Howie wrote:
>
> actually, one would hope that the system has its db independence in the
> application layer rather than the database layer. for instance, using
> something like NeXT's Enterprise Objects Framework to fetch rows from the
> db and translate the rows into objects, you only deal with the objects.
> The whole datastore, at this point, becomes irrelevant since you rarely
> deal with the underlying SQL -- EOF takes care of all that for you.
> Instead, you say "hey, i want all the objects that have their personName
> ivar equal to Amy" ( "personName = 'Amy'" ). I'm fairly positive that
> Sun's Java equivalent of EOF ( 'Entity Javabeans', iirc ) does the same
> sort of thing.
>
Well, you are approaching from an application developer's point of
view. You want to have database independence so you can move back and
forth between all the flavors of databases out there. ODBC was meant to
address this issue, and we all know there are still limitations.
However, even then database independence doesn't make the discussion of
stored procedure irrelevant. Given a better tool to do something,
wouldn't you use it? If you have to deal with databases ranging from
Access to Oracle, are you going to make your application based on Access
capability, since it doesn't have a PL? More than likely you are going
to design one version for Access & another for Oracle...
From business's POV, application layer is _not_that_ important because
production databases (especially OLTP databases) are seldomly moved.
Even today the commercial vendors finding themselves supporting the
legacy versions. In this sense the capability of the database itself
becomes that much more important. For the database administrators, the
ability underneath the application layer is very important indeed.
Certainly SP offers a lot of horsepower :)
Regards,
yin-so chen