[Catalyst] More natural access to model?

[Matt S Trout]

On Tue, May 12, 2009 at 08:04:18PM -0700, Darren Duncan wrote:
> Paweł Tęcza wrote:
> >Dnia 2009-05-12, wto o godzinie 19:30 +0100, Matt S Trout pisze:
> >>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 ...
> >
> >Intriguing post. My application and database design are still under
> >heavy development, so all ideas, suggestions and comments are very
> >welcome :D
> 
> A general rule of thumb is that you should be conceptualizing your 
> databases similar to how you conceptualize your applications.
> 
> Your database schema, such as what tables you have, and their columns, and 
> their column data types, and the relationships between tables and columns 
> etc, these are like program code, such as how you choose to decompose your 
> application into libraries and classes and class attributes and type 
> constraints and input constraints and so on.  The actual data you put in 
> your database tables is analogous to what data you put in your application 
> variables or objects.
> 
> Generally speaking it should be natural to change your actual database 
> schema as often as you change your application source code, where it makes 
> sense; for example, changing your schema is a similar sort of operation to 
> changing what attributes your object classes have or your constraints.
> 
> Or more accurately in practice, a database is more like (or in some cases, 
> exactly like) a shared library, where you have some classes you write once 
> and share in multiple applications, and if you change the library you have 
> to consider that impact on all the applications that use it.  Hence people 
> tend to be more conservative in database design changes, but still one 
> shouldn't be afraid to do it, and all you really need is just proper 
> communication and planning between the involved parties so it goes smoothly.
> 
> Also, same as classes can have multiple APIs, eg keeping old ones for 
> backwards compatibility if old apps can't update, databases have things 
> called views / virtual tables which let them also have multiple APIs; this 
> is one of the main purposes of views in fact.

Too bloody right. Care to shove this on the catwiki somewhere?

-- 
        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/