|
|
Posted by Dikkie Dik on 09/29/07 08:56
> This is actually very interesting. I have been studying user systems a
> lot over the last year or so and have never seen minimal tables in any
> of the active/popular applications. Even the PHPBB3 is a huge offender
> to your suggestion with their whopping 72 fields in their user table.
> I have never really had any issues with dealing with tables with a
> large number of entries, assuming they arent replicated or whatever.
> In fact, i have only ever read about/seen/been forced to use linked
> tables when data is replicated.
>
> Can you provide any reasoning for your minimal approach?
Login tables tend to store a lot of things that just do not belong
there. An account is just an account. It is not a user, and it is not an
activation. These things are usually separate, or should be. I have had
to cope with too many systems that abused a user table as an account
table. This may sound nice, until you find out that:
- There can be more types of account per user (say, a web account and an
office account. Activations are totally different for "near" or remote
accounts)
- Not every user has these account
- Some accounts may link to more than one table that could be seen as a
user table: A web site may know users and suppliers. At some point,
somebody requires that the suppliers can log in as well. I leave the
rest up to your imagination.
All the above examples are real and I have had to deal with them in the
past months.
[Back to original message]
|