Re: OO and relation "impedance mismatch"

Kenneth Downs wrote:
> > Presumably you don't mean that the tables wouldn't ALSO have
primary,
> > unique, foreign key constraints do you?
>
> Correct, they would not also have the constraints. The purpose is to
> completely control error reporting and have it behave the same way
across
> all platforms, and declarative constraints don't let me do that.

Well I don't agree with that. Have triggers IN ADDITION to the constraints if you like, to improve the "user experience", but I would NEVER dispense with such fundamental integrity constraints as primary keys, foreign keys etc. Why?

• Database constraints ensure integrity in a "foolproof" and performant manner
• It is extremely difficult (if not impossible) to write such constraints in procedural code. How do you prevent 2 users simultaneously entering a record with the same "primary key" if you don't have a primary key (or unique) constraint? Do you lock the whole table during insert statements?
• Database constraints can be used by the optimizer to determine the best query plan

No, what you are doing is throwing away decades of development by the DBMS vendors and making yourself decades of work, plus a database that won't perform as well as it should, and will likely have plenty of data corruption in it.

IMHO, I suppose I'd better add! Received on Tue Oct 05 2004 - 10:32:43 CDT