Subject | RE: [firebird-support] Design advice |
---|---|
Author | Thomas Tomiczek |
Post date | 2005-08-20T19:07:55Z |
Well, not wanting to go at all into an architecture discussion, but let
me tell you tat I am one person thinking your arguments are not well
thought out.
Let me explain that in the last year and a half, for example, I have
been writing and architecting a CMS that works against SQL Server,
Oracle, MS Access and soon Firebird (Oracle is a LITTLe feature limited
at the moment).
During this project, which consists of more than 200 tables and roughly
250 or so business classes we have written
ZERO
Sql at all.
There is not a single line of SQL in the whole application. Nada. Zero.
On top of this (exception: oracle, firebird I am working on it) we are
not only generating all queries and db operations, but also all DDL -
database schema creation AND maintenance are fully automated.
We only did this because so far we have been able to offset any and all
performance issues through the use of a data access layer caching
mechanism (which, especially when an object loads data from multiple
tables, can even speed up the whole thing and dake load from the
database).
On top, the program team spent exactly
ZERO
Time on maintaining a data access layer, as data access is 100%
automated under the object model by means of a middleware (that another
team programs, but it is a product).
Now,
Given that SP's and data access are simply not existing - and thus there
is no maintenance issue at all over the whole application, do you not
agree that such an approach is way MORE well structure, thought over and
consisten (and thouroughly tested) than yours? Oh, performance is more
than satisfying.
And before we made this middleware, we used a simpler one that hard
hardcoded SQL statements - in ONE configuration file. You see, "not
using SP's and using dynamic SQL" is by no means identical to "being an
idiot and scattering your SQL over the whole project". There IS a ground
for people using what looks like dynamic SQL to the database, but using
a repository like mechanism (propably with a code generator for strong
typed usage classes) to centralize SQL code on ONE location.
Let me add that our fully automated configured data layer allows dynamic
queries (strong typed, compile time checking) in a db independent form,
and performs a lot of things that most programmers do not even dream of
(like pretty advanced caching).
Good programming is about eliminating unnessary superflous layers, not
about making up justifications for them.
What is the book you talk about, btw.?
Thomas Tomiczek
1124571544/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforg
ood.org/topics/education/digitaldivide/?>
source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In low
me tell you tat I am one person thinking your arguments are not well
thought out.
Let me explain that in the last year and a half, for example, I have
been writing and architecting a CMS that works against SQL Server,
Oracle, MS Access and soon Firebird (Oracle is a LITTLe feature limited
at the moment).
During this project, which consists of more than 200 tables and roughly
250 or so business classes we have written
ZERO
Sql at all.
There is not a single line of SQL in the whole application. Nada. Zero.
On top of this (exception: oracle, firebird I am working on it) we are
not only generating all queries and db operations, but also all DDL -
database schema creation AND maintenance are fully automated.
We only did this because so far we have been able to offset any and all
performance issues through the use of a data access layer caching
mechanism (which, especially when an object loads data from multiple
tables, can even speed up the whole thing and dake load from the
database).
On top, the program team spent exactly
ZERO
Time on maintaining a data access layer, as data access is 100%
automated under the object model by means of a middleware (that another
team programs, but it is a product).
Now,
Given that SP's and data access are simply not existing - and thus there
is no maintenance issue at all over the whole application, do you not
agree that such an approach is way MORE well structure, thought over and
consisten (and thouroughly tested) than yours? Oh, performance is more
than satisfying.
And before we made this middleware, we used a simpler one that hard
hardcoded SQL statements - in ONE configuration file. You see, "not
using SP's and using dynamic SQL" is by no means identical to "being an
idiot and scattering your SQL over the whole project". There IS a ground
for people using what looks like dynamic SQL to the database, but using
a repository like mechanism (propably with a code generator for strong
typed usage classes) to centralize SQL code on ONE location.
Let me add that our fully automated configured data layer allows dynamic
queries (strong typed, compile time checking) in a db independent form,
and performs a lot of things that most programmers do not even dream of
(like pretty advanced caching).
Good programming is about eliminating unnessary superflous layers, not
about making up justifications for them.
What is the book you talk about, btw.?
Thomas Tomiczek
> -----Original Message-----839731.1510227/D=groups/S=1705115386:TM/Y=YAHOO/EXP=>
> From: firebird-support@yahoogroups.com
> [mailto:firebird-support@yahoogroups.com] On Behalf Of constantijnw
> Sent: Samstag, 20. August 2005 20:59
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Design advice
>
> Helen Borrie wrote:
>
> > >I'm developing a commercial application that uses Firebird. At the
> > >moment I have all my queries coded in stored procedures.
> >
> > This is extremely unnecessary.
> >
> Helen, why do people buy your book? I think most do because
> you present scattered knowledge about Firebird in a well
> thought over, structured and consistent way. Also you clarify
> interdependencies between pieces of knowledge. It makes your
> book more valuable than just a bunch of articles.
> I prefer using stored procedures for accessing data just for the same
> reason: well thought over, structured, consistent and
> thorough tested mature code accessing data, instead of
> dynamic queries scattered all over the place in all flavours
> imaginable.
> At first I was also very annoyed about those dependencies,
> when changing a table field for instance. But now I find it a
> big advantage that I can have I clear picture of what my
> field change implies for the other logic used.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> <font face=arial size=-1><a
> href="http://us.ard.yahoo.com/SIG=12h3vp83u/M=362335.6886445.7
1124571544/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforg
ood.org/topics/education/digitaldivide/?>
source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In low
> income neighborhoods, 84% do not own computers. At Network
> for Good, help bridge the Digital Divide!</a>.</font>
> --------------------------------------------------------------
> ------~->
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources
> item on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>