| Re: Mr. Stuckle and Mr. Miller - explain normalisation with an example [message #185293 is a reply to message #185288] |
Mon, 17 March 2014 01:43   |
Mr Oldies
Messages: 241
Registered: October 2013
Karma:
|
Senior Member |
|
|
On Sun, 16 Mar 2014 17:05:44 -0700, Scott Johnson wrote:
> 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
I defend my use of this table by the fact that it is merely for
recordkeeping reasons.
The only data that is changed is the hits.
The licensing agents want to see my playlist and how many plays each song
had.
So the information is for when I create the printout and sned it to them.
Ad the fact that I can't remember what the hell song number 64-444 is.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]