Although i may not understand what a stable databasedesign
has primarly something to do with "webdevelopment on
mysql/php", I don’t agree with you about surrogate
keys. The primary goal for a database design is stability
and consistency at all times. Sure, the error came up by a
code-bug, but this one compromises the database-integrity
too because of the duplicate-key error. In this particular
case I don’t see any reason why not ADDING the
autoincrement field to the unique key. Nobody talked about
setting the id field alone as unique key. You are right -
MANY reason (e.g. security) are against this. And maybe some
performance tweak wouldn’t run as smooth as in the past.
But if I had to choose between a bit more performance or a
bit more stability, I choose stability. But that’s only my
opinion. ;)
Besides: I don’t develop mysql/php solutions. Im more the
spec for backend processings. And - personal: don’t like
php very much. I prefer html4/ssi and cgi a lot more. ;)
yeah im a oldschool dog.
Regards
Simon
PS: yes, it’s a real old debate. ;)
-----Ursprüngliche Nachricht-----
Von: dbmail-bounces dbmail.org [mailto:dbmail-bouncesdbmail.org] Im Auftrag von Paul J Stevens
Gesendet: Mittwoch, 5. März 2008 12:45
An: DBMail mailinglist
Betreff: Re: AW: [Dbmail] (patch) Another case of duplicate
keys (via dbmail-smtp)
Simon Lange wrote:
> What me (duplicate key issue) wonders even more: why
using db-keys without an autoincrement field? This may is
some kind of code-issue but it is definetly also a db-model
issue. What reason the key has no autoincrement field?
> current: UNIQUE KEY `physmessage_id_2`
(`physmessage_id`,`headername_id`,`headervalue`(255))
> well, this cries for a duplicate key error, because its
not unthinkable that ONE message may have the same
header-field twice or more. Maybe someone thinks that RFC
has strict boundaries, but on the other hand human being do
make errors and so may violate RFCs so wouldn’t it be
better to make dbmail more tolerant for
"human-errors" for such a case?
> Just adding the field "id" to that unique key
would solve the issue at once.
>
> What do you think?
A very old database-design debate.
UNIQUE KEYs are perfectly valid. So are duplicate headers.
Duplicate headers are
*not* inserted more than once. The code is specifically
designed to avoid them.
The fact that it still appears to happen is a bug, not a
faulty design.
Auto-increment integers used as primary keys (also known as
surrogate keys as
opposed to natural keys) are a typical pattern used very
often by database
designers geared to webdevelopment on mysql/php. There are
many reasons to avoid
them where possible
http://en.
wikipedia.org/wiki/Surrogate_key
In this case John Fawcett appears to have tracked this issue
down to a memory
corruption.
--
____________________________________________________________
____
Paul Stevens paul at
nfg.nl
NET FACILITIES GROUP GPG/PGP:
1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
|