Is it practical to dynamically normalize a table?

Question

Let's say my database tracks bird sightings (Note: I'm really scraping the bottom of the barrel for examples).

The fields are:

sighting_id | common_name | park_name | location | time | etc....

Although I'm assuming that a park will always be in the same location, the website is like a spreadsheet. The user enters park_name and location for every entry. Also please note that my actual schema has other fields that are dependent on the analogous "park name" as well (e.g. state).

I do not have a way for the user to predefine parks, so I can't know them ahead of time. Should I even attempt to dynamically normalize this data? For example, should my program automatically populate a parks table, replacing the park_name and location column in the bird sighting table with a park_id?

I'm worried about performance, mostly. Listing every sighting would require a join to populate park and location. Also, dynamically managing this would almost certainty require more resources than it would save. I would probably need a Cron job to eliminate orphaned Parks, since they may be referenced in multiple sightings.

Answer 1

It depends on a bit on your usage. The normalized approach (park is a table) will make the following queries easier:

• How many bird sightings have there been for each park
• At which park are you most likely to see bird XYZ
• There are probably quite a few more queries like this

But yes, you do run into some sticky issues. The pattern "if park XYZ doesn't exist then insert it into the parks table" suffers from a race condition that you'll have to deal with.

Now, how about some arguments against normalization here... Most customer databases probably store my street address as "123 Foo Street", without dynamically normalizing the street name (we could have a street table and put "Foo Street" there, then reference it from other tables. Why do I bring this up, well to show that even the guys who hate any repeated data will probably acknowledge that there is some line you don't necessarily have to cross.

Another silly example would be that we might share last names. Do we really need a table for unique last names and then foreign key to it from other tables? There might be some applications where this is helpful but for 99% of application out there, this goes too far. It's just more work and less performant for little to no gain.

So I'd consider how I want to be able to query data back out of the table. Honestly in this case I'd probably do a separate table for parks. But in other cases I've chosen not to.

That's my two cents, one cent after taxes.