On 20 Jan 2006, at 18:38, Ralf Joachim wrote:
It's simple but will require quite some time to implement. I think
with
the planned refactoring of SQL generation we should also take care to
include this featur.
I'm going to have a punt, with a big IM(notashumbleasitshoulddbe)O
attached to it, and say the opposite:
- Databases are uniquely ugly beasts, at their prettiest. Each
database will perform best when its owners spend time thinking about it.
- Table generation will require additional hurdles in syntactical
differences between databases
- Then we've got to regurgitate foreign key constraints...
- Then we have to cover index building, and under what
circumstances the system would need indexes...
etc.
I've got to be honest here: A lot of people spend a lot of time
maligning the performance of things like Hibernate, and never once
stop and look to see whether or not they're doing things that their
DBA would flat out shoot them over; they expect the software to be a
replacement for a DBA.
It won't be. It can't ever be. It won't make half as good a set of
decisions.
The power of Castor is in it's flexibility; our ability to strap on
just about any SQL schema and get a useful object hierarchy out of
it. If the optimal implementation of my object hierarchy conflicts
with my optimal data representation, that's for my DBA to solve
through views, calculated indices, and whatever other tools my DBA
has available.
So, in reality, we'd only ever get as far as the first step - maybe
also foreign key constraints. But we'd be forever neck deep in bugs
akin to "this doesn't work on database version X" and "my performance
sucks because I generated db schema" mail. Ultimately, the best
thing about mapping, and a lot of people aren't going to agree, but
hey, that's life, is that it requires people to think about the way
they're structuring their data. If someone goes and creates a bunch
of text flags, and stores them all in a varchar instead of using a
foreign key to another table, he's going to take it on the nose.
When forced to look at how the data is being stored, your average
programmer *will* think "I'm spending an awful lot of disk space on
attaching the word "PENDING" to a new row in that table, maybe I
should be using a lookup table for that.
We shouldn't try to solve this problem in Castor - leave the domain-
specific knowledge of databases to DBAs whenever possible, IMO. We
do a really good job now of covering just enough of the hurdles to
get data into the system in a smart way, without having to cross the
line into the actual data structuring role; IMO, it's best to leave
it that way - leave the domain specific knowledge to those who have
it, rather than trying to replicate a miniature DBA in code.
And if someone really that desperately wants to avoid learning CREATE
TABLE... then they're never going to be happy with the product,
because they're never going to be able to understand why some things
are fast in a database, and why some things aren't - and will do
exactly what most of the people with a negative opinion of Hibernate
do: say "its performance sucks" and walk away, without ever once
having to rub two brain cells together in the hopes of making a
fire. :)
But that's just me. :)
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
