I have ran into this problem a few times and I am wondering what other people are doing.
When I am creating a database, sometimes I have to import data into a table on a regular basis, let's say daily. What I normally do is delete all of the records and reimport every record from the external data source.
Many times I will have to store some more data that relates to the imported records, but doesn't come from the original import source. Typically this "extra data" comes from user input. So, I will create another table with a primary key matching the key of the table that gets the imported data, and store this additional data in the new table. If that doesn't make sense here is an example:
In an old legacy system, we store employee data. But, I need to use this data in a web application that can't connect to this old legacy system. So, I create a database with a table that matches the schema of the data that I have in the old system and I import each record into this table every day. When I do the import, I drop every record and import every record.
But in my new system, employees can save a bio. So in another table, I store this and their Id.
It would be simpler to have only one table, but I can't do that because I would drop data that doesn't exist elsewhere when I do the import.
Another bad thing is that, because I am deleting all of these records for the import, I can't define foreign key constraints with related data.
I hate designing databases this way, because I know there is a better way. Wouldn't it be nice if I could do updates when I import the data, instead of deleting and importing it all?
I am using Sql server 2008 but am interested to hear of strategies that can work with any RDBMS.