Some minor corrections/clarifications:
* A. Pagaltzis <[EMAIL PROTECTED]> [2007-06-15 09:05]:
> document (
> id,
> )
>
> revision (
> id autoincrement,
> doc_id references document(id),
> num,
> )
This isn’t quite true, of course. There is more data in those
tables. Still, they’re both very sparse.
> And then there is a whole array of tables and join tables like
> the text_value/text_attribute pair for various data types (not
> DB-centric data types, but app-centric ones; eg. several tables
> with TEXT columns, where in one of them there is inline HTML,
> in another there are full HTML documents, in another there are
> just plaintext labels, etc.).
On re-read I realise this might be easy to misinterpret. Most
value tables have only a single value column. Thus I have
text_value ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT )
html_value ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT )
htmldoc_value ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT )
Etc.
And yeah, as Jess said, it’s DB-in-DB. I even have constraint
enforcement code in the app logic. I don’t do *everything* with
this structure though; I try to push modelling from the meta-
schema back down into the schema whenever feasible. If nothing
else, it makes it much easier to query the beast: working with a
supernormalised schema like this one is a right pain if you want
to query on it. I try to have all the data I need for joins
available directly.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
