| Re: Mr. Stuckle and Mr. Miller - explain normalisation with an example [message #185288 is a reply to message #185285] |
Mon, 17 March 2014 00:05   |
Scott Johnson
Messages: 196
Registered: January 2012
Karma:
|
Senior Member |
|
|
On 3/16/14, 4:20 PM, richard wrote:
> On Sun, 16 Mar 2014 21:54:18 +0100, Luuk wrote:
>
>> On 16-3-2014 21:22, richard wrote:
>>> I'll bet you won't.
>>>
>>> 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.
>>>
>>
>> The column 'author' should be an 'authorId'.
>>
>> why?
>> - Because 1 author can write more than 1 song
>> - An author has properties to, like i.e.:
>> - birtdate
>> - date of death (if applicable)
>> - city of birth
>> - etc
>> - etc
>> Another advantage of this is that, when you found out that you
>> misspelled the name of this author, you only need to change 1 record to
>> correct the songs of this author.
>>
>> Another example of this might be 'license'
>> If i ask questions like:
>> When became this license valid?
>> And 'until when was this a valid license'?
>> Did the author have more than 1 license?
>>
>> You might say "this is not applicable to my application"
>> But, in real life, one should be prepared that this will become
>> applicable for your application. (Because users only start to think
>> after they see the portential of your application)
>
>
> Actually, that should have been artist, not author.
> for my purposes, personal information on either the artist, or author is
> not necessary.
> As one particular song could have been performed by any number of artists,
You see Luuk gave you a great but very simplistic example why your
author (artist) should be kept in the different table that only you
would defend against.
How do YOU account for several artists for a song in your schema?
You may not 'need' the extra data for each artist, but wow would it not
be good to be update-able down the road, it shows foresight and a 'Big
Picture' mentality.
> that is why the artist column is included. To distinguish the songs.
> As for the author, that is actually optional.
> Most people don't even care to know who the author is.
> But it's there for helping to identify the song.
A DB is, for as far as I can tell, NOT normalized with the 'people' in
mind but rather your data polling and parsing. Display is second thought.
Scotty
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]