Question

I have an existing table structure that looks something like this:

AnimalTable
-------------
|Id         |
|Color      |
|Weight     |
|AnimalType |
-------------

CatTable
----------------
|Id            |
|MeowSound     |
|AnimalTableId |
----------------

DogTable
----------------
|Id            |
|BarkSound     |
|AnimalTableId |
----------------

AnimalType is either “Cat” or “Dog”. Basically, it’s a “Table Per Type” structure plus the additional “AnimalType” discriminator in the AnimalTable. This is obviously a contrived example, but my project has a similar setup that has been in use for a good amount of time. We’re starting to convert some stuff over to use the EF Code First approach, and I’d like to use this same schema so I have an abstract Animal class, and concrete Cat and Dog classes.

Setting this up from scratch seems pretty straightforward, but I’m not sure what the best way to go about changing the primary keys on my existing tables to make it as if I had been using EF all along. Has anyone done this and can provide some tips/direction? Thanks in advance.

Answer 1

I ended up writing a stored procedure that essentially dropped the Id column in the CatTable and DogTable, renamed AnimalTableId to Id, and made that the primary key. Sounds easy enough, but the hard part was writing something that would generically fix all the foreign keys already pointed at CatTable.Id and DogTable.Id.