Database Life Cycle

by Jeff Baygents

HOW does a typical database life cycle develop? Databases may start out in an office where
someone has some data and then an Excel spreadsheet is created and maintained.
Later, it evolves into several spreadsheets. Then, the individual starts sharing the file with other spreadsheet owners.
Later, a few spreadsheet files end up out on the network for easier accessibility for those individuals.
Then, someone starts creating an Access database. Many of the users don’t know how to use a database
program so, they continue with the spreadsheet system. Then, the Access database user makes some
very nice looking reports and gets some attention.
Then, someone gets a newer version of Excel and e-mails a new spreadsheet to others for sharing it and
they can’t open it. One of the recipients sends a reply telling the sender that it was a bad file and to send
it again. One recipient sends a voice mail message that the file they received must have had a macro virus because they can’t get it open and the message that comes up says it’s the wrong version (the user
knows they have the correct version of Excel because their other Excel files will open). Other recipients email, call, or visit to ask for a file that works because they’ve come to rely on sharing that particular Excel
file for reporting purposes. One person needs it real bad because she uses the data for a chart in her
PowerPoint presentation she needs to give in about 2 hours.
Then, someone sees the need for synchronizing the data and reports that are now commonly shared
among a group of individuals in various departments because of the various issues that are developing.
So, an Access database project is created. It’s put out on the network when completed and everyone is
sharing it. In time, it becomes popular with several additional people. So, other departments start linking
to it to make some of their own custom reports. They even make their own version of a database and
keep their links to the other database tables. Eventually, the new faster version of Access comes out and
the main database is upgraded. Again, the ones who linked to it are panicking because now their reports
aren’t working. They aren’t ready to upgrade their software because of budget constraints and they really
don’t have the need to upgrade. Then, someone mentions SQL Server.
So, a client/server project is created and completed. Now, everyone has an Access front-end which is attached to the SQL Server backend. The Access front-end is deployed like an application using the developer’s run-time engine and the budget allows it because of the distribution license that comes with the
toolkit. Everyone is happy again,… for awhile.
Then, other branches want to be a part of the data system and they have some data that can be shared
in order to assist in expanding the existing reporting system. So, an agreement is reached and a new client/server project is created that modifies the existing model to include replication to a few other servers
in the company in other cities and states. And then, time goes by and new reports are being written. And,
then… one of the servers in the replication model goes down. But, things progressed reasonably well because replication was configured correctly everywhere. And then, a new report is added and its replication was setup not exactly right and all replication shuts down. No one is exactly sure what happened or why until a few days go by and a very astute SQL Server individual discovers that a particular field in a
table was being ‘published’ instead of being ‘subscribed’, ie., the direction of the data was wrong on the
‘one way street’. In the meantime, management is concerned over the serious levels of advanced skillsets
required to maintain the multi-tiered database scheme with replication. New reports aren’t being developed fast enough anymore, many servers are involved as a source of data, replication and security issues are occupying development time, and some users are operating under different types of Visual
Basic & Access clients. What could possibly develop that would be the next step in the life cycle of this
database monstrosity?
Then, the Intranet project came to pass. Eventually the reports came to show up one by one on the Intranet and people stood in line to wait for their report to be developed so they could see it on the company
web site. Then, one day the web site changed and it looked better. It was more user-friendly and less
screens to click on before you finally got to the reports you needed. And then you went to click on one of
your favorite pages and you read an error message… something about a script error or something’s out
of range, it’s technical. So you call support and they ask you several questions for a few minutes and then
you’re told you have the wrong type of browser or the wrong version or you need a plug-in, or you …
And so, the life cycle of the database continues. We haven’t yet gone through a complete cycle yet, technologically speaking. In 1997, this original article concluded with the following:
 What’s anticipated between now and 2008 for databases? Automated Information Filtering,
Trapping, & Dissemination (AIFTD). You will be notified by auto sensor mail (on your ring’s PC)
when it’s been projected (with an 80% accuracy) that one particular material for your top selling
product will be unavailable for 6 days due to international databases forecasts of the world supplies. But, it’s okay because some alternative solutions are also provided such as marketing
schemes to apply to shift sales to other product lines which will be overstocked by 121% during
that time. The cycle continues.
Microsoft, Visual Basic, SQL Server, Access, and Excel are trademarks of the Microsoft Corporation.


Copyright © 1997, 2021 by Jeffrey Thomas Baygents. All rights reserved. URLS (linking) to articles do not require advance authorization. Copying, reprinting, or reposting requires email authorization confirmation. Send requests with brief description of intended
usage to