> This is probably by design...just thought I would ask. I don't know the answer to this as such (and am not speaking for Daemon) but here are some general comments (well probably more of a rave than anything)....
While I am sure there are some places in the FarCry schema that could have constraints created (see below), there are some inherent issues with a "generic" database design like FarCry that make constraints impractical. The main one is the "generic" nature of things like the object id's of all (most) of the FarCry objects. While you can say it is true that all object id's should be in the central table (what I like to think of as the "object register), the converse (all object id's in the object register must exist in one of the "other" tables) is not an easy relationship to define in the database itself (because, in essence, the database wont know WHICH tables it should enforce that constraint on - the constraints would have to be added dynamically). Similarly, the "tree" and "categorisation" core tables work in a similar manner. These types of relationships are known as "categorisation relationships" and are often symbolised on a relationship diagram as a circle with a line underneath it (at least they are when you draw them in Visio using IDEF1X notation). I haven't yet seen a database system that can enforce that as a constraint though. In addition to the above, one of the database servers supported (mySQL) in FarCry does not have a very good mechanism for enforcing constraints (and it is not enabled/installed by default). I also think it is only supported on one of the additional database sub-systems (which is not the "default" mySQL one). So that would cause major problems for installs of FarCry. Given all the above, I am guessing that it is definitely by design. The other "giveaway" hint is that the Admin Console provides tools to identify and repair orphaned records. This (almost) implies no constraints by design. Another good reason to not use constraints in FarCry is because it is loosely coupled. The relationships are very dynamic and indirect. Adding constraints would actually restrict some of that functionality in some cases. One place where a constraint might be useful though (with full cascade) is the relationship between a main object table and it's associated *_a* tables (the ones that FourQ provides as an array-of-structures mechanism for objects). But, since FourQ handles this for you programmatically there really isn't a need to implement it using a constraint. The other place constraints could be implemented is in the many-to-many joining tables (like refCategories or refContainers) as the relationships are clearly defined and are part of the core. However, people may be surprised by how many commercial/production systems out there that DON'T use constraints. A good example is Bugzilla (the bug tracking software running on PHP/mySQL). They have a "sanity check" that goes through and tells you what is and isn't hooked up. You then go into the DB and manually fix it. In the end, if the DB access layer software (in this case FourQ) is maintaining some of the important constraints and the application (FarCry) provides you some tools to deal with any other constraint violations (the orphan tools), then all bases are probably covered. Regards, Gary Menzel --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
