Recently one of my articles got published in a site dedicated to SQL Server performance.
Please visit http://www.sql-server-performance.com/pk_or_clause.asp
May 23, 2005
May 18, 2005
Unicode in SQL Server
I hate using Unicode fields unnecessarily. If the data is going to be English only, what is the point of using nchar, nvarchar or ntext? It takes more space. It increases the size of index keys; it reduces the number of rows stored in data pages and makes the database unnecessarily bigger. The performance goes down due to this.
One DBA (a couple of them actually) recently argued with me saying, it will help the future enhancement of internationalization. Good point; you can make field Unicode compliant for the user data so that without major change you can handle non-English data.
How about the data used by the application? Can you handle internationalization by just changing the field into nchar? No. you need additional field to connect with the language data. The front end you have should read the data with the appropriate language. That will be a big change. Unless that is done, none will make use of you 'n' (nchar, nvarchar and ntext) fields.
In summary, use Unicode field only if you have non -English data for that field;
the field is an external (user entry) field and you are going to have Unicode data in the near future Don't use Unicode field for internal data if your application is not capable of handling it.
One DBA (a couple of them actually) recently argued with me saying, it will help the future enhancement of internationalization. Good point; you can make field Unicode compliant for the user data so that without major change you can handle non-English data.
How about the data used by the application? Can you handle internationalization by just changing the field into nchar? No. you need additional field to connect with the language data. The front end you have should read the data with the appropriate language. That will be a big change. Unless that is done, none will make use of you 'n' (nchar, nvarchar and ntext) fields.
In summary, use Unicode field only if you have non -English data for that field;
the field is an external (user entry) field and you are going to have Unicode data in the near future Don't use Unicode field for internal data if your application is not capable of handling it.
May 12, 2005
SQL Server 2005
I was able to have some hands on experiance on SQL Server 2005 express edition today.
Some of the obvious changes are really good to mention:
Schema is playing a major role in this edition. All these years it was like a simple equation where user=schema. This was giving a lot of problems to users who are not the owers. Some people even questioned the validity of schema and asked "do we really need schema with Yukon? (earlier name for SQL server 2005)"
Micorsoft has answered this question well. All the system tables are located unser "sys" schema. Schema is a way of classifying the objects where some pre-defined schemas are available.
Another change is the enhancement to TSQL. It supports CTE (Common Table Expression) which reduces the effort on query development. However, We need to check on the execution plan to see how it is actually implemented.
Some of the obvious changes are really good to mention:
Schema is playing a major role in this edition. All these years it was like a simple equation where user=schema. This was giving a lot of problems to users who are not the owers. Some people even questioned the validity of schema and asked "do we really need schema with Yukon? (earlier name for SQL server 2005)"
Micorsoft has answered this question well. All the system tables are located unser "sys" schema. Schema is a way of classifying the objects where some pre-defined schemas are available.
Another change is the enhancement to TSQL. It supports CTE (Common Table Expression) which reduces the effort on query development. However, We need to check on the execution plan to see how it is actually implemented.
Subscribe to:
Posts (Atom)