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? :-)

Terje

-- 
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.

Reply via email to