On Thu, 13 Jun 2002, Perrin Harkins wrote:

> As you can see it gets messy fast, and I didn't even cover the
> Mastercard part.  It would probably have terruble performance too.  This
> is why people usually just write this kind of report as a big SQL query
> instead.  You can make a model object called ConcertSeatSearch:
>
> @seats = Model::ConcertSeatSearch->findSeats(
>                                               reserved_after => $date,
>                                               payment_type   => $card,
>                                               user_state     => $state,
>                                              );
>
> Just be careful that you don't end up making this into something that
> mirrors the SQL exactly.  There might be 4 tables involved in finding
> out what kind of credit card the user had, but that gets hidden behind
> this API.  If you find yourself writing classes that take options like
> "where => 'date > ' . $date" you are reinventing SQL, and you've lost
> your abstraction.

This approach works for some things, but I think it falls down when it
comes to doing complex database searches, particularly searches generated
ad-hoc on multiple columns in multiple tables.

This is why Alzabo is much lower-level than what you have above.  I needed
something where I could easily construct queries that might include 1+
tables, with various types of searches of individual columns in those
tables (equal to, between, less than, like, etc.) with dynamic sorting
(again, on any of the columns in any of the tables, ascending or
descending).

With what you're proposing, I think you could easily end up with either:

A) a ridiculously flexible interface that looks sort of like SQL, except
where it is SQL, except where it's only sort of like SQL, etc.

B) a ridiculous profusion of classes, methods, or both.

SQL has its place, and Alzabo merely provides a thin layer on top of it.

Trying to jam a thick layer of OO-goodness over relational data is asking
for a mess.  OO has its place, but if your application is primarily about
the database, I don't think that a heavy OO layer on top of that will do
you much good.  And OO has a huge impedance mismatch with relational data
(irregardless of SQL or not).


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Reply via email to