Last week, I had to exercise the old gray muscle on some database design, and ran into a little gotcha when trying to make a high level conceptual database model in Visio.  Essentially, when you're using the ERD template, you can't model a many to many relationship without elaborating the model further with a junction table.

So that being established, I referred to my handy copy of Michael Hernandez's brilliant Database Design for Mere Mortals (by the way, I'm proud to be able to call him my friend), and some other articles including Jason Mauss' Database Naming Conventions for some opinions on naming things.

Many people suggest that the junction table name be a compound of the two tables comprising the many to many relationship (for example, DoctorsPatients).  In my opinion, this is fine only if the junction table will not contain other columns.  In many cases, the junction table will be used to record other information... order details, doctor assignments, etceteras.  In this case, I think it's better to formulate a name that describes the other content and let the two foreign keys (for the two tables with the many to many relationship) convey the many to many relationship.  For example, in the case of the Doctors and Patients, Assignments is more accurate than DoctorsPatients.

What do you think?

If you have a SBS 2003 server running Intelligent Message Filtering, and you're using ORDB as one of your Real Time Block lists, some time around January 7th, your SBS server may have stopped routing inbound faxes to an email recipient.  The official SBS Blog wrote this post on the issue a couple days ago, but we started experiencing the problem about a week ago, before we could find any information on it.

We resolved the problem by using the Custom Weighting feature in Exchange.  This is a feature that allows you to specify key words or phrases that if IMF finds in an email message, will cause it to allow the message through.  You can find this discussed about half way down the page here:  http://download.microsoft.com/download/f/b/5/fb5c54af-fe5c-48e9-be97-f9e8207325ab/Ex_2003_SP2_RelNotes.htm

We added a line like this:

<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="FAX"/>

Admittedly, this isn't the best solution for the problem, but the custom weighting feature is still something that should be enabled on SBS if you're using IMF.  We likely won't remove the line, and we can quickly add more strings any time.

When we began seeing errors on our SBS 2003 Server several days ago warning that space on the C drive was running low, we began to plan an intensive (and scary) operation to upgrade it.  The plan WAS going to look something like this:

• shut down server
• remove system drive and install it in a second machine
• install bigger drive in second machine
• install disk cloning software on second machine
• copy old drive to new drive
• put new drive (cloned) in server
• be happy

There are many esoteric little things involved in these steps, especially when we're talking about SCSI and Dynamic NTFS disks. The whole process was a little daunting.

BUT, much of this worry goes away with Paragon Partition Manager Server Edition.  Hallelujah!  I installed a new 70 gig SCSI drive to replace a 16 gig drive (required a server restart). Then I ran Partition Manager to copy the system disk to the new disk (this needed another restart), and Ka-ching!... shut down the server one more time to remove the old drive and we were back in business.

Brilliant. Thank you Paragon!