|
|
Posted by Jerry Stuckle on 09/29/07 13:05
Dikkie Dik wrote:
>> 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:
It depends on how you define "account" and "user". In many systems,
each account is considered a different user.
Also, whether the account is activated or not is an attribute to that
account.
> - 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.
>
Sure. But a proper database design and you don't have these problems.
> All the above examples are real and I have had to deal with them in the
> past months.
Only the past months? They've been going on for the > 20 years I've
been involved in RDB design/development. And they aren't going to go away.
But many of these problems also occur because the system needs changed
over the years. Things were correct when they were first laid out, but
as things changed, management tried to modify existing code to "make it
fit", rather than take a look at redesigning the system to make it work.
Such decisions are almost always cheap in the short term, but expensive
in the long term.
The answer is proper system design - including the database. And you
can't make one rule which covers all solutions.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|