How do I enforce data integrity rules in my database?

Question

I'm designing this collection of classes and abstract (MustInherit) classes…

This is the database table where I'm going to store all this…

As far as the Microsoft SQL Server database knows, those are all nullable ("Allow Nulls") columns.

But really, that depends on the class stored there: LinkNode, HtmlPageNode, or CodePageNode.

Rules might look like this...

How do I enforce such data integrity rules within my database?

---

UPDATE: Regarding this single-table design...

I'm still trying to zero in on a final architecture.

I initially started with many small tables with almost zero nullalbe fields.
Which is the best database schema for my navigation?

And I learned about the LINQ to SQL IsDiscriminator property.
What’s the best way to handle one-to-one relationships in SQL?

But then I learned that LINQ to SQL only supports single table inheritance.
Can a LINQ to SQL IsDiscriminator column NOT inherit?

Now I'm trying to handle it with a collection of classes and abstract classes.
Please help me with my .NET abstract classes.

Answer 1

Use CHECK constraints on the table. These allow you to use any kind of boolean logic (including on other values in the table) to allow/reject the data.

From the Books Online site:

You can create a CHECK constraint with any logical (Boolean) expression that returns TRUE or FALSE based on the logical operators. For the previous example, the logical expression is: salary >= 15000 AND salary <= 100000.

Answer 2

It looks like you are attempting the Single Table Inheritance pattern, this is a pattern covered by the Object-Relational Structural Patterns section of the book Patterns of Enterprise Application Architecture.

I would recommend the Class Table Inheritance or Concrete Table Inheritance patterns if you wish to enforce data integrity via SQL table constraints.

Though it wouldn't be my first suggestion, you could still use Single Table Inheritance and just enforce the constraints via a Stored Procedure.

Answer 3

You can set up some insert/update triggers. Just check if these fields are null or notnull, and reject insert/update operation if needed. This is a good solution if you want to store all the data in the same table.

You can create also create a unique table for each classes as well.

Answer 4

Have a unique table for each type of node.

Why not just make the class you're building enforce the data integrity for its own type?

---

EDIT

In that case, you can either a) use logical constraints (see below) or b) stored procedures to do inserts/edits (a good idea regardless) or c) again, just make the class enforce data integrity.

A mixture of C & B would be the course of events I take. I would have unique stored procedures for add/edits for each node type (i.e. Insert_Update_NodeType) as well as make the class perform data validation before saving data.

Answer 5

Personally I always insist on putting data integrity code on the table itself either via a trigger or a check constraint. The reason why is that you cannot guarantee that only the user interface will update insert or delete records. Nor can you guarantee that someone might not write a second sp to get around the constraints in the orginal sp without understanding the actual data integrity rules or even write it because he or she is unaware of the existence of the sp with the rules. Tables are often affected by DTS or SSIS packages, dynamic queries from the user interface or through Query analyzer or the query window, or even by scheduled jobs that run code. If you do not put the data integrity code at the table level, sooner or later your data will not have integrity.

Answer 6

It's probably not the answer you want to hear, but the best way to avoid logical inconsistencies, you really want to look at database normalisation

Answer 7

Stephen's answer is the best. But if you MUST, you could add a check constraint the HtmlOrCode column and the other columns which need to change.

Answer 8

I am not that familiar with SQL Server, but I know with Oracle you can specify Constraints that you could use to do what you are looking for. I am pretty sure you can define constraints in SQL server also though.

EDIT: I found this link that seems to have a lot information, kind of long but may be worth a read.

Answer 9

Enforcing Data Integrity in Databases Basically, there are four primary types of data integrity: entity, domain, referential and user-defined.

Entity integrity applies at the row level; domain integrity applies at the column level, and referential integrity applies at the table level.

1. Entity Integrity ensures a table does not have any duplicate rows and is uniquely identified.

2. Domain Integrity requires that a set of data values fall within a specific range (domain) in order to be valid. In other words, domain integrity defines the permissible entries for a given column by restricting the data type, format, or range of possible values.

3. Referential Integrity is concerned with keeping the relationships between tables synchronized.

@Zack: You can also check out this blog to read more details about data integrity enforcement, here- https://www.bugraptors.com/what-is-data-integrity/

Answer 10

SQL Server doesn't know anything about your classes. I think that you'll have to enforce this by using a Factory class that constructs/deconstructs all these for you and makes sure that you're passing the right values depending upon the type.

Technically this is not "enforcing the rules in the database" but I don't think that this can be done in a single table. Fields either accept nulls or they don't.

Another idea could be to explore SQL Functions and Stored Procedures that do the same thing. BUt you cannot enforce a field to be NOT NULL for one record and NULL for the next one. That's your Business Layer / Factory job.

Answer 11

Have you tried NHibernate? It's much more matured product than Entity Framework. It's free.