The database development life cycle is the sequence of steps that takes a business problem and turns it into a working database. Textbooks give it six or seven formal stages. This version describes what each stage actually involves on a real small or mid-sized business project, and where projects usually go wrong.
1. Work out what the business actually does
Before any design, someone has to understand the process being supported — not the process as described in a meeting, but as it really runs, including the exceptions everyone has stopped noticing.
The most reliable source is whatever the business already uses. A spreadsheet or an old Access database that has been running for years is a specification: the columns people actually fill in, the rules they work around, the reports they genuinely rely on. Reading that beats interviewing, because it records what happens rather than what people think happens.
Where it goes wrong: designing for the tidy version of the process. The exceptions are the process. If 15% of orders are handled differently, that path needs designing too, or staff will keep a private spreadsheet for it and you are back where you started.
2. Design the structure
This is the modelling stage: what things exist (customers, orders, products), what facts you hold about each, and how they relate. Normalisation belongs here — storing each fact once so it cannot contradict itself.
The practical test is not academic correctness. It is: can this structure answer the questions the business asks, without anyone re-typing anything?
Where it goes wrong: modelling the current screens instead of the underlying information. Screens change; the information does not. Get the information right and screens are easy to change later.
3. Choose the platform
Which database engine, where it runs, how it is backed up. For most small and mid-sized businesses this is a shorter conversation than expected — SQL Server if you are a Microsoft business, PostgreSQL if you are not, hosted rather than a server in a cupboard.
Where it goes wrong: treating this as the big decision. It rarely is. The application built on top matters far more than the engine underneath.
4. Build it
Tables, relationships, constraints, and the application people will actually use. Constraints matter more than they look: a rule enforced by the database is enforced always, whereas a rule enforced only in the interface lasts until someone imports a spreadsheet.
Where it goes wrong: building the whole thing before anyone sees it. Get one real workflow in front of real users early; they will tell you within a day what six weeks of specification would have missed.
5. Move the existing data in
Always harder than expected, and the stage most often underestimated. Real data is inconsistent — the same customer spelled three ways, dates as text, blank fields that turn out to be meaningful.
Migration is where the cost of years of loose data entry finally becomes visible. Budget properly for it, and expect to make decisions about which version of a duplicate record wins.
Where it goes wrong: assuming a one-pass import. Plan to run it repeatedly, checking totals against the old system each time, until they reconcile exactly.
6. Test with real data and real people
Not just "does it save a record" but: does the month-end total match the old system, does it hold up when three people work at once, what happens when someone enters something absurd.
Where it goes wrong: testing with clean invented data. Clean data hides every problem that migration just revealed.
7. Run it, and keep changing it
Go-live is the start. Backups have to be tested by actually restoring one. Someone has to own changes, because the business will keep changing and a system that cannot follow becomes the next legacy problem.
Where it goes wrong: treating the project as finished. The systems we are asked to replace are almost always ones that were built well and then never touched again.
How long this takes
For a typical business system replacing a spreadsheet or an Access database, weeks rather than months — provided the existing system is available to read. Most of the analysis has already been done by whoever built and maintained it; the work is translating it, not inventing it.
If you have a system like that and want to know what replacing it would involve, our free system review starts by reading what you already have rather than asking you to describe it.
Comments
Be the first to comment on this post.
