I've started to write an answer and then a power outage killed my answer
on half way. Rewritting from scratch now...
On Mon, Dec 03, 2001 at 02:53:31PM +0100, Emiliano wrote:
> > 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.
> a) OK, so you can't use foreign keys everywhere, that doesn't mean you
> can't use them anywhere
True.
> b) don't tell me you think the extra etc fields are a good idea. I think
> we still have them because they were in the first release. Were we to
> redesign the entire database today I'd certainly argue to have them
> removed in favor of a more general mechanism.
We already have too much things in DB which would be removed but still
maintain them due to legacy issues. I don't think that these fields or
functions are good, but conversion is a way harder. For example, recent
thread in cyrillic@ raised some problems with strictness of article names
(non-emptiness). There are several sites already in production where
emptiness of article names was used as indicator of article's belonging.
And this kind of legacy stops us from more revolutional changes as well.
> IOW the places where we can't use enforced integrity rules are exactly
> the places where I think the midgard database design is flawed.
It may also mean that selection of underlying data storage is wrong,
not just structure of the database. By introducing parameters or other
extensions of objects we are trying to workaround existing problems in
relational database philosophy rather than to make reference integrity
easier. I know, this was covered in our previous discussions about
Midgard2 but it is a little edge of whole problem.
> > This just means that relational databases in Midgard's case are not good
> > choice for storage.
> Well, that's like the old saying "the X window system is the second
> worst display system in existance, with all others tied for third". As
> soon as anything better turns up, I'm game. In the meantime we have to
> use what we have in the best way we can. I'm not proposing to jump in
> with refint checking right now -- the installed base of mysql 3.x
> servers is too large for that. But as soon as mysql 4.x is 'the'
> standard database out there, yes, I'd absolutely be in favor of using
> the strength of the database where possible.
May be. Though proposing reference integrity be a part of core design may
low portability across different databases. What to do if some user will
want to place Midgard database into MySQL's type different from Innodb
where such syntax will simply cause parse errors? I'm not against it, I'm
for better design of its integration.
--
/ 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]
