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.

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

But there are other concerns to be raised on using a denormalized schema.

KiokuDB doesn't so much use a denormalized schema as it uses no schema at all. Using the DBI backend for Kioku your schema basically looks like this:

sqlite> .tables
entries    gin_index
sqlite> .schema entries
CREATE TABLE entries (
  id varchar NOT NULL,
  data blob NOT NULL,
  class varchar,
  root boolean NOT NULL,
  tied char(1),
  PRIMARY KEY (id)
);
sqlite> .schema gin_index
CREATE TABLE gin_index (
  id varchar NOT NULL,
  value varchar NOT NULL
);
CREATE INDEX gin_index_ids_gin_index ON gin_index (id);
CREATE INDEX gin_index_values_gin_index ON gin_index (value);
[download]

I suspect (but I don't know for sure) that with this we can still take advantage of the concurrency inherent in the RDBMS we use.
-stvn