I learned how “object-oriented databases” worked in college. After 20 years of work, I still don’t know if such a thing exists at all. I read books regularly instead.
Eplan, electrical controls layout tool, used an object oriented database as its file format, It still may. I saw recently that they entered a partnership of some sort with SolidWorks, so they’re still kicking.
I’ve used one before. Maglev is a ruby runtime built atop GemStone/S, which is an object db. Gives Ruby some distributed powers, like BEAM languages (Elixir and Erlang) have.
Practically all it meant was you didn’t have to worry about serializing ruby objects to store them in your datastore, and they could be distributed across many systems. You didn’t have to use message buses and the like. It worked, but not as well as you’d hope.
Amusingly, BEAM languages, have access to tools a lot like oodbmses right out of the box. ets, dets, and mnesia loosely fit the definition of an oodb. BEAM is functional and doesn’t have objects at all, so the comparisons can be a tad strained.
Postgres also loosely satisfies the definition, with jsonb columns having first class query support.
I learned how “object-oriented databases” worked in college. After 20 years of work, I still don’t know if such a thing exists at all. I read books regularly instead.
Wiki says they existed, and may still do… never come across one. I thought mongodb might be one but apparently not.
Eplan, electrical controls layout tool, used an object oriented database as its file format, It still may. I saw recently that they entered a partnership of some sort with SolidWorks, so they’re still kicking.
I’ve used one before. Maglev is a ruby runtime built atop GemStone/S, which is an object db. Gives Ruby some distributed powers, like BEAM languages (Elixir and Erlang) have.
Practically all it meant was you didn’t have to worry about serializing ruby objects to store them in your datastore, and they could be distributed across many systems. You didn’t have to use message buses and the like. It worked, but not as well as you’d hope.
Amusingly, BEAM languages, have access to tools a lot like oodbmses right out of the box. ets, dets, and mnesia loosely fit the definition of an oodb. BEAM is functional and doesn’t have objects at all, so the comparisons can be a tad strained.
Postgres also loosely satisfies the definition, with jsonb columns having first class query support.