3 ms·
> In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that wor
by ken 8y ago
> In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that worked out.
What am I supposed to know about this? I've only used an object database for one serious (>100KLOC) project, but it was by far the best part of that system. I always wondered why that architecture never caught on.
The only reason I'm not using an ODBMS on my own projects today is that there's no good open-source one, but that seems like something a company could do something about, and a lousy reason to condemn an entire architecture.
- anonetal 8y agoOrientDB is a good open-source database that exposes a primarily object data model (the document and graph abstractions are built on top of it). Lack of a good query language and scalability issues doomed those. Mike Stonebraker (https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1ea9e https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1...) had a nice summary in that article.
- ken 8y agoThere are 4 reasons proposed for the failure of OODBs, in that paper, but scalability is not among them. Interestingly, the issues are largely C++-specific (and I know lots of people using an ORM today but none via C++), and largely driven by historical accident and market forces ("It is interesting to conjecture about the marketplace chances of O2 if they had started initially in the USA with sophisticated US venture capital backing"). I still don't think these sound like good reasons to dismiss the architecture.
- lvca 8y agoI agree that a pure ODBMS makes no much sense today, but OrientDB is a Multi-Model where the Object Model is one of the supported models. You can mix objects, graphs, schema-less documents and much more + using SQL as the query language. Boom! (Disclaimer: I am the founder of OrientDB)