|
|
Posted by Jerry Stuckle on 10/01/07 12:20
Bruno Barros 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?
>>>> --
>>>> ==================
>>>> Remove the "x" from my email address
>>>> Jerry Stuckle
>>>> JDS Computer Training Corp.
>>>> jstuck...@attglobal.net
>>>> ==================
>> 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!
>
But I called it what it is - an example of overnormalization which
causes more performance problems. And stupid.
But again, this a PHP group, not a database group. If you want to
continue this inane discourse, please take it to a database newsgroup -
where you will be told why you're wrong by a lot of database experts.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|