He says: “...Scientists should stick with science. What they invent and discover should be moved to the real world by engineers, not by scientists as well. Because, if you leave it to scientists, you’ll end up with horrible syntaxis like the ROW_NUMBER() function in SqlServer 2005….”

Read the entire post. Its certainly eye opening to everyone who hasn’t had to implement paging in another db outside of SQL Server.

I have an SSIS package that runs perfectly well in my Integration Studio dev environment, locally. Once it was published to a staging server it kept failing with an assortment of errors pointing to login credential issues. Nothing I tried seemed to help.

If you are coming to SSIS from SQL Server 2000 DTS – boy are you in for a surprise. Some things are way nice, but others – like the configuration management aspects are tough to get used to. As it stands, SSIS Packages maintain various settings in configurations once they are deployed. The first clue to that aspect is when you try to run a package on the server and find that the config string doesn’t contain the password anymore. Say hello to the MS Trustworthy Computing initiative. To the unsuspecting developer this little diddy can be a real doozy. Ok enough with the funny language. Because this wasn’t funny, especially after holding the phone fo four hours waiting for PSS to answer.

Ostensibly the issue had to do with the configuration file used by the package. But even recreating the file and rebuilding / redeploying the package didnt make any difference. I found that using dtexec to run the package from the command line was very useful because it provided immediate feedback. Little by little the PSS Engineer and I narrowed the problem down.

In the end it turns out that a common network design practice got in the way of my configs. You see, our data center has servers with publicly mapped IP addresses and privately mapped ones. In other words there is a public set of addresses that is severely constraints and an internal set of IP’s for the same boxes. My dev environment was able to connect to the staging database using the public IP of that box because our office is physically and from a topology point of view very seperate from the datacenter holding the server. So my package when run locally executed fine but when run on the staging box at the data center it failed because it could not resolve the IP address used. It could not resolve the external IP address used in the config because…. it wasnt running external to the server. See? The solution to all this was to change the config to use the named instance of the database server – as in LA-Staging01 instead of 216.53.93.11 – that did the trick. The package writes whatever is defined in the connection object for SQL Server connection to its config file. Hence the use of the external IP, while completely fine for my dev box, caused the error on deployment.

You might say “d’oh – everybody knows you shouldnt use IP addresses in your config”. Well, I dont know if its that well known but I can say the reason why I wasnt using a named instance for my connections was the fact that I couldnt get the name to resolve properly. Turns out there are two ways one can the name to resolve. One is via the via the the hosts file. Now why didnt I think of that? When working with web sites I am in the hosts file all day long. What was it about this SQL box that made me not connect the dots here. Oh well. The other method is via a SQL utility called cliconfg , which allows you to define a local SQL alias by name and then point that alias to a specific IP. That did the trick.

Now all my connections are using a consistent name for the server the problem is taken care of. Lesson learned.

Amazing how far you can get with a free database….. I still prefer SQL Server, but all the RoR examples I see deal with MySQL, so I had to get a little bit familiar with it.

Thus far the most innovative usage of it that I have seen was the in-memory option of MySQL (which is wicket fast) being used as a fancy caching layer for an Informix based system. Since there are only about two Infomrix dba’s left in this country, I think thats a good approach.

Speaking of LINQ, Caber Computing offers a beta for a product called SqlTac which hopes to do several interesting things. First it attempts to provide a graphical representation of the “soundness” or efficiency of your db. Secondly it allows you to cretae  versioned set of scripts plus a test database containing – you guessed it – test data. Seems like an interesting idea. There are aspects of this tool that are better done by other products. For example dependency analysis is done extremely well by SQL Clean. But this looks promising for the always present need to document and standardize the db.

More Info

One of the hardest things in our industry is to get a team of people to work along the same line. Some have compared managing programmers to herding cats. In my case many of the cats think they know best…..

So here is Louis:

One table to hold all domain values

“One Ring to rule them all and in the darkness bind them“

This is all well and good for fantasy lore, but it’s not so good when applied to database design, in the form of a “ruling” domain table. Relational databases are based on the fundamental idea that every object represents one and only one thing. There should never be any doubt as to what a piece of data refers to. By tracing through the relationships, from column name, to table name, to primary key, it should be easy to examine the relationships and know exactly what a piece of data means.

The big myth perpetrated by architects who don’t really understand relational database architecture (me included early in my career) is that the more tables there are, the more complex the design will be. So, conversely, shouldn’t condensing multiple tables into a single “catch-all” table simplify the design? It does sound like a good idea, but at one time giving Pauly Shore the lead in a movie sounded like a good idea too.

For example, consider the following model snippet where I needed domain values for:

• Customer CreditStatus
• Customer Type
• Invoice Status
• Invoice Line Item BackOrder Status
• Invoice Line Item Ship Via Carrier

On the face of it that would be five domain tables…but why not just use one generic domain table, like this?

This may seem a very clean and natural way to design a table for all but the problem is that it is just not very natural to work with in SQL. Say we just want the domain values for the Customer table:

SELECT *FROM Customer 
  JOIN GenericDomain as CustomerType   
    ON Customer.CustomerTypeId = CustomerType.GenericDomainId     
     and CustomerType.RelatedToTable = ‘Customer’     
   JOIN GenericDomain as CreditStatus   
     ON  Customer.CreditStatusId = CreditStatus.GenericDomainId     
       and CreditStatus.RelatedToTable = ‘Customer’ and CreditStatus.RelatedToColumn = ‘ CreditStatusId’

As you can see, this is far from being a natural join. It comes down to the problem of mixing apples with oranges. At first glance, domain tables are just an abstract concept of a container that holds text. And from an implementation centric standpoint, this is quite true, but it is not the correct way to build a database. In a database, the process of normalization, as a means of breaking down and isolating data, takes every table to the point where one row represents one thing. And each domain of values is a distinctly different thing from all of the other domains (unless it is not, in which case the one table will suffice.). So what you do, in essence, is normalize the data on each usage, spreading the work out over time, rather than doing the task once and getting it over with.

Looks harder to do, right? Well, it is initially. Frankly it took me longer to flesh out the example tables. But, there are quite a few tremendous gains to be had:

• Using the data in a query is much easier:

       SELECT *
             FROM Customer
             JOIN CustomerType
                 ON Customer.CustomerTypeId = CustomerType.CustomerTypeId
              JOIN CreditStatus
                 ON  Customer.CreditStatusId = CreditStatus.CreditStatusId

• Data can be validated using foreign key constraints very naturally, something not feasible for the other solution unless you implement ranges of keys for every table – a terrible mess to maintain.
• If it turns out that you need to keep more information about a ShipViaCarrier than just the code, ‘UPS’, and description, ‘United Parcel Service’, then it is as simple as adding a column or two. You could even expand the table to be a full blown representation of the businesses that are carriers for the item.
• All of the smaller domain tables will fit on a single page of disk. This ensures a single read (and likely a single page in cache). If the other case, you might have your domain table spread across many pages, unless you cluster on the referring table name, which then could cause it to be more costly to use a non-clustered index if you have many values.
• You can still have one editor for all rows, as most domain tables will likely have the same base structure/usage. And while you would lose the ability to query all domain values in one query easily, why would you want to? (A union query could easily be created of the tables easily if needed, but this would seem an unlikely need.)

I should probably rebut the thought that might be in your mind. “What if I need to add a new column to all domain tables?” For example, you forgot that the customer wants to be able to do custom sorting on domain values and didn’t put anything in the tables to allow this. This is a fair question, especially if you have 1000 of these tables in a very large database. First, this rarely happens, and when it does it is going to be a major change to your database in either way.

Second, even if this became a task that was required, SQL has a complete set of commands that you can use to add columns to tables, and using the system tables it is a pretty straightforward task to build a script to add the same column to hundreds of tables all at once. That will not be as easy of a change, but it will not be so much more difficult to outweigh the large benefits.

The point of this tip is simply that it is better to do the work upfront, making structures solid and maintainable, rather than trying to attempt to do the least amount of work to start out a project. By keeping tables down to representing one “thing” it means that most changes will only affect one table, after which it follows that there will be less rework for you down the road.

In the years since the storage engine was re-architected (SQL Server 7.0+) there’s been constant debate on how to appropriately choose the clustered index for your tables. I’ve generally recommended an ever-increasing key to use as a clustered index and many find that counterintuitive. The primary reason people feel it’s counterintuitive is that it creates a hotspot of activity. [If "hotspot" is not a familar term - a hotspot is solely an active place within your table.] Hotspots were something that we greatly tried to avoid PRIOR to SQL Server 7.0 because of row level locking (and this is where the term hot spot became a negative term). In fact, it doesn’t have to be a negative term. However, since the storage engine was rearchitected/redesigned (in SQL Server 7.0) and now includes row level locking, this motivation (to avoid hotspots) is no longer there. In fact, the opposite is true. Hotspots (specifically hot PAGES not hot ROWS) can be very beneficial because they; minimize the number of pages needed in cache, improve the likelihood of the required page already being in cache and in general, they minimize the overall amount of cache required. So, this is why many of us (SQL Server consultants) have changed our recommendation on where to create the clustering key. Instead of focusing on range queries we now focus on placing the clustering key on an ever-increasing key. In earlier releases focusing on range queries for the clustered index reduced hotspots for insert/update and this in fact was the PRIMARY motivation to choose them, NOT range query performance! But – there are even MORE reasons to choose an ever-increasing key and they are based on internals as well. These internals are based on the significant changes made in the storage engine for 7.0+.

Read Article.

The one drawback to site navigation is that XmlSiteMapProvider is the one and only site map provider included in the box with ASP.NET 2.0, which means that site maps must be stored in XML files. Even before ASP.NET 2.0 shipped, developers were clamoring for a means to store site maps in databases.

Read Article.

• Daniel Zeiss is on rev 9 of his major Ajax framework comparison. Great stuff.
• Today I installed ScrewTurn Wiki in 10 minutes (as opposed to an hour for Sharepoint2007)
• Another very cool color scheme generator
• Microsoft has updated the XML Notepad. It has some very cool features. 
• Nicelist of links for Reporting Services 
• A comparison of Themes versus CSS
• Atlas crash course part 1
• Atlas crash course part 2
• Creating and using your own custom events
• Enum to list converter
• Chad Finsterwald Server Side Validation Lib
• Convert the .NET tilde to normal path in js
• Prototyping wireframes directly in FF browser
• Edit CSS in Both IE and FF 
• Examine the XML output of a webservice
• Looking for an open rest-based api?
• Nice! Chad Finsterwals Reg Expressions Class. Patterns all set to verify one or multiple matches 
• Interesting discussion of scheduled app execution in asp.net
• The Commerce Server team used divs and design time properties to create layout flexibility in their product
• RadRails made some progress - 
• Whitpaper on sql server db physical design decisions. 
• Tools for sys admins
• Rick Strahl talks about Atlas
• Craig Dunn - Generics serialization and Unit Tests (via Jason Haley) 
• Everything you need to create and manage IIS sites in code - 
• Ward Pond’s Time Zone Table
• A must read. The Definitive Guide to ASP.NET ViewState