The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

On object databases

I originally posted this on the regular "Joel on Software" board, but maybe this one is more appropriate:

http://discuss.joelonsoftware.com/default.asp?joel.3.42979.12

I recently got feedback on this from my uncle, who's a former Microsoftie and has executive friends at large software corporations (so he's very capable of being brutal about new ideas).  He essentially told me not to keep wasting my time on this, as there are hundreds of other projects out there that are like this.

He called it an "object/relational mapper", but I've always thought that people are generally talking about ways to persist objects to relational databases when they say that.  This is more like a container for objects (like std::list or std::vector) which just happens to support relational operations and can be treated like a database.

What do you guys think?  Is this a futile path or is there something valuable here?
Kalani Send private email
Wednesday, December 15, 2004
 
 
"He called it an "object/relational mapper""

I always think of an object/relational mapper going in the other direction.  That is, it's a way to use object (and containers) and persist them to a database.

This is more like table-oriented programming (google it) where tables are first-class data structures and SQL queries are used to operate on them.

I find this to be very interesting; there are lots of tasks where a table-based approach would make sense. 

I'm not sure it's valuable for anything other than a toy -- it really depends on how flexible and usable it could become.
Almost Anonymous Send private email
Wednesday, December 15, 2004
 
 
Thanks for the phrase, I've got a lot of interesting sites to read in google.

As far as flexibility -- I'm not exactly sure what you have in mind but this system already works with any object that can be represented in my little script interpreter.  That includes OLE objects (e.g.: Active X controls or random VB objects).

But there are still a number of features to add to the query language itself.
Kalani Send private email
Wednesday, December 15, 2004
 
 
Well that's pretty flexible!
Almost Anonymous Send private email
Wednesday, December 15, 2004
 
 
You're not the only one to go down this path. The people who built the IP*Works library recently announced their Internet ADO.NET provider. With it, you can query your pop3 server using SELECT statements.

Have you thought about going the ADO.NET provider route?
Chris Tavares Send private email
Wednesday, December 15, 2004
 
 
Post it on http://www.lambda-the-ultimate.org and I'm sure someone will dump reams of literature about precisely what you're doing and ways to improve it.

Wednesday, December 15, 2004
 
 
I'd view it more like SQLite meets old-school object databases.
Flamebait Sr.
Thursday, December 16, 2004
 
 
Kalani,

No matter what your uncle says (or others for that matter) there's only one way to walk your own path: walk your own path; there's no better way to learn but your own experience (there are only ways to speed up the learning process, but you can only learn from experience).

Back to ODBs. The problem with ODBs is not that much storing the objects in a repository, but querying through the repository. The query operation requires you to either break the object encapsulation (that is what ORM tools do) for building indexes and fast querying artifacts; alternatively the encapsulation can be preserved at the cost of performance.

True object databases do not query fast.
Dino
Monday, December 20, 2004
 
 
Dino, thanks for the support, I really appreciate it.

I don't think that my system breaks encapsulation (unless the object is designed in such a way that encapsulation is broken).  It's essentially just another container system like std::list or std::vector, except that you can do joins and update/select/delete according to constraints on object properties.  For example, in the demo program you can delete all windows whose "left" property is 20.  This doesn't break the encapsulation provided by the window system (hiding OS window handles and a big fancy message pump and so on).

I haven't really optimized it for speed, although in principle there are a lot of optimizations that I could make.  I mostly made it so that certain tasks would be much easier (performing operations on aggregations of objects in my little video game).
Kalani Send private email
Monday, December 20, 2004
 
 
Oracle has an object-relational database already, where you can create canonical objects, and store them (I hate using the word persist when store is available (:=)) in relational tables, using normal SQL, with some extensions. How is what you're doing different?
Stephen Hirsch Send private email
Tuesday, January 04, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz