[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