-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noah Kantrowitz wrote: > On Jul 4, 2010, at 12:27 PM, Remy Blank wrote: > >> Terje S. wrote: [...] >> - I have read a few times that although a normalized database >> schema makes it very flexible and general, it also has a >> performance impact. From a layman point of view, having to join >> multiple tables has to be slower than not having to join tables, >> hasn't it? Again, I'm a noob in DB technology, so don't laugh too >> much if the question is stupid. > > Also remember that 1) most advanced features like triggers are not > standardized between server implementations enough to be useful and > 2) SQLite supports only the most basic of these features and is still > the default backend for Trac. IIRC SQLite parses but ignores FKs, so > we can't even depend on those. Also because the reports system > depends on humans being able to write simple queries, it is very nice > to have a more human-friendly schema.
I'm not an expert in the DB field, but wouldn't it be possible to have an abstraction layer to do needed table joining in background and not expect it from the admin or user setting up custom queries? IMHO this abstraction could become handy for migration to another DB schema as well. If it would be possible to do such an abstraction layer one could transparently replace the DB schema and proceed with migration to direct use of the new schema later and in steps. Steffen Hoffmann (hasienda) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwxqlcACgkQ31DJeiZFuHc8pwCfVKsQiWz53lyXYVTCE0yZbRuG 1HIAoMNotWigwVTYx3eQy71QcJGjgT1k =bFUj -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
