You are here: Re: Database abstraction layers « PHP Programming Language « IT news, forums, messages
Re: Database abstraction layers

Posted by Colin McKinnon on 10/27/97 11:47

Dikkie Dik wrote:

>> I want some code where I present an array of data, and the corresponding
>> primary key and let the code work out whether to INSERT or UPDATE it,
>
> Quite simple. If the primary key in your application is numeric, you got
> it from the database. Otherwise, how would you know the key value?
> If the primary key value is NULL, it is a new record. even if it
> contains the same non-key data as an existing record, it is different
> anyhow.
That only really works if you don't bother normalizing your data but chuck
in an auto-incrementing record identifier (the rot started with MS-Access
on that one, but its far too common in web apps).

It all rather falls apart when you're dealing with very large sets of
normalized data - what about updating the data within the PK? Cascade
updates?

> If you have more than one instance representing one record, you
> may look at http://www.w-p.dds.nl/article/wrtabrec.htm for how to fix
> that (shamelessly plugging my own article).
>
>> I also want to be able to present the data from a QBF or QBE then be able
>> to step through the result set. However I don't want to have to configure
>> the DBMS structure - after all most of it is already in the DBMS (OK so
>> not the relationships in a MySQL db). It'd be really cool if I could
>> throw SQL directly at it *too*.
>
> I think having to configure a mapper is a bad code smell. My biggest
> problem today is the dependency across systems. You probably have
> encountered situations where file names were in the database, or where
> constants in an application referred to enumerations in a database
> field. These dependencies cannot be enforced (no one will stop you from
> deleting a file if its name is in a database, for example). If you have
> a configuration file for a mapper, you introduce *yet another* non
> enforceable dependency, along with an untestable system.
>

I think that's the point I was making - there should be enough description
of the structure accessible via the DDL to make that redundant. In fact
using just SQL on its own its not sufficient - even with foreign key
declarations and constraints. Having said that there is a lot you can do
with what is avilable even in MySQL. Particularly if you maintain a strict
domain naming strategy.

In my search I came across a couple of systems which seemed to come close to
what I wanted, but both used a static description of the data structure
which was maintained independently of the DBMS - yes that causes problems.

> But then, I always write my mappings myself. Common code gets into
> superclasses and the strict typing (in languages that support it) and
> the communication stategies into the wrappers. So definition/lookup
> tables become read-only collections, for instance. For each table, I
> decide whether I want it to be lazy, greedy, preloadable (you can
> "schedule" a record without loading it yet, but it will be loaded at the
> first necessary database action), or whatever other combination of lazy
> and greedy.
> Always remember that a class should encapsulate and hide its internal
> structure. If a table strategy would change the interface of its
> wrapping collection, it is not a useful wrapper.

You're the one who started talking about OO. I spend my working hours fixing
problems that have arisen from O-R impedance mismatch. I think the idea of
using a relational database as a persistance layer for an OO application is
fundamentally flawed. While I admit that it does take more work in
producing the initial version of an application, its not really much effort
to extrapolate a normalized database design and implement the factories to
populate the runtime rather than simply a 1:1 object:record mapping - and
the benefits are huge when you start looking at whole lifecycle -
particularly post-release development. This was one of my reasons for
tackling the problem in this way - to eliminate that hurdle. It also means
that the abstraction is applicable in other idioms.

But the article is interesting.

C.

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация