Webcast: The SQL Service Broker Advanced Performance Tips and Tricks Webcast is today
If you’re not registered you can get there now. The webcast doesn’t start until 12:00 pacific giving you plenty of time to get signed up. Steve Wynkoop is our presenter. You can count on Steve to provide helpful insight to solving real world problems. In his webcast he will be looking at some of the advanced features of SQL Service Broker as well as some of the advanced techniques which can be used to maximize the performance of the SQL Service Broker. Come join us and learn what the Service Broker can do for you.
> Register Now
> Live date: 11/3/2010 at 12:00 Pacific
Featured Article(s)
Tips for using SQL Server 2008 Transactional Replication
In this article, you can find some tips to performance tune and optimize SQL Server 2008 transactional replication.
Featured White Paper(s)
An Introduction to Workload Tuning
Workload Tuning is just what it sounds like: tuning the performance of all processes that comprise a database workload in one… (read more)
Database Modeling
I came across this gem of a web page with links for dozens of database modeling tools. So, today I’m going to talk a little bit about Database Modeling and communicating a database design to those who work with it. I have found that people have two different ways of understanding a database.
Some people can look at a database diagram (entity relationship diagram) demonstrating all of the tables, relationships between those tables, Primary Keys and Foreign Keys and they are good to go. Some prefer more content in the diagram demonstrating each column, the datatype the column uses, nullability, default or check constraints, etc. They can look at this diagram and find it easy to code applications or consume the data.
Other people look at a diagram, and it doesn’t confirm the database design as meeting their needs to them. This second group (no less intelligent…their brain just works differently) prefers to see a table with data in it. They make the connections to the other tables by seeing the data in the foreign key columns matching the data in the primary key column of another table.
For both these groups I have found it important to have a data dictionary. SQL Server allows 128 characters in table and column names (sysname data type). So, it is often beneficial to use longer table and column names that are more descriptive, even it it means more typing when accessing the data. With auto completion in SSMS it makes sense to make your table/column names more descriptive. Still, a data dictionary with definitions for columns is often valuable. You can use extended properties on your tables to hold descriptions; but, they do not readily appear for the average developer or report writer.
You probably know by now that I am a BIG advocate of Agile methodologies. One of the primary practices of Agile is to "Document only what is necessary." This is primarily due to the fact that creating and maintaining documentation is time that doesn’t directly produce software. In my opinion, a database diagram and data dictionary are minimal. The amount of time it takes to create and maintain is easily revovered by clear communication of the intent of your design to those who must work with it., especially when your database is very big.
So, enjoy the link, find some tools that fit your budget. I haven’t found a free one yet that matches the capabilities of the commercial products. But that is no excuse not to model.
I’d like to get your input. There are a few things you could share with our readers. What are your favorite modeling tools or techniques, and why. How you name your tables or columns. How you communicate the database with the developers and end users. Send you ideas, experiences and suggestions to btaylor@sswug.org.
Cheers,
Ben