Re: Generating SQL
From: Topmind (topmind_at_technologist.com)
Date: 11/17/04
- Next message: Otavio C. Decio: "Re: Generating SQL"
- Previous message: Topmind: "Re: Switch Statements and Refactoring"
- In reply to: Otavio C. Decio: "Re: Generating SQL"
- Next in thread: Otavio C. Decio: "Re: Generating SQL"
- Reply: Otavio C. Decio: "Re: Generating SQL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 17 Nov 2004 09:34:26 -0800
"Otavio C. Decio" <REMOVEodecio@earthlink.REMOVE.net> wrote in message news:<f6GdnVoztfw0EwXcRVn-vg@giganews.com>...
> "Topmind" <topmind@technologist.com> wrote in message
> news:4e705869.0411141849.4e871928@posting.google.com...
> > "Otavio C. Decio" <REMOVEodecio@earthlink.REMOVE.net> wrote in message
> news:<vcCdndLJWpilFQjcRVn-3A@giganews.com>...
> >
> > Scanning a bunch of column descripter classes for column
> > info sounds like a kind of data dictionary.
>
> Yes, a data dictionary documented in code - the value object class. Change
> the data dictionary means change the class - the SQL gets updated with no
> other code change, just the class definition.
Well, a real table is easier to edit and maintain by far
in my opinion than one in linear text code. But, this is
assuming you already have the right tools. If not, then I
suppose classes are a consolation prize, but DD's can be
made many other code-centric ways besides classes.
>
> >
> > Well, anything is wrappable, but that does not necessarily mean
> > that it should be wrapped. You may end up inventing a custom
> > language that is uglier and/or less documented than SQL.
> > I'll take a standardized devil over a custom-rolled devil
> > in most cases. If you get hit by a bus and your replacement
> > cannot find the documentation for your custom query API,
> > they may be in for a lot of
> > work. But if you get hit by a bus, there are still plenty
> > of SQL books and resources available.
>
> That doesn't make string concatenated SQL any more readable or maintainable.
Nor does it by itself make it less maintainable.
> My original intent was to find a better way to communicate with the
> database, to make it more consistent.
Concatentation is not by itself less consistent.
> Now I have something that generates
> proper SQL, with parameters and data types derived from my classes. Changes
> in the database are documented in code - as you said, the value object class
> is the data dictionary, which is great.
That only allows automatic column info generation. But, there is
much more to SQL than that, as already stated. I am not against
that for columns, I just don't beleive it practical to
entirely wrap SQL, only the low-hanging fruit. This is not
an all-or-nothing argument.
>
> >
> > Any business app programmer who does not know SQL should
> > be fired anyhow. Programmers are a dime-a-dozen these days,
> > and if you cannot find one who knows SQL (in addition to
> > app language), you must be locked in car.
> >
>
> Just because programmers are cheap these days doesn't mean that hiring a
> dozen of sql-concatenating of them will be any guarantee of success.
Nor does reinventing the whole of SQL via verbose API's.
>
> >
> > -T-
>
> Otavio
- Next message: Otavio C. Decio: "Re: Generating SQL"
- Previous message: Topmind: "Re: Switch Statements and Refactoring"
- In reply to: Otavio C. Decio: "Re: Generating SQL"
- Next in thread: Otavio C. Decio: "Re: Generating SQL"
- Reply: Otavio C. Decio: "Re: Generating SQL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|