Re: Mixing OO and DB
Date: Tue, 4 Mar 2008 12:01:56 -0800 (PST)
On Mar 4, 10:10 am, Gene Wirchenko <ge..._at_ocis.net> wrote:
> Robert Martin <uncle..._at_objectmentor.com> wrote:
> > or
> >find_by_name_and_department("Bob", "Accounting");
> >I'm sure you can think of some others that would read nicer than the SQL.
> Now throw another column into the mix. How many methods are you
> going to end up with? What will you have gained?
Now let's consider what all the combinations are. If we have
a single table with ten columns, then we have 1024 possible
column lists, so if we want a class for each such we need
Now let's consider what all the combinations are. If we have a single table with ten columns, then we have 1024 possible column lists, so if we want a class for each such we needa thousand classes. We also have to consider how many "find" methods we need. This is a function of the number of columns involved in the selection predicate (which is not the same set as the column list), and a function of how many function there are defined over that set of attributes. So if you want to select using function f on columns A and B, that's a find method, and you want to select on function g on columns C and D, that's a find method, and if you want to select on f(A, B) AND g(C, D) that's another find method, and if you want to select on f(A, B) OR g(C, D) that's another find method. Times the possible column sets.
You won't want all of those. Just a smallish subset. But every time you want a new one, you need a new class if the column set is different, and at least one new method.
What if we want to actually JOIN? If we limit ourselves to just two tables, we have to consider, again, all the possible column sets, (now 2^20, so a million possibilities instead of a thousand) and all the possible join conditions, in addition to all the possible WHERE conditions. Did I mention GROUP BY yet? And we haven't even really started to approach any *fancy* SQL.
Some problems are handled nicely by an API. Some aren't, and need an actual language. Things that need a language don't make good APIs. Consider something as comparatively low-power as regular expressions, and try to write an API for them. It's just a really bad idea. Now try to write an API that's as powerful as Java. It just doesn't make sense. Instead these problems are handled with a real *language*.
Marshall Received on Tue Mar 04 2008 - 21:01:56 CET