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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
