[Catalyst] More natural access to model?

Matt S Trout dbix-class at trout.me.uk
Tue May 12 18:30:17 GMT 2009


On Tue, May 12, 2009 at 11:45:01AM +0200, Paweł Tęcza wrote:
> Dear Catalyst users,
> 
> It's my first post here, so I would like to say "Hello" to all of us! :)
> 
> I'm writing my first Catalyst application for student registration and I
> have the following tables for details about studies at our university:
> 
> CREATE TABLE studies (
>     id integer NOT NULL,
>     unit_id integer,
>     status integer,
>     limit_soft integer,
>     limit_hard integer
> );
> 
> 'id' column is a database study identifier. It's also primary key for
> that table. 'unit_id' is an unit identifier of study, 'status' column
> says whether registration is open/suspended/closed, 'limit_soft' and
> 'limit_hard' are for student number limits.
> 
> CREATE TABLE study_data (
>     study_id integer NOT NULL,
>     lang lang NOT NULL,
>     name text NOT NULL,
>     value text
> );
> 
> 'study_id' column is database study identifier (please look at
> studies.id column), 'lang' column points language for (name, value)
> pair, for example 'pl', 'en', etc. 'name' column is for name of data,
> for example 'name', 'description', 'program', 'email', etc.
> ('study_id', 'lang', 'name') is a primary key for that table. Finally
> 'value' column is for data content.
> 
> I think it's very simple structure and fully understandable for you,
> so it doesn't need more comments. Of course, I can also define
> table 'study_data' with many columns, for example 'name', 'description',
> 'program', 'email', etc. but I think that its simpler structure is
> better idea here, because it's more flexible. I can add new type of
> data, without changing table definition.

Well, that's a horrible idea.

The whole point of having a database is to -model- your data.

If you try and turn it into a giant hash, then of course you're going to
end up with nasty code.

I -could- explain how to clean that loop up a lot, but the reality is that
you should have actual columns for things and update your database as
required as new types of data need to be included - you'll have to update
the application anyway, so I don't see any reason not to update the database
at the same time ...

-- 
        Matt S Trout         Catalyst and DBIx::Class consultancy with a clue
     Technical Director      and a commit bit: http://shadowcat.co.uk/catalyst/
 Shadowcat Systems Limited
  mst (@) shadowcat.co.uk        http://shadowcat.co.uk/blog/matt-s-trout/



More information about the Catalyst mailing list