Databases

NHibernate - null id in entry (don't flush the Session after an exception occurs)

Brian Chavez — Wed, 14 Nov 2007 21:41:11 GMT

I ran into this issue today when trying to persist one of my objects. The cause of the problem was interesting. I was trying to save an object when a property/columns in the table had a unique constraint. As a result, the object that I was trying to persist would not persist simply because the object's property it failed to meet the unique constraint.

As a result, a call to Save() on the object failed and the ID on the object I was trying to save was not set, but NHibernate still processed the object and associated it with its persistence mechanism leaving it in a "semi-persistent" state with the NHibernate persistence manager (ie: NHibernate now knows about the object you tried to save and it SHOULD have fully evicted the object from its persistence manager because the save failed, but it didn't).

When an HTTP request finishes on my ASP.NET application, I flush and close all NHibernate session objects at the time the request is done. And as a result, when the HTTP request finished, NHibernate attempted to flush the jacked up "semi-persistent" object (an object who's ID was null) and ultimately generating the error above.

So, the solution that I implemented was to wrap the Save() in a try{} catch{} statement, and if the save failed, immediately close and shutdown the session, handle the error/exception. Then, check if Session.IsOpen when the HTTP request finishes.

Hope that helps,

Brian Chavez

WMI Provider Error - Access Denied - TDSSNIClient initialization failed with error 0x5

Brian Chavez — Tue, 06 Nov 2007 18:44:42 GMT

I got an interesting error while trying to change the log on service account for SQL server. I got a "WMI Provider Error" and a bunch of errors in the Windows Event Log.

Simple solution:

Restart.

The problem is simply, a Named Pipe issue. Restarting re-creates the Named Pipe under the correct log on account.

If the restart fails, and you're still having problems connecting to SQL Server Remotely, try the following:

Set the log on account permissions on:

C:\Program Files\Microsoft SQL Server
C:\DATA DIRECTORY

for the log on account. You'll need to set "Full Control" permissions and make sure that you re-apply the rule to all children by clicking on the directory properties>Security>Advanced>Permissions>"Replace permission entries on all child objects..."

Hope that helps.

General Database Design Guidelines and Naming Conventions

Brian Chavez — Wed, 15 Aug 2007 14:18:35 GMT

Here are some helpful tips on database naming conventions. Consistency, readability, maintainability, and extensibility are some of the most important factors when designing new databases. In this blog I'll go over some conventions I use to keep myself consistent. If you have any conventions you follow or ways to improve these conventions, let me know. :)

Entity Class Naming

The name of our entity classes should be in the singular form, for example Account, Customer, or User (for a user accounts table). Plural names (such as Accounts, Orders, and Order Details) aren't good candidate for entity names because 1) plural names don't grammatically fit well when reading relationships that are self-referencing and one-to-one 2) it reduces the readability of SQL statements when fully qualified names the WHERE clause. To Illustrate:

/* Using singular form */

SELECT * FROM Account WHERE Account.ID = 1;

/* Using plural form */

SELECT * FROM Accounts WHERE Accounts.ID = 1;

If you ask me, the singular form reads much better in the WHERE clause, but the plural form performs better in the FROM clause. When creating complex SQL queries, readability in the WHERE clause tends to outweigh the benefits of readability in the FROM clause. This is why singular table names are generally better. Furthermore, the name of the entity should be representative of a single row in the table. Names like History, Schedule, and Table are not descriptive enough.

For certain types of entities, special keywords should be contained in the naming of the entity. Below is a list of special entities and associated key words that should be considered a part of the naming scheme.

Tracking History: History, Historical, Event

Attribute Naming

Below is a small list of naming guidelines for naming columns based on the type of data they hold.

Identifiers: Number (or No), Code, Identifier (or Id), Tie-Breaker
Categories: Type, Method, Status, Reason
Counts: Count
Dimensions: Length, Width, Height, Weight
Amounts: Amount, Price, Balance
Factors: Rate, Concentration, Ratio, Percentage
Specific Time Points: Timestamp, DateTime, Date, Month, Year
Recurrent Time Points: TimeOfDay, DayOfWeek, DayOfMonth, DayOfYear, MonthOfYear
Intervals: Duration, Period
Positions: Point, LineSegment, Polygon
Texts: Name, Description, Comment, Instructions

Try to avoid abbreviations; it may likely confuse business people using the database.

Natural Keys vs Surrogate Keys

When choosing the primary key for a table, often in designs, natural keys occur in the business problem. For example, if we're modeling a Person table in our database we might be inclined to use the Social Security number (a natural key) of a person as the primary key in the Person table. This isn't a bad design, since everyone in the US should have a Social Security number; however, keying the Person table with a Social Security number as the primary key doesn't lead to an extensible design. What happens if the system and database we're designing for needs to handle people who are not US citizens or people who don't have a Social Security number? As you can see, using a Surrogate Key named PersonId with an identity constraint as our primary key is a much better extensible database table design than using a natural key. In most cases, even if the natural key is truly unique, I would still use a Surrogate Key.

That's all for now! If I come think of some more, I'll add them to this blog post later. :) Keep in mind there is no "best practice" because any best practice can be turned into a worst practice if the situation changes. The point is the schema design of every database should be well thought out. Being consistent in your designs help leads designs to be readable and maintainable. Extensibility leads your designs to be changed and refactored when business processes change.