Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 01 Jun 2006 02:09:29 GMT
Message-ID: <t%rfg.36182$YI5.2763_at_tornado.ohiordc.rr.com>
Robert Martin wrote:
> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout_at_myonline.be> said:
>
>> Little point in preaching to the chuiar of course (how do you spell >> that damn word ?). >> >> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed. >> >> That said, application code is still highly important because it's >> needed to fill all the holes that current dbms's still leave wide open >> in the area of constraint enforcement.
>
>
> This statement is fascinating. It takes the view that the majority of
> the system is DB and that application code simply fills the cracks. The
> DB represents the bricks and the application code is the mortar.
>
> I disagree with this analogy. The RDBMS is a mechanisms for storing,
> accessing, reporting, data. That mechanism can be implemented many
> different ways and need not even be an RDB. The application code
> defines what the program does with the data.
>
> Some RDBMSs have created an application language in which some
> application programs can be written. (stored procedures in SQL, or 4th
> gls, etc.) Typically these langauges are very special purpose and
> vendor specific. They are not general purpose application programming
> languages. Therefore, though they have their uses, they should be used
> with caution and restraint.
>
> Even when such language exist, they are not part of the datbase itself.
> They are still aplication languages.
>
> The application code is not the glue that fills in the cracks. Instead
> the data is the cargo, and the application code is the railway network,
> engines, and cars, factories, that transform the raw data into useable
> product. The databases are the warehouses, and a specific vendor's DBMS
> is the material that the warehouse is made of.
>
> Granted those warehouses are complicated structures with their own
> internal access and transport mechanisms to put the data in and get the
> data out, and keep the data safe. But they aren't the railway network,
> factories, and distribution networks.
>
>> >> Little true story : some OO proponent in a seminar (well, it was >> actually "in front of an audience") declared that integrity enforcement >> is the responsibility of the application, blahblahblah (he also >> promoted meaningless ID's everywhere in the same breath). I asked him >> if he was actually aware that the first letter of the word IT stood for >> "information". His reply was : Yes, but the second stands for >> "technology".
>
>
> The story may be true, but I'm not sure I get the point. Frankly, it IS
> the responsibility of the application to enforce integrity. Oh, the DB
> can enforce it while the data is in the warehouse, but the data comes
> out of the warehouse, gets transported all over the place, gets
> transformed in many different ways into many different products, gets
> presented to many different customers and put into many different
> systems, and for all these activities it is the APPLICATION that must
> enforce the integrity of the data. The DB loses control once the data
> is out of the warehouse.
>
> Clearly keeping the integrity of the data in the warehouse is
> important. But that's not the whole story. It's not even most of the
> story.
>
> Finally, and this is critical to the understaning of my point, the code
> in which data integrity is specified IS application code. It may be
> written in a special purpose DB language, or it may not. But it is code
> that supports the application.
An important clarification is needed here: when relational theory advocates talk about data integrity they are talking about constraints which are expressed in declarative language. The superiority of declarative v. imperative languages has long been decided. In part, data dogs slam OO languages because they are, essentially, procedural, and building systems using them is extremely difficult. Sure, you can settle upon "design patterns" and conventions which help all the parts fit together, but complexity abounds and the pile of code is littered with artifacts which exist only because of the technology chosen.
Moreover, putting any part of the mechanism which ensures data integrity in "the application" limits the currency of data -- and that's not something those in the data business want to give up. Received on Thu Jun 01 2006 - 04:09:29 CEST