0

I'm writing a quick app using LINQ to SQL to populate a db with some test data and had a problem because one of the tables had no primary key as described by this bloke Can't Update because table has no primary key.

Taking the top answer I added the IsPrimaryKey attribute to an appropriate column and the app worked even though the I haven't changed the db table itself (i.e. there is still no primary key).

I expect it will be ok for my current intentions but are there any side effects which may come from having a table without a primary key seen as having one by the LINQ object?

(I can only think it might be a problem if I tried to read from a table (or populate to a table) with data where the 'primary key' column has the same value in more than one row).

Community
  • 1
  • 1
Patrick
  • 8,175
  • 7
  • 56
  • 72

2 Answers2

3

When using an ORM framework, you can simulate keys and foreign keys at ORM level, thus "hiding and overriding" the database defined ones.

That said, that's a practice that I wouldn't recommend. Even if the model is more important than the database itself, the logical structure should always match. It is ok doing what you did if you're forced to work with a legacy database and you don't have the possibility to fix it (like adding the PK on the table). But try to walk the righteous path everytime you can :)

Tables without a PK = Pure Evil.

Matteo Mosca
  • 7,380
  • 4
  • 44
  • 80
  • 1
    "Tables without a PK = Pure Evil" - Why? – Patrick Oct 14 '10 at 15:30
  • 3
    Because if the table does not have a PK the DB engine has no way to identify the single rows. Try to visually delete rows from a table without FK by highlighting them on a user interface like Sql Management Studio and delete them. The tool will refuse to delete them, because it has no way to know what it is trying to delete. – Matteo Mosca Oct 14 '10 at 15:34
  • To quote Joe Celko: "if it doesn't have a primary key, it's not a table". Any "useful" table **MUST HAVE** a primary key. – marc_s Oct 14 '10 at 16:16
2

Basically if all the table updates go through the LINQ object you should be fine. If you have a DBA that decides to modify data directly though SQL then you can quickly run into issues if he duplicates a row with the same PK value.

John Hartsock
  • 85,422
  • 23
  • 131
  • 146