Slashdot Mirror
Evolutionary Database Design
Andre Mermegas writes "Check out this article by everybody's favorite object mentor Martin Fowler on database design. Be sure to take a peek at his wonderful books as well."
← Back to Stories (view on slashdot.org)
I think it's nice that people are starting to get interested in relational databases again. They really are the backbone of information systems in business, despite what the industry rags will have you believe.
The "hype" of object-oriented and XML-driven "databases", although aesthetically prettier, have adverse effects on performance and design. Programmers get lazy, applications become sloppy and performance goes into the toilet.
This may sound very arrogant, but I think the developer should manage the DBA, often the DBA is a lone-wolf with too much power.
So instead you'd end up with a developer with too much power...
The thing about the separation of database design from "front-end" design (which could be middleware or front-end applications) is that in most cases the database scheme and I/O design has a shelf life far longer than most front-ends. i.e. Don't see that new web interface as a new system with a new database, but rather as a "one of many" front ends to the back-end database: i.e. the database is of much greater long term importance than any front-end.
Regarding your particular scenario: Is it possible that you're looking to shoehorn functionality for your particular front-end into a universal back-end where it might not be appropriate? Will every query on the person table suddenly have have the overhead of calculating the persons age because one page in one obscure part of one front end needs it?
I'm currently working as a developer, but I used to work as a development DBA. In my opinion this article shows the database and the DBA roles in a project from a developer perspective.
As a general rule, the developers think that the database is there to support their application, which is really the piece that solves the problem. In the other hand DBAs think that the developers are there to support their data model, by supplying an interface with validation and some simple pieces of logic that their store procedures don't cover.
I have worked much longer as a developer than as a DBA, but I still find it funny that the article assumes that the developer should be able to add a column to a table freely and the incorporate the changes to the main database. This is the equivalent of saying the DBA should be able to freely change a class or an interface and then add the changes to the source control repository.
While not wrong in itself, it clearly shows that many developers consider the DBA role secondary to the developer. It goes something like this: I can somehow do some DBA tasks that impact the development like adding tables to the schema, I just don't want a get involved in the boring parts (backups, recovery or replicating schemas).
I think that creating a good data model is as difficult as creating a good application design and doing a decent store procedure as hard as doing an efficient method. While some DBAs can write very good C++/Java code and some developers can design very good data models, no one should be doing each other job unless they really, really, really know what they are doing.
As a general rule of thumb, if you consider that mySQL is a better database for large complex applications as PostgreSQL or Oracle, you should not be doing any database work.
is iterative design. Which is becoming fairly widely accepted in OO circles, and almost universally accepted in Agile circles.
Databases, however, are a lot harder to iterate - the cost of change is higher than with any other code. Martin Fowler is laying down an approach to manage (not reduce - manage) that cost, and it all comes down to a guess we have to make - do we think the overall cost/benefit tradeoff of an iterative process is better than a Big Design Up Front process ?
On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc. It all boils down to the cost of change - it's expensive to change a database design because it is very hard to identify the knock-on effects. Some changes are relatively easy to manage - adding a column is unlikely to actually break anything - but others can wreak havoc with existing applications - changing the type or size of a column for instance.
I'd love to think that the next big improvement in software development tools is not going to be yet another language but a sensible way of tying objects to their persisted data. All the solutions I've seen so far are bolted-on - they either force the database into unnatural positions, or make the objects fit into a model that's not quite what they'd be otherwise.
In the meantime, this article is well worth investigating - the idea of evolving the datamodel in tandem with the migration scripts is very powerful.
It's all very well in practice, but it will never work in theory.
I work on a project of about a dozen developers, some os us geographically diverse. We use an Object-Oriented Database with Java (Database is from Versant).
I would note that "object oriented databases" tend to resemble the hierarchical or "network" databases of the 1960's. They fell out of favor for various reasons.....until OODBMS started popping up again. The OO croud has not been able to solve many of the same problems that were there in the 60's.
It is true that they tend to be more "organic" than RDB's, but they also lack the rigor of relational algebra that makes RDBMS scalable, manageable, and more queriable. (Although the current crop of RDBMS also fall short of the theory by some accounts.)
Table-ized A.I.
No, and I do mean no Perl programmer ever calls it PERL. It is not an acronym, even though people has been to retrofit one to it at lots of occassions. Unless you are the only person that actually uses the cheap copy with that name, that someone tried to promote a long time ago.
Your credibility goes right out the window if you don't even know that. Reading your post it does seem that you are just throwing out some buzzwords and acronyms, hoping for some cheap karma.
If I wanted to be real nitpicky, there are dozens of other such mistakes - things that are called things they are not and misspelled. Sad, sad.
Why?
He's big on automated testing. He's big on frequent, small integrations. Ideally, every developer integrates with the bleeding-edge source code at least once a day. That's why the changes are so little! No one strays too long from the work of everyone else.
It may seem like anarchy at first glance, but if you read a little closer, you'll see that there are strong behaviors in place to prevent that chaos.
how to invest, a novice's guide
Whether it's a schema change or a data change, a change like that mid-way through development is a serious decision, and shouldn't be undertaken lightly.
That's one way to develop.
Or, instead, you could assume that change is a given and tune your development process for that.
The DBA and developers need to work together to work out an ideal schema. Ideally, it's msotly worked out *before* any coding is done. DB objects should not be done on the fly in msot cases.
Yes, ideally all requirements are identified, and then all the design is done, and then all of the code is written. Ideally. And ideally, you could remove the backspace key from they keyboard.
Alas, most of us don't get to code in an ideal world. The premise behind the various Agile methods (Extreme Programming, Crystal, Scrum, FDD, etc.) is that since the world isn't ideal, we might as well pick development methods that are tuned for the world we live in.
Interesting notion, eh?