in reply to Is Perl Truly an Object Oriented Language?

I took quite a number of database classes in school, and they all dealt with relational databases. However, we covered OO databases, and from what I remember they are completely different from relational. For example,
select * from emps a, payroll b where a.empid = b.empid
would not work in an OO database, because this is using relational logic. I might be wrong here, because I've never worked with an OO database.
Also, we talked about the fact that OO databases are still very obscure, and in the opinion of my professors, there is a good reason they are. The idea behind them pretty much sucks. Somethimes I think people go a little overboard with the beauty of OO abstraction. Yes its cool, but there are lots of cases where OO is too much work and/or it's inefficient. That's why Perl is such a popular language, because its designer recognized that most people hate being constrained to a difficult and obtuse function, especially when it's inefficient.

Replies are listed 'Best First'.
Re^2: Is Perl Truly an Object Oriented Language?
by aerts (Initiate) on Dec 03, 2004 at 13:03 UTC
    To clarify the aspects of both types of databases a bit: I'm using an OO database at work stuffed with genomics data based on the AceDB database. The problem with object-oriented databases is that they (at least not AceDB) don't support relationships except when defined in the objects themselves. Let me explain: suppose you want to store the names of villages and the persons living in those villages:
    • in a relational database, you would create 2 tables: 'villages' and 'persons'. A truly relational way to create links between the two, would be to create a third table 'villages2persons', which holds only 2 columns: one with the IDs from villages and one with the IDs from persons.
    • in a OO database, there are objects from the class 'village' and objects from the class 'person'. The problem starts when making links: within every village object, a list of IDs from persons has to be kept AND in every person object, a village ID should be added. (Of course, there are workarounds, but then you're distracting from the OO setup of the database) Ergo: same information is stored twice. Ergo again: _very_ high change to create inconsistencies when updating data and stuff.

      Of course, you could solve this problem in the same way you solve it with a relational database, by introducing the Residency object (you called it villages2persons), and then navigating Village->Residency->Person to get at the persons of a village, but that way, you've just replicated the relational model onto the object database - which most likely isn't what was intended.

Re^2: Is Perl Truly an Object Oriented Language?
by exussum0 (Vicar) on Dec 03, 2004 at 03:34 UTC
    From what I understand, which may be wrong as always ;), is..

    sql: select book.* from author, book where author.id=book.authorid_id and author.name='bob'

    oo-sql: select author.books from author where author.name = 'bob'

    ----
    Then B.I. said, "Hov' remind yourself nobody built like you, you designed yourself"