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. -- Remy
signature.asc
Description: OpenPGP digital signature
