Database Rules

   

---

In addition to referential integrity, InterBase enables you to place server-side rules in the database. This is one of the great strengths of C/S development. Database rules that reside inside the database are enforced, regardless of the client that is accessing the data. An added advantage is that internal rules can often be changed without updating the client applications that are in use. For example, if it is decided that deleting a Revision record should set the corresponding bug record's bug- resolved field to zero, a trigger can be created or modified to handle the event. This means that for our earlier referential integrity problem (where we are trying to delete a record from the Program table), we could create a database rule that will automatically delete any Bugs table records that are assigned to that particular program.

There is no universally accepted standard concerning the placement of rules, and there are many differing opinions as to which rule should be on the server and which should be in the client. We would recommend that any rule that involves referential integrity or that operates on a large number of rows in the database should be placed on the server. Other rules can be located on the server or in the client, whichever seems best to you.

In multitier databases, on the other hand, the best place to keep database rules is generally in the programs of the middle tier. The only rules kept in the database tier are referential integrity rules, to ensure that even database administrators cannot damage the integrity of the data. This scheme ensures scalability as the middle tier is replicated, while still protecting the integrity of the underlying data.

---

Top