Comments on: Surrogates http://blog.roweware.com/2009/12/23/surrogates/ Ramblings about things I think I know... Tue, 30 Mar 2010 20:28:17 +0000 hourly 1 http://wordpress.org/?v=3.0 By: dave http://blog.roweware.com/2009/12/23/surrogates/comment-page-1/#comment-1296 dave Wed, 23 Dec 2009 23:15:50 +0000 http://blog.roweware.com/?p=150#comment-1296 I would contend (given this example) that tables should not be referencing the user_role table, since that table merely links the user to the role, establishing that the relationship exists. The parent table should rather link to the role table, and the business logic states that the user is a member of that role. For instance, if driving a permission from the role, I would code the application to the role, not the user_role. Though, it is a very valid point in a different situation, and I'd not thought of it that way. I would contend (given this example) that tables should not be referencing the user_role table, since that table merely links the user to the role, establishing that the relationship exists. The parent table should rather link to the role table, and the business logic states that the user is a member of that role.

For instance, if driving a permission from the role, I would code the application to the role, not the user_role. Though, it is a very valid point in a different situation, and I’d not thought of it that way.

]]> By: Jon Tucker http://blog.roweware.com/2009/12/23/surrogates/comment-page-1/#comment-1295 Jon Tucker Wed, 23 Dec 2009 23:09:23 +0000 http://blog.roweware.com/?p=150#comment-1295 I prefer the Candidate Key combination myself. Reason being is that the Surrogate Key method doesn't allow the two columns (in the above example: user_id and role_id) to be maintained with referential integrity in the database. If a parent table has the user_role_id as a child relationship, one can easily modify the user_id and role_id in the user_role table without impacting the parent that is using the user_role table. The business rule just got wacked and the database stood by helpless. Now, if you want to code and maintain the database trigger to enforce this relationship, then I maybe willing to go along with it. : ) I prefer the Candidate Key combination myself. Reason being is that the Surrogate Key method doesn’t allow the two columns (in the above example: user_id and role_id) to be maintained with referential integrity in the database. If a parent table has the user_role_id as a child relationship, one can easily modify the user_id and role_id in the user_role table without impacting the parent that is using the user_role table. The business rule just got wacked and the database stood by helpless.

Now, if you want to code and maintain the database trigger to enforce this relationship, then I maybe willing to go along with it. : )

]]>