F
faceman28208
Over the past few years I have consulted on six large projects that all
independently arrived at the same moronic design desision: The use of
SQL query classes.
No, I don't mean a class hierararchy like:
SQL Query
UpdateQuery
SelectQuery
Where you hide the details of the underlying database API. (Along the
lines of what Rogue Wave does.)
I mean a system where there is a sepate and distinct class used for
every query in the system. [What next, have employee virtual classes
from which you derive a separate class for each employee?????]
All of these have systems employed home-brew code generators. You give
it a query and it generates a class with a bunch of set and get
members. None of these code generators were very sophisticated (e.g.
all used hand coded recursive-descent parsers). They varied in their
levels of capability. One of them could support joins but it took great
effort. Another supported joins but only inner joins. One was database
independent. The others were not.
The obvious theoretical problem from such an approach is the number of
possible queries is potentially [nearly] infinite. Thus, the number of
potential classes in the system is nearly infinite.
The obvious practical problems resulting from this approach included:
1. On all of these systems, most of the code was query classes. One
system had so many of them that it took two days to rebuild the
systems.
2. Each time the system needed a query, the developer either had to
concocted a new query class from the code generator or (even worse -
but more likely) they would piece together existing query classes to
get what they needed. Instead of one query with joins, you have nested
queries in the appllication. In investigating a performance problem in
one of these systems, it turned out the application was executing
400,000 queries where one would have sufficed. In several cases I found
code that walked through and counted rows in select queries rather than
doing "Count(*)".
Of course the "architects" for all of these systems were long gone
before the problems showed up.
So here's my question: Is there some source (book, magazine, etc.)
advocating such an approach to databases? It would strike me as an
unusual coincidence for so many projects at different companies to
independently arrive at the same stupid idea (and suffer the same
brutal consequences).
independently arrived at the same moronic design desision: The use of
SQL query classes.
No, I don't mean a class hierararchy like:
SQL Query
UpdateQuery
SelectQuery
Where you hide the details of the underlying database API. (Along the
lines of what Rogue Wave does.)
I mean a system where there is a sepate and distinct class used for
every query in the system. [What next, have employee virtual classes
from which you derive a separate class for each employee?????]
All of these have systems employed home-brew code generators. You give
it a query and it generates a class with a bunch of set and get
members. None of these code generators were very sophisticated (e.g.
all used hand coded recursive-descent parsers). They varied in their
levels of capability. One of them could support joins but it took great
effort. Another supported joins but only inner joins. One was database
independent. The others were not.
The obvious theoretical problem from such an approach is the number of
possible queries is potentially [nearly] infinite. Thus, the number of
potential classes in the system is nearly infinite.
The obvious practical problems resulting from this approach included:
1. On all of these systems, most of the code was query classes. One
system had so many of them that it took two days to rebuild the
systems.
2. Each time the system needed a query, the developer either had to
concocted a new query class from the code generator or (even worse -
but more likely) they would piece together existing query classes to
get what they needed. Instead of one query with joins, you have nested
queries in the appllication. In investigating a performance problem in
one of these systems, it turned out the application was executing
400,000 queries where one would have sufficed. In several cases I found
code that walked through and counted rows in select queries rather than
doing "Count(*)".
Of course the "architects" for all of these systems were long gone
before the problems showed up.
So here's my question: Is there some source (book, magazine, etc.)
advocating such an approach to databases? It would strike me as an
unusual coincidence for so many projects at different companies to
independently arrive at the same stupid idea (and suffer the same
brutal consequences).