2

I want to create a database listing characters in each book of the A Song of Ice and Fire series, listing the name of the character and the page in which they appear. I could just use three fields (not including the primary key,) Name, PageIntroduced, and BookIntroduced, but the Name field isn't atomic; I could be subdivide it quite a bit. Some characters have titles (Maester, Lord, Ser,) some characters have house names (Stark, Lannister, Baratheon,) plenty have nicknames (Bull, Ned, Arry,) and there are quite a few kings differentiated by regnal numbers (there are five Aegon's!) So my table might look like the following:

CHARACTER (
ForeName
HouseName
Title
NickName
RegnalNumber
PageIntroduced
BookIntroduced
)

The question is: is this complete overkill, or should I use a single "Name" field encompassing all five attributes, even if it's non-atomic? I'm sure it's neater, especially for "King Aegon V "the Fortunate" Targaryen", but it would lead to a lot of fields not being used - many characters have only one name and nothing else, such as "Rorge", "Biter" and "Hot Pie". Is this a problem in databases? Does it matter if fields are left blank in databases?

Lou
  • 181
  • 1
  • 8

1 Answers1

3

Splitting given names from surnames is not normalisation. What would be normalisation would be if you created a series of tables that contained additional details about some of the columns in your table.

For example, you could create a HOUSE table that contains information about the house other than the name, such as it's catch phrase or home town etc. You might do something similar with TITLE and BOOK.

Don't worry about nulls in your case. Some people are concerned about too many nulls because it can be a sign that your design is not correct or because they are worried about wasting disk space. In your case neither of these concerns is germane.

Joel Brown
  • 12,604
  • 2
  • 32
  • 46