I have been somewhat busy of late and have not had much time to post entries, but this one caught my eye and I thought I had to comment. Micheal Platt in an unrelated topic, declares that his '4th law',
quote - 'In general the architecture of a system should start with the data or informational schemas.' - unquote
I have seen this approach in so many companies. It has been an historical design philosophy that does not seem to be going away.
My opinion is that it is one of the worst places to start for a new development and that it is an unfortunate place to start if it already exists.
No matter how well you design a system, data schemas change - and very often forces a lot of code changes too.
A Database is a storage mechanism, used to store stuff, its not the epicenter of the world.
Don't get me wrong, data is important, to clients and to applications, its ultimately what you build a system for, however, its not the only consideration.
Code is just as important and is often neglected. What do clients wait for? Code. What do clients most often have problems with? code.
As long as a database can deliver queries and views of data in a speedy fashion, and suitable for replication and transactions, the rest is probably right down the 10 point meter, sitting at 2 or 3.
If a database is slow or large, you reindex, partition, load balance, move things around, split tables, change query criteria to cross tables, cross database etc.
In most developments, its not the perfect world of design, so if you change as much as a table name, your code breaks.
If code is slow, you have to refactor, optimize and generally fix the data reads and writes, thus database changes, thus more code changes.Why would you build on such a sandy foundation.
All the end user really looks at and gauges with is the code, and more specifically the UI. They tell you of problems at that level.
The core UI of a system can last for years, with extra menus or other functionality slotted in. As an example, a TreeView can exist for years.
New requirements that translated into the database, affects everything. If one concentrated on the UI first, you get more of the unaccounted for requirements, before you get down to the db level. If you spend time on your middle tier, you can design for the requirements of the UI, not the requirements of the database.
I think the UI and Middle tier is a far more stable foundation to base your system on, than the database.
Iteratively, they are all linked, but I would concentrate on building the middle as you 'experience' the Top, and let the bottom follow.
In many larger organizations (generalizing), a DBA 'owns' the database, and plays his 'god' role to perfection. I have seen this to have detrimental affects on code performance, maintainance and other issues.
Just think of all the systems out there, that cannto be updated, upgraded, moved on, etc, because changing the database is just too much hassle. The more you abstract the 'physical data' and lessor the emphasis on it, the more stable and alterable your system can become.
One of the biggest hurdles to companies that want to use the new design features of Yukon, will be their database and the code that is so dependant on it.
Previous Topic
