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