On Mon, Dec 03, 2001 at 02:24:10PM +0100, Emiliano wrote:
> I don't buy these arguments. It's easy enough to dismiss that which you
> haven't (yet) implemented for whatever reason. I don't hear any Oracle
> or PostgreSQL (etc) complaining about the restraints of using enforced
> referential integrity checks. Good database design isn't necesarily
> easy, and anything which makes it easier to go ahead while having major
> flaws in your design (which is what they're outlining here) is an
> inherently Bad Idea IMNSHO.
These are generalizations. In our particular case we don't achieve
anything with these foreign keys in MySQL. We do that with Repligard's
integrity checking instead. Moreover, our database structure has fields in
some tables (article, for example) which do have variable referencing
nature and thus cannot be covered easily by foreign keys at all.
For example, extra? or icon,print,view fields in article table can be and
used by many sites to reference external (for article table) data in the
database depending on developer's approach. They store ID information for
some table but full reference information isn't known for MySQL (or any
other database) because it may vary on, for example, type field of
article.
This just means that relational databases in Midgard's case are not good
choice for storage.
--
/ Alexander Bokovoy
$ cat /proc/identity >~/.signature
`Senior software developer and analyst for SaM-Solutions Ltd.`
---
Nov 21 20:58:58 alconost kernel: VFS: Busy inodes after unmount.
Self-destruct in 5 seconds. Have a nice day...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
