Is it practical to dynamically normalize a table?

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 exampl开发者_如何学Goe, 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.

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.

My two cents on the original "parks" example (as opposed to the OP's actual problem):

The decisive argument against trying to automatically normalize the park and location columns is usability: when data is presented to the user in an editable spreadsheet-like format, they will naturally assume that each row can be independently edited, so it's deceptive (and likely to lead ultimately to confusion) if some columns such as "location" are actually associated with the park, rather than the row.

A typical pattern for handling this sort of situation is to only prompt the user for park's details and create a row in the "parks" table when a new park is entered. For example, if the park column contains a drop-down box, then the last option could be "add new park". Alternatively, add a new park when the user enters an unrecognized park name -- but still make it clear to the user that a new park is being created.