Since last 10 years I’ve worked on many projects where in the significant amount of work comes for Performance and Tuning, the first approach is to identify the culprit and quick fix it and the next course of action would be to fix it permanently. In most of the cases what I’ve found is the size of the database grows beyond the expectation (estimation!!), sometimes 300%. Sometimes it has a problem with the data type or index etc. There are many things we should have consider when we design a database and when we develop an application which uses MS SQL Server as backend.
There are some points I think we have to be careful when we design a database or an application go live, this will save our lots of effort in future!!
So, what are the Common Mistakes done in SQL Server?
Well, as I said they are so common that sometimes we just overlooked them and we came to know the significance of these pointers when we got trapped. Based on my experience I’ve pen down 10 points below; this is the part 1 of the series so keep visit this place.
I hope this would have answer some common questions like:
- What data type to be used?
- Difference between varchar and nvarchar!! and varchar vs nvarchar
The first thing which I’ve noticed is length of the data type to be used. One have to be very careful here, one should not use fixed length of data type when one is not sure about the length of the data which is being inserted either from website or from an application; if one fails to choose the correct length it will unnecessarily occupy the valuable disk resource. For example when data which is to be inserted is “Address” and we are not sure of the length we should use variable length data type such as varchar and when we are sure of the length of the data type we should use fixed length data type such as char for “Gender”.
There are cases when I’ve seen where Unicode data are not stored but people have used nvarchar data type for their websites and applications . This will give you a pain when database size grows over a period of time and one is trying to figure out what are the areas we’ve to consider!! nvarchar or nchar should be used when application or website requires to store data in Multilingual format. Both, nvarchar and nchar occupies double the space of stored data the reason is, ncahr or nvarchar uses UTF-16 (16 bit per character ) where as char or varchar uses UTF-8 (8 bit per character) .
Let’s see an example, create a table with 2 column (FirstName and LastName) which uses varchar and nvarchar data type respectively to store data. Now, insert record and then use function len() to count number of characters inserted and datalength() to know how much space it has occupied. Download the script
Also, we should be very careful about the trimming the white space this should be taken care either at front end or at back end.
Here, what I am advising is to use nvarchar or nchar whenever you required to add multilingual support and try to limit it to where it is required the most, say a particular column.
As I said earlier this is the part 1 of the series so keep visiting this place!!
Data Types: It requires careful attention when we design a table and choose type of data we are going to store here and what Data Type we are going to have for particular column of a table! And, that is why choosing right data type is most crucial part of database design, because, if one failed to choose the right data type there could be several pitfall he/she would encounter as the database size grows.
Hi hemant,
ReplyDeleteNice article.
However, I want to know that how much space will a varchar(10) field will occupy in the following cases -
1. Having NULL
2. Having Empty String
Which one is more prefereable to store in case of NO VALUE and why?
Hi,
ReplyDelete1. Null will occupy 2 bytes
2. If you entered empty string i.e. single space it will occupy 1 byte
so, the answer is leave single space. Download the script here http://www.surat-user-group.org/sqlservercitation/scripts/choosingrightdatatype.sql and in any of the record try this out :D
nice article sir.
ReplyDelete