| Re: Mr. Stuckle and Mr. Miller - explain normalisation with an example [message #185296 is a reply to message #185292] |
Mon, 17 March 2014 02:54   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 3/16/2014 9:14 PM, Lew Pitcher wrote:
> On Sunday 16 March 2014 20:12, in comp.lang.php, "Scott Johnson"
> <noonehome(at)chalupasworld(dot)com> wrote:
>
>> On 3/16/14, 2:29 PM, Lew Pitcher wrote:
>>> On Sunday 16 March 2014 16:22, in comp.lang.php, "richard"
>>> <noreply(at)example(dot)com> wrote:
>>>
>>> [snipe snipped]
>>>
>>>> The table I have now consists of the following columns.
>>>> songid,hits, title, author, license.
>>>> Please explain how this data should be normalised.
>>>> And why.
>>>> Thank you.
>>>
>>> For what it's worth, I don't think that you have to normalize your
>>> tables. Your table design seems to work for you. Normalization won't
>>> "fix" anything, because nothing is "broken".
>>
>> Nobody said his DB was broken
>
> Perhaps. I haven't been following every post.
>
> The point is that richard's current design will not, of itself, cause a
> problem. It will, however (as I implied later) be less than optimal.
>
> But, if richard isn't concerned about optimal performance or design, then
> there's nothing that normalization will bring to him.
>
>> rather an effort to....(read next section)
>
> Yes, I'm familiar with the effort. I've "assisted" richard a couple of
> times, and find his design and implementation less than... what I would do.
>
> But, I'm not him.
>
>>> What normalization (and, a proper database design, for that matter)
>>> /will/ do is make data maintenance and manipulation easier and possibly
>>> more efficient. For big datasets, normalization reduces storage costs,
>>> improves data reliability, and makes data manipulation (and the program
>>> development that goes with it) more consistant.
>>>
>>
>> What for the most part most have been trying to explain. And yes at
>> time it gets in the weeds out of frustration but the foundation has been
>> solid all along.
>>
>>> You seem to need none of these benefits. So, normalization is not for
>>> you. Perhaps, when your application and database grow larger, you will
>>> see the need for the improvements that database normalization and proper
>>> database design bring.
>>
>> It is when your DB is small that you want to incorporate a normalized
>> design so you can work out exactly what you need before you start having
>> to code and run DB routines to normalize it.
>>
>> Nightmare scenario.
>
> Very true. And, most of the "you need normalization" and "you need to
> redesign your data table structure" comments have been well-meant attempts
> to address that scenario.
>
>> Kind of like saying, don't get health insurance until you are
>> sick....wait. Never mind
>
> Yup.
>
> Richard has passed on the health insurance. Nothing that we say will change
> his mind. All we are doing is cluttering up an unrelated newsgroup with
> unrequested advice that won't be listened to.
>
> Bottom line: richard's app works to his satisfaction, without a proper
> database design and without database normalization. I think that the
> subject is closed, and it is time to move on.
>
> --30--
>
The problem here is in a couple of months Richard will want something
else which can't be done with his current design - at least not without
rewriting his entire site again. Then he'll come crying back here again...
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]