|
|
Posted by Rik Wasmus on 10/01/07 13:03
On Mon, 01 Oct 2007 11:16:17 +0200, Bruno Barros <ragearc@gmail.com> wrote:
> On 30 Sep, 19:09, "bob.chat...@gmail.com" <bob.chat...@gmail.com>
> wrote:
>> On Sep 30, 5:45 am, "Sanders Kaufman" <bu...@kaufman.net> wrote:
>> > "Jerry Stuckle" <jstuck...@attglobal.net> wrote in message
>>
>> >news:WeCdneLtDcJVNmPbnZ2dnUVZ_q_inZ2d@comcast.com...
>>
>> > > Sanders Kaufman wrote:
>> > >> I'm woring on a similar situation.
>> > >> I've got a userid, username, emailaddress and password.
>>
>> > >> But I also want fields for login_cookie, last_login, and
>> parent_user.
>> > >> I don't really WANT to create whole nother table to track that
>> stuff, but
>> > >> good design dictates that I should.
>>
>> > > And what "good design" is that? Definitely not normalization.
>>
>> > Definitely normalization.
>>
>> > >> The question becomes - if I break atomicity for expedience's sake,
>> what
>> > >> will be the consequences?
>>
>> Has anyone got any benchmarks or profiling data to back up their
>> claims? i have never noticed any performance increases based on
>> setting up a database to be set up in the, for lack of a better label,
>> "Everything belonging to the user in the user table" form versus the
>> "Spread it out and call it normalized" form. There is of course merit
>> to both options, but i think that it would be better to stop
>> speculating and start supporting the information.
>>
>> I am working on a paper on this stuff so if i try to back something up
>> with "Sanders Kaufman" or "Bruno Barros" said it wont come across very
>> well.
>
> I never said there would be performance differences, nor I named it
> normalization. I named it keep the essential table a MUST for ALL
> applications using the framework and then, according to the
> applications' needs, use another table with the data needed. Not all
> applications need the same amount of information! For example, a
> customer needs to give away his phone number to be contacted, but a
> guy registering for a forum doesn't have to! And then, instead having
> a big fat table with a load of fields that might or might not be used
> for the applications, you only had what was really necessary!
Who cares there's more information in the database? As long as you just
use 'SELECT only,the,fields,I,need FROM table' instead of a lazy 'SELECT *
FROM table', eveything's going to be speedy and allright. On a side note:
I know forums where a telephone number is needed/required/recommended.
Usually a more closed, select group forum though.
--
Rik Wasmus
Navigation:
[Reply to this message]
|