| Re: Mr. Stuckle and Mr. Miller - explain normalisation with an example [message #185289 is a reply to message #185280] |
Mon, 17 March 2014 00:12   |
Scott Johnson
Messages: 196
Registered: January 2012
Karma:
|
Senior Member |
|
|
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 rather an effort to....(read next section)
>
> 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.
Kind of like saying, don't get health insurance until you are
sick....wait. Never mind
Scotty
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]