1

Reading this article,

http://weblogs.asp.net/manavi/archive/2010/12/28/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-2-table-per-type-tpt.aspx

and doing a simple test myself, I feel that the database isn't very safe (from data integrity).

I mean, lets take the example in that page:

1 base class and 2 subclasses: base = BillingDetail subclasses = CreditCards, BankAccounts

3 tables. BillingDetail has primary key shared with CreditCards, BankAccounts.

Say from the application, we create a CreditCards entity and save to database. We get a row in BillingDetail + a row with same id in CreditCards.

If we then go to database, and manually create a row in BankAccounts with the same ID, it now is also a BankAccounts entity in the application.

I mean is this behavior.... wrong?

(Not that I am that overly concerned about this, but wouldn't it have been better to insert something like trigger or constraint in database to ensure integrity?)

Sleeper Smith
  • 3,212
  • 4
  • 28
  • 39

1 Answers1

2

You can always create your own trigger if you feel that you need additional integrity. Your described approach will be indeed allowed in the database but once you do such change your EF application will always fail when trying to read such corrupted record.

The reason why EF does it this way is that using either code first or model first is for scenarios where database is only for your application so you don't have to deal with such modifications from elsewhere.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670