5 ms·

Tons of first hand experience and expert research says that relational normalization is the best way to avoid mistakes. > If your in-memory data doesn't make s

Tons of first hand experience and expert research says that relational normalization is the best way to avoid mistakes. > If your in-memory data doesn't make sense, then who cares what's stored? You are going to screw up your in memory data structures in a complex application. It WILL happen. A normalized relational schema will catch the mistake. You can go 3NF, with decades of experience and theory. Or you can wave your hands and say "don't make mistakes" in your hierarchical/oodb system. If you need simple persistence for an app that will be dead inside a few years, go knock yourself out with an OODB. It will work fine. If you're doing something complex, like say the equivalent relational DB would have a few dozen tables, I think it's foolish. You really probably aren't smarter than the collective experience that has successfully settled on the relational model.

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.)
jrockway 18y ago
You really probably aren't smarter than the collective experience that has successfully settled on the relational model in recent decades. The same collective that thinks Java is the right thing for teaching, research, and industry? </strawman> But seriously, the industry at large is usually about 40 years behind the state of the art. Look at all the features that your programming language of choice doesn't have, even though we've known them to be good ideas for 40+ years. Finally, data is not some sacred thing that is set in stone forever. If you need a different schema for a different application, then translate it. When I worked in data warehousing for a large advertising company, we had to translate the data that was collected from the ad servers and translate it to a variety of forms; one for archival analysis with specialized tools, and another for showing the data in the web interface. The schema that could cope with tracking millions of hits a minute did not do well for the off-the-shelf analytics tools or the web UI. (We used relational databases for all three systems, but we didn't have to. The only thing that had to be a relational database was the off-the-shelf software.)
- silentbicycle 18y ago
  For what its worth, "What language is the the right thing for teaching, research, and industry" is a complex (and, ultimately, pretty ill-defined) question, but "What techniques can be used to organize information whose internal consistency must be mathematically verifiable?" is not.
  - arohner 18y ago
    Naive question: what mathematically verifiable properties do current SQL DBs have that current OODBs cannot? Also remember that strictly speaking, the following things are not the same: modern SQL DBs, all RDBMSes, and pure relational theory. I can easily imagine an RDBMS that does not use a SQL interface, and modern DBs are not the same as the Codd's pure conceptual work.
    - deleted 18y ago
      [deleted]
    - 18y ago

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.)

jrockway 18y ago

You really probably aren't smarter than the collective experience that has successfully settled on the relational model in recent decades. The same collective that thinks Java is the right thing for teaching, research, and industry? </strawman> But seriously, the industry at large is usually about 40 years behind the state of the art. Look at all the features that your programming language of choice doesn't have, even though we've known them to be good ideas for 40+ years. Finally, data is not some sacred thing that is set in stone forever. If you need a different schema for a different application, then translate it. When I worked in data warehousing for a large advertising company, we had to translate the data that was collected from the ad servers and translate it to a variety of forms; one for archival analysis with specialized tools, and another for showing the data in the web interface. The schema that could cope with tracking millions of hits a minute did not do well for the off-the-shelf analytics tools or the web UI. (We used relational databases for all three systems, but we didn't have to. The only thing that had to be a relational database was the off-the-shelf software.)

silentbicycle 18y ago
For what its worth, "What language is the the right thing for teaching, research, and industry" is a complex (and, ultimately, pretty ill-defined) question, but "What techniques can be used to organize information whose internal consistency must be mathematically verifiable?" is not.
- arohner 18y ago
  Naive question: what mathematically verifiable properties do current SQL DBs have that current OODBs cannot? Also remember that strictly speaking, the following things are not the same: modern SQL DBs, all RDBMSes, and pure relational theory. I can easily imagine an RDBMS that does not use a SQL interface, and modern DBs are not the same as the Codd's pure conceptual work.
  - deleted 18y ago
    [deleted]
  - 18y ago