On Monday 03 December 2001 18:56, you wrote: > > 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.
And at some point we'll have to deal with them. Rather than keeping them it'd be more productive to talk about how to solve the issue behind it. And having fields do double-duty (with a special state of the variable having a specific meaning) is a well-known oops-shouldn't-have-done-that (like the y2k issue). It's something you want to find a good solution for (and yes, that includes a good solution for those currently using it that way), not something you want to have around forever. > 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. Parameters are easily covered by referential integrity checks. And until something better pops up, SQL is the way to go for data 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. As I said above: 1) if there's something better, I'm all ears 2) As soon as MySQL with refint checking is considered the standard, I see no issue with starting to require that. Realistically, MySQL 4.X with refint checking is not going to happen this month. It may never. But when it does, I'll happily use it. Emile --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
