Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Christian Brunschen wrote:
>
> For a trivial example, consider an application that needs to somehow
> authenticate users (because different users have permission or not for
> different parts of the functonality of the application. The user
> information (name, password, etc) will have to be stored somewhere - a
> relational database might be an excellent place, in particular if this
> application is essentially a stand-alone one.
>
> However, it might be that the application is intented to be integrated
> into an existing infrastructure, that has user information stored in an
> LDAP-accessible database; or for another example, the user information
> might be stored in a Unix-style flat file (a la /etc/passwd).
>
> By separating out the logic that handles any interaction between the
> chosen database into separate, database-specific modules that share a
> common interface, the rest of the application can remain identically the
> same, with only the database-specific parts needing to be plugged in or
> out, depending on the precise environment where the application is
> deployed.

There's a severe problem with that logic, though.

If you want to build a layer to wrap a variety of different storage mechanisms, that layer *cannot* be any more powerful than the weakest mechanism you want to layer on top of. Which means your very high level, very powerful SQL dbms will be stuck at the level of the stupidest file store ever invented.

And in swoops the application programmer to "save" the day from the problem he invented! All he has to do is write that subset of a DBMS that he needs today. Which will slowly, over time, increase until it's a badly implemented, bug ridden, ad hoc implementation of half of a database. This is Spight's Law. You have to have a dbms, whether you use a good one or reinvent it yourself, badly.

To put it in the terms of application programming, it is as if we decided we want to be able to swap our programming language one for another at will. So we can't use any features of any programming language that isn't in all of them. Oh, and we want assembly to be on the list.

Marshall

PS. Props to Greenspun's Tenth. Received on Thu Jun 01 2006 - 16:32:15 CEST