by Arlyn R
In the article, “Physical Database Design Consideration” by Greg Larson, it answers and provides some answers to questions that come up in designing a physical database. The author provides information and some guidance to help the designer understand the outcome from given choices. Larson covers data types and the difference between variable and fixed -length characters, whether to allow nulls or not, different date data types, and index guidelines. The article advises to use CHAR and NCHAR data types for data that have similar length size and do not have many NULLS. These columns will most likely be populated with the same range of characters and the space for these columns will be used up no matter what. Therefore, VARCHAR can save storage space if the data type can and is frequently NULL.
In regards to whether to use Non-Unicode versus Unicode, Larson explains changing a database to support Unicode can be much more expensive than purchasing hardware to handle the larger character set. The author goes on to show the storage size differences between integer values and suggests to scale up to the next larger integer type because only a small amount of disk space is wasted and makes the database flexible to future changes. Larson displays a table to show the six different date data types SQL Server 2008 offers and to obviously choose the one that is applicable to the business rule. Finally, the article gives five things to consider when creating indexes which provide short cuts to database queries. Greg Larson recommends to “…find the balance between conserving disk space and supporting future data requirements,” which this article efficiently supports.
Now that we have entered into the physical database design, this article proves relevant especially in the details of data types. I found the articles explanation on when to use VARCHAR versus CHAR helpful. I agree with the author that using Unicode character sets is best even if the business is operating in one national economy. In my opinion, most businesses strive to enter and sustain in the global market and so creating a physical database to support the business’s future will make it robust. This article was very informative yet easy to understand and covered situations that prove helpful as we start to transform our design to a physical database.
Larson, G. (2011, December 21). Physical Database Design Consideration. Retrieved from http://www.databasejournal.com/features/mssql/physical-database-design-consideration.html. Retrieved on October 28, 2012.