I found that there were several factual errors in the article and several differences of opinion. The following is a list, in no particular order:

1) "where the developer has free access to the production servers..."

DO NOT let the developers have free access to the production server(s). We can debate how much access to grant them in the development environment but Production is for real. Hands Off!!!

2) "The developer may choose to create a database..."

DO NOT let the developers create databases. If they must be allowed, do it through a script that you keep in some source code control mechanism (e.g., SourceSafe, et al.)

3) "The recovery model is by default full..."

The recovery model defaults through the MODEL database. MSDE deafults this to Simple; others versions to Full.

4) "The transaction log settings should be kept to simple..."

This is a recipe for disaster. While the log files do grow in the other two modes, this is precisely what allows you to recover all (most?) of your data in the event of a failure. Regular backups should be run in order to prevent excessive growth of the log files.

5) CHAR vs VARCHAR - There are conditions where VARCHAR consumes MORE space than CHAR and results in slower performance.

6) "The transaction isolation level should be set to low wherever possible."

The isolation setting is a trade-off between speed and data integrity. There is no simple rule that can be universally applied. You could just as easily argue here that the isolation level should be set as high as necessary.

Steve Hendricks

MCSD, MCDBA

AFS Consulting Group

shendricks@afsconsulting.com

(949) 588-9800 x15