On Freitag, 1. Juni 2007 Blake Mitchell wrote: > It always seemed to me that the dbmail_aliases table should have a > user_idnr column along with the deliver_to column. This way if > deliver_to was null, go to the user's inbox. This would allow > constraints to prevent dangling aliases on user delete, and aliases > to user_idnrs that don't exist. > > It would require a user for every alias, but there's no harm in > creating administrative users that don't actually receive mail.
Why would it require a user? You could simply define that either the deliver_to or the user_idnr must be filled, but not both. But I'm not sure about the performance of such a solution, it could well be that this is slower, as it could require separate lookups at some points. But it sure would make the DB model more stable, and I'd prefer that. I love to have the DB rock solid, after all, it's a bit important. ;-) And is we're developing a complete web interface for it, having dependencies guaranteed by the DB is much better than logic in external programs. Developers make errors, after all. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: EA39 8918 EDFF 0A68 ACFB 11B7 BA2D 060F 1C6F E6B0 // Keyserver: www.keyserver.net Key-ID: 1C6FE6B0
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
