|
|
Posted by Jerry Stuckle on 09/29/07 18:24
klenwell wrote:
> On Sep 29, 6:57 am, Bruno Barros <rage...@gmail.com> wrote:
>> I, for my framework, put:
>>
>> ID
>> USERNAME
>> PASSWORD
>> EMAIL
>>
>> That is for the simple login / logout / register data.
>> Then, according to the application, there is another user table, which
>> holds all the user's information. It is always made from scratch as I
>> never know which fields my customer requires or my code needs ;). For
>> example, for a social networking site you need about me, musical
>> interests, ..., but for a customer account on a shop, you needn't such
>> things. The main users table only stores what is essential in ALL
>> users. Then I make a relation between them, connecting users by ID.
>> The record with ID X on main table belongs to ID X on the other table.
>>
>> By the way, PHPBB3, MediaWiki and such are not frameworks, they are
>> not made to be as broad as possible. They are ONLY made for themselves
>> and their specific needs, while a framework needs us to remember that
>> it has to work with all websites from top to bottom.
>>
>> ---
>> Bruno Rafael Moreira de Barros
>>
>> Adobe Photoshop CS2 and CS3
>> -
>> XML / XSLT
>> -
>> MySQL / SQLite / TerraDB
>> -
>> PHP 3, 4, 5 and 6
>>
>> :: Looking For A Permanent Job ::
>> ---
>
>> By the way, PHPBB3, MediaWiki and such are not frameworks, they are
>> not made to be as broad as possible. They are ONLY made for themselves
>> and their specific needs, while a framework needs us to remember that
>> it has to work with all websites from top to bottom.
>
> That's a good point. I should probably look at the popular PHP
> frameworks, too, for an idea of how they handle this.
>
Better would be to understand database normalization. Most databases
are about third normal form (3NF). Adding unnecessary tables can
actually slow down access.
> The model I'm using now was first designed with a specific application
> in mind. The inclination to minimize is prompted by the goal of
> abstracting the model to be more flexible for greater general usage.
> But I'm keeping in mind Jerry's point above: "The answer is proper
> system design - including the database. And you can't make one rule
> which covers all solutions."
>
>> ID
>> USERNAME
>> PASSWORD
>> EMAIL
>
>> That is for the simple login / logout / register data.
>> Then, according to the application, there is another user table, which
>> holds all the user's information. It is always made from scratch as I
>> never know which fields my customer requires or my code needs ;).
>
> I like this idea. This is definitely the direction I'm leaning. I
> agree these are the essential, though a date (timestamp) established
> seems fundamental to me, too.
>
But it also means extra joins (and overhead for the database) when you
need other data. A one-to-one correspondence between rows in two tables
is generally considered "overnormalizing" and not really a good thing.
Of course, there are valid reasons - like a large BLOB field in the
table - which would make it better to have that data in a different table.
> I find it an interesting question as it does lead one to the more
> philosophical issues of what is identity exactly (is it an account or
> a user)? May have to move this over to alt.philosophy. :)
>
> Tom
>
Actually, a database newsgroup would be more applicable when you're
talking about database design. If this is MySQL, for instance, you can
get some excellent help on comp.databases.mysql.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|