Will,
I know that on PostgreSQL it will only waste one bit per row if there's
a
null in a field. I assume that MySQL does something similar. It doesn't
seem like it would that big a deal (unless MySQL is even worse than people
say).
Thanks,
Peter Darley
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Will Berry
Sent: Friday, May 14, 2004 10:11 AM
To: DBMail mailinglist
Subject: Re: [Dbmail] Is there a nead for a users description table
Feargal Reilly wrote:
>I had a look last night and could not find a formal definition of it.
>Common usage however indicated that most flavours of unix treat it the
same. It is a comma seperated list which takes the following order:
>Full name, Office Location/Room Number, Office/Work Phone Number, Home
Phone Number, Other/Miscellaneous.
>
>Many applications look up the first field to insert a user's name. Some,
such as finger, chfn, and adduser uses the other information too. I checked
this on FreeBSD, Debian, Red Hat, and Solaris.
>Apparently Solaris they only used two labels - Full Name and other.
>
>
This tells me that the field is basically a hack, and doomed to be
non-standard and non-portable until approximately 3 years after it
appears in an RFC. Maybe if there was a way to define the format in
dbmail.conf it would be portable enough.
>I agree on you with using the client_idnr for tying to other databases; the
GECOS field is not intended for that. I suggest it as it satisfies the needs
of many people who do not need to develop a full blown user management
database.
>
>
Another issue with having a gecos field in the DBMail user table that
DBMail itself does not use is wasted space. A comma-separated list of
text data would probably be best implemented as a varchar(255) field, or
even a tinyblob (that's max 8K, right?). As you scale up, that could be
a lot of space, and for an awful lot of people this space would be unused.
On the other hand, the long int client_idnr field, while not strictly
necessary (the tie-in could be made in another table or db), is nice and
takes a lot less space per row than arbitrary text data.
>I would suggest that if renaming the client_idnr field, it should be called
'group' or 'group_idnr'.
>
>
Naming it 'group' implies a specific meaning for the field, and
therefore would be confusing to new users/developers. Any new name
should imply *any* use the application desires. Something like
'external_idnr' would be sufficiently generic.
--
Will Berry
Co-founder, Second Brain website hosting
http://www.secondbrainhosting.com/
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
