[Catalyst] More natural access to model?

[Darren Duncan]

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.

-- Darren Duncan