Skip to main content

Maintaining Cross-Database Referential Integrity

It is often convenient to house your master tables in a separate database from application specific databases so that primary keys are copasetic and multiple databases have access to the same lookups.

Common examples would include employees, counties, regions and other lookup tables.

Once these tables are in a separate database however it is no longer possible to simply drag-and-drop a relationship between them to maintain referential integrity.

Here's a Solution
For this example we'll use an Observation table, tied to a master list of Sex, that's right, Sex (we could call it Gender to be all PC, but these are animals, not Pat in the Personnel Department.)

Step 1:
We create a new view called PIC_Sex in our Application Database by querying the table PIC_Sex in our Master Database:

CREATE VIEW dbo.PIC_Sex AS
SELECT SexID, Sex, Rank
FROM Master.dbo.PIC_Sex
ORDER BY Rank

Yes, that's right, Male and Female! You don't even want to go down that road.

Step 2:
We create a new user-defined function xdf_ValidateSex to validate if a given SexID exists in the view PIC_Sex.
CREATE FUNCTION [dbo].[xdf_ValidateSex] (
@SexID int
)
RETURNS int AS
BEGIN
RETURN
(
SELECT SexID FROM [dbo].[PIC_Sex] WHERE SexID = @SexID
)
END
I've found this function really handy at some bars in the Village (see note above).

Step 3:
In our Observation Table we add a constraint on the field SexID which tests against the function xdf_ValidateSex to see if the SexID exists.

Enter the following Constraint Expression:
([dbo].[xdf_ValidateSex]([SexID]) is not null)


Viola! You can now validate Sex programmatically! Just add this constraint to your front door (or back door as the case may be) and no more embarrassing mornings waking up the spoonee instead of the spooner (or the other way around, I'll let you work out the validation details on your own).
Hint: Add a WHERE clause to the initial view to match your preferences.

Comments

Popular posts from this blog

Simple HTTP Redirect with Querystring in IIS7

HTTP Redirect seems simple enough. Always was in IIS6 and in IIS7 there's even a button labeled HTTP Redirect that promises relative redirects.  It looks like it'll be as easy Apache finally.  That is until you try to redirect a querystring.  Then everything bombs.

Turns out it still is relatively easy, except you have to know that Microsoft changed $S$Q to $V$Q. Why? $Ss and $Gs I suspect.

And How.
In our example we'll redirect all pages under http://olddomain.com/content to http://mydomain.com/content.
Pick the virtual directory you want to redirect. e.g. http://olddomain.com/content Click HTTP Redirect under IIS in the IIS management console.In the HTTP Redirect Dialog:
Check Redirect requests to this destinationEnter your new path ending with $V$Q.  e.g. http://mydomain.com$V$QCounter-intuitively check Redirect all request to exact destination (instead of relative destination)Choose the appropriate Status Code (Permanent or Temporary)Apply Changes and Test

Serving up KML in IIS 6

To serve up KML in IIS 6, you have to add a few MIME Types. The easiest way to do this is to apply new MIME Type settings globally by changing the properties on your server's "Web Sites" folder in IIS.


Google Earth reads KML and KMZ files. The MIME type for KML files is

* application/vnd.google-earth.kml+xml

The MIME type for KMZ files is

* application/vnd.google-earth.kmz

Source: Google KML Tutorial


To add a MIME type to a Web site or directory

1. In IIS Manager, right-click the Web site or Web site directory for which you want to add a MIME type, and click Properties.

2. Click the HTTP Headers tab.

3. Click MIME Types.

4. Click New.

5. In the Extension box, type the file name extension.

6. In the MIME type box, type a valid MIME type. If you define a MIME type that has already been defined at a higher level, you are prompted to select the level where the MIME type should reside.

To create a MIME type for an undefined MIME type, type an asterisk (*) in the Extension box, an…