http://qs321.pair.com?node_id=754238


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

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
  • Comment on Re^8: Reflections on the design of a pure-Moose web app...

Replies are listed 'Best First'.
Re^9: Reflections on the design of a pure-Moose web app...
by stvn (Monsignor) on Mar 30, 2009 at 23:49 UTC
    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);
    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