Here Here ....
I think calling for an abstraction layer for the sake of it is
crazy design. I always thought modelling was about getting as close to the
subject as possible - distilling the essential - nothing more, nothing
less.
The more layers/interfaces/tears involved the more shaky a
foundation - and abstract a solution. Building software is not like
building a bridge --- over-engineering by pouring more cement doesn't
help.
The costs for this extra abstraction can include: extra debugging,
extra complexity, hobbling functionality (e.g., no group by clause etc.)
and extra maintenance (of the abstraction layers).
I still think a well designed relational model is the most solid
foundation a system can have - and the less layers/interfaces/tears on top
of that the better.
Nige
> On Wed, 1 Aug 2001, kyle dawkins wrote:
>
> kd> Well, yes and no. I was citing that example as *another* reason to keep
> kd> SQL out of your application-level code.
> kd> If you do, as Henrik suggests, write pure SQL92, then obviously you
> kd> wouldn't need to wrap all your SQL in "ifs" like they did with
> kd> wwwthreads... you could just switch out MySQL and switch in Filemaker
> kd> Pro if it supported SQL92 and had a DBD module :-). I maintain,
> kd> however, that SQL embedded in application logic is evil in all but the
> kd> simplest of scripts. Putting it in middleware is mandatory; I don't take
> kd> issue with that.
>
> I am not against removing redudancy and creating function/methods of code
> that is used more than once so that you don't do the same SQL query at
> several places in your code. But that is good programming practices within
> your own classes/modules.
>
> But to abstract everything to a SQL class only moves your SQL there and
> probably causes severe limitations when wanting to do something advanced
> Maybe if you were writing a data abstraction layer and API for some other
> programmers, but if you have a database that you know only your script
> will use, writing an extra abstraction seems very overkill.
>
> I could see a use for abstraction if we were going to support several
> different query languages, but as long as we only use SQL my belief is
> that DBI is abstraction enough to maintain DMBS interoperability. And of
> course only use SQL92.
>
> Someone once said that more abstraction levels than four (4) is counter
> productive.
>
> I can see both sides in real life. It all comes down to what kind of
> application development you are doing. And writing your SQL in your main
> Perl code now does not make it impossible in the future to abstract it to
> it's own class. But I have seen whole applications go under because they
> have been so heavily abstracted that in the end no one is even sure what
> happens anymore - and then of course - class/object operations in Perl 5
> are not the fastest either.
>
> Regards, Henrik
>
> --
> Henrik Edlund <[EMAIL PROTECTED]>
> http://www.edlund.org/
>
> "You're young, you're drunk, you're in bed, you have knives; shit
> happens." -- Angelina Jolie
>
