Re: Mixing OO and DB
Date: Tue, 11 Mar 2008 20:21:49 -0300
Message-ID: <47d71410$0$4053$9a566e8b_at_news.aliant.net>
Marshall wrote:
> On Mar 8, 3:37 am, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
>
>>In the context of a single application with a variety of storage >>backends, which is what the OO world usually thinks of, and Robert Martin >>in this case, abstraction means providing a common application/storage >>interface that allows storage backends to be added and replaced without >>any change to the common application code.
>
> This is certainly *possible* to do. But there is a significant
> issue involved, relative to the comparative expressive power
> of the storage backends being considered. (To say nothing
> of the issue of compatibility of the computational model of
> the backends.) If we are, for example, comparing a flat
> file backend to a SQL database backend, we have a serious
> mismatch if we want to address them with a single polymorphic
> interface.
Unless one buys Alphora's Dataphor. In that case, one codes in D, a relational programming language, and the product translates that into whatever approximation of the relational calculus the back-end will support.
> There are exactly two ways to address this mismatch. One
> is to write a data management language on par with SQL
> that is backed by a flat file. This will bring the flat file interface
> up to the power of the SQL interface. It is essentially the
> same job as writing a SQL DBMS. The other way is to
> limit one's use of SQL to something comparably powerful
> to flat files: read/write/seek. This, plus a little bit, is about
> all most ORMs do.
>
> Of course, to someone who knows how to leverage SQL
> well, either option is a horror.
>
> Am I overstating the case here? A bit, yes. But not much.
>
> As to the specific point you were making, though, it was
> an excellent one.
>
>
> Marshall
Received on Wed Mar 12 2008 - 00:21:49 CET