Re: The IDS, the EDS and the DBMS
Date: Mon, 6 Sep 2004 08:52:59 -0400
Message-ID: <iI2dnT0mD_FNwKHcRVn-rA_at_comcast.com>
> http://martinfowler.com/articles/dblogic.html
Thanks for the pointer to this article. I'll start a new thread once I've
absorbed the content. I think Fowler's thinking is a nice complement to my
own. I'm a SQL oriented person. (I would have said a "Relational" oriented
person to anyone but you).
And I'm trying to understand the real value of object oriented analysis and
design without abandoning my own perspective.
Fowler appears to be an OO person who is exploring the value of SQL based thinking.
There are three points where I would word things differently from Fowler.
First, SQL is is not a "database language" as such. It's a data sublanguage
for data exchange across a client-server interface.
The fact that the DDL (CREATE, ALTER, and DROP) were thrown in with SQL is
very handy at the practical level, but
obscures the real mission of the language: to facilitate data exchange
between a database environment and a data processing environment.
Second, the logic encoded in an SQL SELECT is not a statement about what the data IS (emphasis mine). It's a statement about how the data may be viewed. That view may be idiosyncratic or even perverse, but it is not imposed on the rest of the users of the database. When an SQL SELECT is encoded in an SQL view, that view may appear to enforce its own view of the data on those who use the view as if it were a table, but that's another story.
The business rules in the database are not, IMO, in the logic of the SELECT, but in the constraints which prevent anomalous data from being added to the database. In other words, the business rules are imposed when the data is added, not when the data is used.
Third, Fowler properly puts maintainability ahead of performance. But there is something that comes ahead of both maintainability and performance. It's correctness. The first thing you do with some code (once it compiles without error), is to prove its correctness for a given range of inputs. This proof can be done by abstract reasoning, or by oberving a test sample, or both. If the code is not maintainable and it contains errors, then it should be junked. If it is maintainable, and it contains errors, then the first work of maintenance on it, prior to release, is to fix the errors.
Once it is both maintainable and correct, it's time to look at performance. And the performance of a sound piece of code working on soundly designed data is often "good enough", at least at first. Abstract code analysis is of value here, too. In particular, it behooves the coder to be aware of all cases where the effort grows non linearly with the volume of data.
Aw jeez, I went and wrote a book, in this post. Maybe I should write in blogs instead of newsgroups. Received on Mon Sep 06 2004 - 14:52:59 CEST