http://www.perlmonks.org?node_id=752755


in reply to Re^4: Reflections on the design of a pure-Moose web app...
in thread Reflections on the design of a pure-Moose web app...

And why would one want to do that if not for having persistant objects?

A relational database is just one way to store objects (and a very poor one at that). There is and have been better alternatives out there for many years, so the idea that you should ever have to go through that is just silly. If you choose to, or if your requirements dictate that you do, that is different, but you certainly don't have to use a RDBMS, it is just the most commonly chosen knee-jerk design decision out there.

Languages like Smalltalk and LISP have had OODBs for a long time now and they are used very successfully in lots of real world mission critical apps. And even Java and .NET have a pretty decent and successful OODB out there as well. And Cocoa nib files are really just archived object graphs that the Cocoa framework unarchives when needed.

Perl now has KiokuDB, a production-ready alternative to ORMs that does not suffer from impedance mismatch or any of the other annoying compromises that ORMs force you to make.

My point is really that using a relational database as a dumb object store is neither good OOP or good database-ing. The right tool for the right job, which IMO is exactly what the OP did here.

-stvn

Replies are listed 'Best First'.
Re^6: Reflections on the design of a pure-Moose web app...
by ruoso (Curate) on Mar 24, 2009 at 17:10 UTC

    While KiokuDB is a neat project, most of the time, in my case, I take advantage of my relational database, not every operation is simply store and fetch, but very often I see myself doing most of the business logic in terms of the relational model.

    I'm not that all against KiokuDB, but it solves a different issue than DBIx::Class... In my case, I mostly can't allow myself using KiokuDB because I need my relational database to work as a relational database.

    daniel

      Well, yes, if you need a relational DB, then you need something like DBIx::Class or Fey. But even this does not prevent you from also being able to use KiokuDB. I am currently working on a project where my objects are stored in KiokuDB using the KiokuDB::Backend::DBI backend and I am using Fey to access my non-object, relational data.

      The reason for this is that to model my objects in the RDBMS would result in an explosion of tables and a duplicated metadata which wouldn't really be useful to me because that data is only meaningful when it is in object form, not when it is sliced and diced into a bunch of relational tables.

      The rest of the app has relational data that makes little or no sense as objects. Just as with the above, putting this relational data into objects would result in an explosion of classes and duplicated metadata none of which would be useful for me, and would only make manipulating this data tedious and difficult.

      The right tool for the right job, that is all I am saying really. Too often people just assume "okay, I need a RDBMS" when they want to save data and don't really consider other forms of persistence. This is becoming an increasingly precarious assumption the more people use ORMs and model their business objects in pure OO rather then SQL.

      -stvn

        Indeed. There are a lot of applications which data is never traversed in a relational way. But there are other concerns to be raised on using a denormalized schema. Concurrency being the most important IMHO, database systems like PostgreSQL do a great deal of effort to behave nice and easy with a lot of concurrent access, but you can only benefit from it as long as your database is kindly normalized, otherwise there isn't much that can be done.

        But I can't really say at which extent it matters, to which kind of application, at which volume of access. But at least as far as my experience goes, most of the time the bottlenecks are on the persistency, and there's a lot of science in making RDBMS scale.

        Of course I'm not talking about the "solve the RDBMS scaling issue with memcached" paradigm.

        daniel