4 ms·
I think the attractions of object databases are: - It's easier to restructure than a relational schema in isolation - ORMs can be painful if you want to work li
by cratuki 19y ago
I think the attractions of object databases are:
- It's easier to restructure than a relational schema in isolation
- ORMs can be painful if you want to work like that.
But I think they're inherently slower for things like reporting.
The first item can be overcome with effective scripting (rather than trying to avoid the change necessary to restructure apps and schemas using relational databases instead embrace it and make schema changes easy) environment. And there are some OOs around that do a pretty good job of the second item (cayenne but I'm looking for one . I have had great experiences with using business logic layers around cayenne and have been able to rapidly refactor to achieve major schema changes like this.
Having said that - the allegro graph stuff looks like it might be a good alternative.
I'm currently interested in the idea of using couchdb while getting an app set up and then switching to postgresql later. Can anyone see any benefits or problems with this approach?
- ijoshua 19y ago"But I think they're inherently slower for things like reporting." I wouldn't say the deficiency is _inherent_, but the powerful indexing ability of a relational DB that we take for granted seems to be necessarily _ad hoc_ in an object-oriented DB. From my understanding, the index in an OODB is just another object in the database, which may be a B-tree, a hash table, or a simple sequential list. So far, that's fairly similar to the RDB. However, the indices in the RDB are closely coupled to the table that stores the records. The RDB "knows" that it should update the index when the table is modified. On the other hand, there isn't a table of records in the OODB, so there isn't a close coupling of the index to the data store. It may be entirely up to the application to manage the integrity of the index.