4 ms·

In my experience, keeping objects consistent is easier than keeping the database consistent. The database can only do trivial consistency checks. With objects y

by jules 18y ago

In my experience, keeping objects consistent is easier than keeping the database consistent. The database can only do trivial consistency checks. With objects you can write arbitrary predicates that check things about your objects. In the applications I write that means that even though I use a relational database, I end up doing all important checks on the objects, and none in the DB.

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 ago
  Actually, 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 ago
    Actually, 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 ago
      I 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 ago
        Complex business logic constraints depend on "the object model and polymorphism"? Can you give an example?
        gnaritas 18y ago
        Objects 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.
silentbicycle 18y ago
> I end up doing all important checks on the objects, and none in the DB. Databases, particularly relational databases, have a LOT of functionality specifically for enforcing constraints and consistency checks on data. You will almost certainly need to organize your schema differently, but you can delegate a lot of that checking onto the database engine, and it will probably speed everything up -- you'll be passing quite a bit less data back and forth just to verify it, and databases are generally optimized heavily for that sort of checking. (Databases are also great at dealing with data as collections, unsurprisingly.) All bets are off if you're using a really crappy RDBMS, though. (Postgresql is quite good, in my experience.)

by jules 18y ago

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 ago
Actually, 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 ago
  Actually, 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 ago
    I 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 ago
      Complex business logic constraints depend on "the object model and polymorphism"? Can you give an example?
      - gnaritas 18y ago
        Objects 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.

silentbicycle 18y ago

> I end up doing all important checks on the objects, and none in the DB. Databases, particularly relational databases, have a LOT of functionality specifically for enforcing constraints and consistency checks on data. You will almost certainly need to organize your schema differently, but you can delegate a lot of that checking onto the database engine, and it will probably speed everything up -- you'll be passing quite a bit less data back and forth just to verify it, and databases are generally optimized heavily for that sort of checking. (Databases are also great at dealing with data as collections, unsurprisingly.) All bets are off if you're using a really crappy RDBMS, though. (Postgresql is quite good, in my experience.)