[Catalyst] More natural access to model?

[Paweł Tęcza]

Darren Duncan pisze:
> Paweł Tęcza wrote:

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

Hello Darren,

At first, thank you very much for your advices! There are really very
valuable for me.

Yes, I'm trying to think about my data as about the objects with
attributes and create simple and flexible database without data
redundancy. For example, I have tables for users and their roles,
studies, units, registrations. I also have tables for multilanguage
attributes of studies and units. Finally, I have tables for
relationships beetwen users and their roles, units and their attributes,
studies and their attributes, etc.

I'm very curious what database schema is the best for me in your
opinion. Of course, I don't ask you for desing of the whole database.
But could you please show me what tables I should create to store
information about studies? :)

Please remember that a study has a lot multilingual attributes (name,
description, duration, fee, etc) and non-multilingual attributes
(student limits, dean's office, its address, phone number, fax and web
site, study manager, his name, e-mail, and phone number, etc).

Have a nice weekend,

P.