|
|
|
|
real estate software / uk database design | property management software
|
Property Databases
Writing your own database
Writing your own property database or having one
written for you is a popular idea for many small to medium sized
Estate Agencies (and some larger ones too).
It can be a good solution for some organisations
but unfortunately there are many organisations who do not consider
all the implications of doing so.
One of the most common misconceptions, for example,
is that you can simply buy Microsoft Access for a couple of hundred
pounds, and that there will be no more costs.
This section tries to give the pros and cons of
writing your own database.
Benefits of writing your own database can include:
- Keeping it Simple:
If you are a small Estate Agency with simple requirements then
it may well be that you really do not need any of the sophisticated
requirements offered by commercial property packages. It is not
difficult to write a fundamental database with name and address
information, basic recording of clients, a few simple reports
and an export function to a word processor for writing letters.
It can and has been done successfully many times.
- Cost: Again,
if you do want the simplest of databases and you either have an
employee or a volunteer who already knows how to write databases,
then the cost can be kept down.
- Designed for your
requirements: There may be cases where you have to have
something written for you because you have specific requirements
which a commercial package cannot match. And you can have reports
written which match your output requirements exactly.
- Consideration to
expansion: Not just for property For 'organisation-wide'
(or "corporate wide") databases where you might want
to hold information other than just properties all on the same
database, then you could consider a database written especially
for you. For example, if you also wanted the public's requests
for detailed information internal data, cause-related information,
research and so on.
- It is yours to change:
If you do get someone to write a system for you then you will
also probably have access to the database structure and 'source
code'. This means that if there is someone in your organisation
who knows how to program this database then they can change it
as and when you want it changed. And potentially far quicker than
with a commercial package where they need to consider the affect
of any change on all their customers.
The possible downsides of writing your own system include:
- They are not pre-defined:
As stated above, it is a common misconception that you can simply
buy a database package such as Access, Paradox, FoxPro, Cardbox
and so on, and that is all there is to it. All these packages
are simply tools which let you write your own system, and you
need to add everything to it (often referred to as 'templates'):
fields, lists, screens, functions, reports.
- Design: You
have to design your entire system. This means thinking about all
the data which you want - or might want - to hold. It means meetings
with users, planning, writing a specification, designing fields/screens/functions/reports
and checking to see if you have thought of everything. If you
are getting a company to write a system for you then if you forget
anything at this early stage then they are highly likely to charge
you more later if you want to add/change anything.
- Cost: Again,
although it can be cheaper than buying a pre-defined package,
there are many cost considerations. For a start, if you are considering
getting a commercial company or independent developer to write
a system for you then this really can be expensive. They may well
charge for feasibility & design as well as programming and
no programmer worth their salt will be less than several hundred
pounds a day; and it will take many days of their time. Even if
you are writing the database 'in-house' (i.e. having your IT staff
write it) then all the above issues can add up.
- Time: Writing
your own database can take a long time and one of the sad facts
about the computer industry is that projects always seem to take
far longer than expected! This is not just a truism.
- Support:
Who will give you support after the package has been written?
What about help screens? Or a user manual?
- No future-proofing:
This in itself can outweigh many of the advantages of writing
your own database because, once you have written it, then a little
later, technology (and your requirements) will change and you
may be left with an out-of-date database. If you want it changed
or updated then back come those costs all over again.
- Database querying/reporting:
One specific issue of writing your own database but where you
want other people to be using it, involves querying the database.
- Usability & Accesibility:
Many packages do offer 'graphical query interfaces' but they are
not always user-friendly and can require a degree of technical
comprehension on a user's part. This is one of the most common
complaints of any user, not just in fundraising - that their database
can record data okay, but it is very complex getting the data
out.
|
