Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

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

by stvn (Monsignor)
on Mar 26, 2009 at 21:12 UTC ( #753514=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^7: Reflections on the design of a pure-Moose web app...
Re^8: Reflections on the design of a pure-Moose web app...
by ruoso (Curate) on Mar 30, 2009 at 20:00 UTC

    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);
      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://753514]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2014-07-28 12:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (197 votes), past polls