Q:

Is it okay for a foreign key to reference an identity field?

Suppose I have the following models in the ASP.NET MVC code first approach :
public class City
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class Restaurant
{
    public int Id { get; set; }
    public int CityId { get; set; }
    public virtual City City { get; set; }
} 

That means I have a table called City Which has :

Id ( Primary key and it's an identity field)
Name ( varchar )

And another table called Restaurant Which has :

Id ( Primary key and it's an identity field)
CityId( Foreign key refrencing Id in City table and no cascade on delete )

Now because my city data is fixed and not changing much i use the seed method to populate it like:
context.Cities.AddOrUpdate(x => x.Name,
               new City() { Name = "Springfield" },
               new City() { Name = "Franklin" },
               new City() { Name = "Greenville" }
            );

Please notice I'm not assigning any ID because City Id is an identity field and auto-increments.
One Scenario:
A scenario which i fear is this:
Assume there are some restaurants in the Restaurant table referencing these cities. Now as time goes by, for some unknown reasons Franklin which had the Id of 2 gets deleted from the City table. So when you notice what happened, you insert Franklin as a city again but this time it's Id has changed. So what happens to those restaurants which were already referencing "Franklin" as their city?
Should I make City Id not an identity primary key but just an integer primary key and assign City Ids myself?
If I enable cascade delete on the foreign key, then i will lose the records referencing the deleted city and I don't want that. I want to keep them until I figure out what happened to the deleted city and fix the issue.
Question
So with this information, in my case, is it a good practice to make a foreign key from an identity field? What's the best way to handle this situation?

A:

Primary and Foreign keys ensure something called "referential integrity." Just like it sounds, they ensure the integrity of the references contained in the data. If you have restaurants in a city you should not be allowed to delete that city because it would destroy the integrity of the references (i.e. you now have orphaned restaurants). The alternative would be to allow the database to delete the restaurants if you delete the city. Either of those scenarios (blocking the deletion or cascading the deletion) can be accomplished with a foreign key.
Whenever the data in one table is dependent on the data in another table for its existence you should create a foreign key to ensure you don't end up with data corruption. The fact that it is an identity column is irrelevant.
Your database is the last line of defense against corrupt data. You want to ensure that those "unknown reasons" that cause the row to be deleted are simply not allowed. It's easier to prevent the problem in the first place than to try to fix the data after it's corrupt.

