Many of the databases we develop are what we call small either from the point of view of the number of users (a single user database anyone?), or the number of tables (that which stores the database's records) or perhaps the number of records in each table. Small databases have some aspects to their development that are a little different from their larger brethren, apart from their size.
Small databases are an unusual challenge as they are often associated with small budgets and small time scales. As such the developer needs to focus very clearly on what can be achieved within time and within budget. There is no room to make fundamental mistakes about the role of the database. There are however some tools at the developers disposal to assist this process.
At Meadowlark we develop our small databases iteratively. We work hard to produce a basic working version, we demonstrate it to the customer, we may even let them play with the software to feel comfortable with how it works. We listen carefully to their feedback, then adapt the database in the light of their needs.
Writing any software is hard. The technology is not the problem, the problem, particularly with small databases is that the developer must know what is required of the software. This is no mean feat. It takes persistence, and sometimes many patient dialogues with the customer.
Small databases may have few database tables and few records within those tables. As such there may be no merit in systems with large slow connection overheads, large table capacity, or onerous security measures. On the subject of security, small databases often avoid many of the pitfalls of cloud based systems if they store their data locally. You can find some of our comments about security here: article:Database security.
For decades we have developed bespoke databases for some of the best known organisations in the UK.
We are told our work is excellent, and our customers have no hesitation in returning to us for further work.
If you have not heard of us, it could be that some of our customers would rather not allow their competitors access to our services. We have been told this on more than one occasion.
On any given database project our work comprises many stages:
The iterative software development process can be summed up as "delivery in proven stages". An initial application is developed, it is evaluated by the customer, or their representatives, it is refined, and extended to deal with any failings that are reported, it is reviewed and improved until it is fit for purpose (as deemed by the customer). This can take many cycles. Iterative development has some major advantages.
The software written at each iteration is proven to be valid (at least from the point of view of the conceptual model). With such a solid background, it is hard to make any major and costly errors that feature in the finished software.
The developer is confident that the progress so far is genuine, and that code written today will not need to be scrapped later as new requirements are belatedly discovered.
The customer is a willing and informed participant throughout the software development process. They understand and agree to each facet of the software.
With such an investment, the customer often understands the finished application before it is delivered, and can support and justify its use to other staff. They become an evangelist, and the developers best asset.
Because the iterative method quickly showcases each stage of the software development project, managers are often more supportive of the process. They can see what they are getting.