On Jul 4, 2010, at 12:27 PM, Remy Blank wrote: > Terje S. wrote: >> All that said, I hope I did not offend or kill anyone with the lengthy >> amounts of text in this post. I realize it may be outside the Trac >> philosophy, scope, or simply beating a dead horse.. So be it! > > Thank you for your constructive criticism. No, you didn't offend anyone, > and your comments are certainly valid. > > My guess (I wasn't there when it started) is that none of the project > initiators was a database expert, and so they did the simplest thing > that would work, which retrospectively wasn't so bad but still not ideal. > >> I would be happy to contribute to modelling as best I can, but I'm not sure >> when the team can consider such fundamental philosophical and architectural >> changes, if at all? (it does imply a more or less complete rewrite) > > I'm sure your input would be highly appreciated. None of the current > developers is a DB expert either (AFAIK, I'm certainly not one, quite > the opposite), so any help is welcome. > > I have two concerns with such a restructuring: > > - Even if a complete migration requires a complete rewrite, is it > possible to migrate progressively from the current to the new structure? > I don't believe in big, monolithic rewrites, as they are a sure way to > stall the project for a long time. Say, we introduce the concept of a > "project" in 0.13, we should design it according to the new structure, > and integrate it with the old structure. Or migrate one subsystem (e.g. > milestones) to the new structure, at the same time as we add a new > functionality (e.g. milestone versioning). > > - 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. --Noah -- 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.
