On Jul 5, 2010, at 11:47 AM, Terje S. wrote:
On Sun, Jul 04, 2010 at 12:35:36PM -0700, Noah Kantrowitz wrote:
Also remember that 1) most advanced features like triggers are not
standardized between server implementations enough to be useful and
I absolutely agree that vendor-specific solutions are a big no-no,
however
triggers do not always fall in this category. Granted, the syntax is
different, but they react to events on the data in all cases. I'm not
proposing any major use of them for the standard model, but there may
be a few cases where they prove useful down the line.
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.
Fortunally as of 3.6.19 this is no longer the case, foreign keys are
supported! That's been out for over a year, so conceivably we will not
have to worry about older SQLite at 1.0 release time anyway ;-) So
by now,
SQLite supports all the major requiremens, plus can be tweaked
with use of attach, memory databases etc if it should prove
neccessary.
Supporting older SQLite will require to rewrite the most important
foreign keys as triggers for those versions.
On a sidenote, I would argue for a general reccommendation of postgres
for the future versions. It is a much better fit for the multi-user,
database-centric solution required to support the multiproject,
distributed and such capabilities.
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.
Ah, but the database designers have thought of this, as Steffen
mentiones in
his post. The data model needs fully normalized tables at the
bottom, and
views (+ other tricks) are layered on top, to abstract the hard
parts away.
In fact, given example SQL, I'm sure most users would like the
increased
reporting capabilities across different work units in a hierarchy,
even if
it means they have to unlearn the old ways.
At least, several major software packages have happy users with such a
systems, so I can't see why we would be unhappy with it? :-)
Name one such system that expects users to write direct SQL? Not to be
rude, but this all sounds very much like it is coming directly from a
book about DB theory, not from a practical assessment of what would
help Trac improve. The only real bonus anyone has come up with to
"fix" our schema is that it would be easier to transition to
SQLAlchemy as an ORM. That has been a rather contested feature, and as
of yet I don't think any work has been done on it (SQLAlchemy as a
connection broker is a different thing entirely). DB performance has
never really been of major importance for Trac one way or the other,
mostly because our storage needs are rather simple in nature. The
current system hasn't particularly limited us or plugin devs that I
know of, so I'm not sure why this is even being discussed, it seems
like a pretty cut and dry issue to me. If you want to talk about
moving Trac to an ORM (SQLAlchemy, Storm, etc) thats a different
issue, but don't drag relational modeling and normalization into it
because those are really non-issues.
--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.
