2

I don't usually design databases, so I'm having some doubts about how to normalize (or not) a table for registering users. The fields I'm having doubts are:

  • locationTown: I plan to normalize for countries, and have a separate table for it, but should I do the same for towns? I guess users would type this in when registering, and not choosing from a dropdown. Can one normalize when the input may be coming from users?
  • maritalStatus: I would have a choice of about 5 or so different statuses.

Also, does anyone know of a good place to find real world database schema/normalizing examples?

Thanks

coopersita
  • 5,011
  • 3
  • 27
  • 48

2 Answers2

1

  • locationTown - just store it directly inside user table. Otherwise you will have to search for existing town, taking typos and code case into account. Also some people use non-standard characters and languages (Kraków vs. Krakow vs. Cracow, see also: romanization). If you really want to have a table with towns, at least provide auto-complete box so the users are more likely choosing existing town. Otherwise prepare for lots of duplicates or almost duplicates.

  • maritalStatus - this in the other hand should be in a separate table. Or more accurately: use single character or a number to represent marital status. An extra table mapping this to human-readable form is just for convenience (remember about ) and foreign key constraint makes sure incorrect status aren't used.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
-2

I wouldn't worry about it too much - database normalization (3NF, et al) has been over-emphasized in academia and isn't overly practical in industry. In addition, we would need to see your whole schema in order to judge where these implementations are appropriate. Focus on indexing commonly-used columns before you worry about normalization.

You might want to take a look at this SO question before you dive in any further.

Community
  • 1
  • 1
acconrad
  • 3,201
  • 1
  • 22
  • 31