Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 01 Jun 2006 23:14:04 GMT
Message-ID: <0xKfg.16264$A26.376556_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> 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.
Unless one wants to re-implement larges parts of a dbms, as you have pointed out several times.
> 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.
Man, you sure are pushing hard for a legacy. Do you not intend to number your laws? Should we take that as Spight's First Law? Or Spight's Zeroth Law? And law of what?
> 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.
You and your obscure references to interesting geeks. You caused me to waste an entire afternoon reading various and sundry snippets from Greenspun's sites. Received on Fri Jun 02 2006 - 01:14:04 CEST