13 ms·
The database can only do trivial consistency checks. Between foreign keys, triggers, and CHECK constraints, databases can actually do pretty sophisticated cons
by neilc 18y ago
The database can only do trivial consistency checks.
Between foreign keys, triggers, and CHECK constraints, databases can actually do pretty sophisticated consistency checks. There's also a SQL standard feature for database-wide assertions that would be very useful, but AFAIK no one implements it (probably for performance reasons).
- gnaritas 18y agoActually, no, it can't, unless you code all your business rules into the db as well. The advantage the objects have is that they're also the application and all the rules are there and checkable.
- neilc 18y agoActually, no, it can't, unless you code all your business rules into the db as well. Well, you can code all your business rules into the DB, in the form of stored procedures. But even if you choose not to, I don't see why that fact prevents you from enforcing a wide range of consistency constraints in the database.
- gnaritas 18y agoI didn't say you can't do any checks, rather, the db does mostly simple checks. The complex checks often depend heavily upon the object model and use of features like polymorphism which relational databases suck at modeling.
- neilc 18y agoComplex business logic constraints depend on "the object model and polymorphism"? Can you give an example?
- gnaritas 18y agoObjects can validate themselves and object databases store the class as well as the instances. This allows a database to contain a mix of different versions of a particular class of objects. The invoice from yesterday might have 5 fields and validate under one set of rules while todays invoice has 7 fields and validates itself under a completely different set of rules. Such polymorphism is trivial to implement with objects and very painful to implement withing a relational database. It's not a matter of whether a RDBMS can model something, it's a matter of how much effort is required.