C# + SQL Server developer best practices / Mejores prácticas desarrollador SQL Server + C#


For a developer, start to develop, save data, query data and update data sometimes is the only goal needed for an specific project. Once the project is installed the problems arrive being the first one and most problematic: “too slow”

To prevent this, developers need to construct software that prevents slow performance when executing process on SQL Server databases:

1. Check Indexes with DBA. DBA is there because his expertise working with data, so share with them your indexes to understand the best performance while constructing code, and make a plan when changing to production.

2. Do not create ad-hoc queries. Database performance is really affected by using “burned queries” with instructions like “..where state=’Open'”, you must implement as much as you can queries inside stored procedures with parameters, this way SQL Server will create easily reusable “cache execution plans”.

3. Do not run everything on server side. The use of stored procedures to run the entire application logic on the server is not good, there are a lot of small/medium result size queries that can be handled on client side. Do not affect the database performance by applying any single queries on stored procedures.

4. Avoid to query a lot of data. Bringing too much data when you need only a few records is a bad practice. If that amount of data is needed, always use pagination in the application, this will bring more data only when user request it.

5. Use views. The normal use of views allows SQL Server to create “cache execution plans”, this means next time you call the view, this is optimized to bring data in shortest time.

6. Do not use Cursors. Developers always will find a good reason to create cursors in their stored procedures. Try to avoid this as much as you can because these are very costly in processor and memory for the server. This executes one row at a time.

7. Good Design database. To prevent the use of over joining when querying data. Up to 10 joins in a single query are normal, more than that mean that your design may be in bad design. If you have this problem, try to Normalize your database share some work with the DBA.

8. Use roles to handle security. There are a lot of job in SQL server security to avoid it by using sysadmin or “sa” accounts. If you don’t understand how the security works in the database, take your time to talk to DBA and together prepare some users/ roles to use in the application and avoid the use of “super users”.

9. Design the proper audit system. A lot of projects miss to define the audit system from the beginning and tries to do it after the project was implemented, big mistake. Ask the management/stakeholders what kind of auditory will be needed for the project and apply it from the start of the project.

10. Prepare the test environment. Testing is one of the best and needed tools to guarantee the project will be working as needed. Do not hesitate to help testers with any information they need to test the entire project. If the project fails, the construction of the code is the first implicated.

This rules can be applied to any other database, this is most like generic thinking about database development process.

*************************************************Español:

Para un desarrollador, empezar a desarrollar, guardar los datos, los datos de consulta y actualización de datos es a veces la única meta necesaria para un proyecto específico. Una vez que está instalado el proyecto los problemas llegan, siendo el primero y más problemático: “demasiado lento”

Para evitar esto, los desarrolladores necesitan construir software que no tenga rendimiento lento cuando esté en ejecución en bases de datos SQL Server:

1. Compruebe índices con el DBA. El DBA está ahí por su experiencia de trabajo con los datos, por lo que vale la pena compartir con ellos los índices y retroalimentarse mientras la construcción de código y hacer un plan al cambiar a la producción.

2. No crear consultas ad-hoc (al instante). El rendimiento de la base de datos será muy afectado por el uso de “consultas quemadas” como “..where estado=’Abierto'”, debe poner en práctica siempre que pueda consultas dentro de procedimientos almacenados con parámetros, así SQL Server creará “planes de ejecución de caché” fácilmente reutilizables.

3. No pase todo el lado del servidor. El uso de procedimientos almacenados para ejecutar toda la lógica de la aplicación en el servidor no es bueno, hay una gran cantidad de consultas pequeñas / medianas en resultado como en la instrucción, que se pueden manejar en el lado del cliente. No afectar el rendimiento de la base de datos mediante la aplicación de cientos de consultas individuales en procedimientos almacenados.

4. Evite consultar una gran cantidad de datos. Llevar demasiados datos cuando se necesita sólo unos pocos registros es una mala práctica. Si en realidad necesita esa gran cantidad de datos, use siempre la paginación, esto traerá más datos sólo cuando el usuario lo solicite.

5. Utilice views. El uso normal de views permite que SQL Server cree “planes de ejecución cache”, esto significa que la próxima vez que llame a la vista, estará optimizada para llevar los datos en menor tiempo.

6. No utilizar los cursores. Los desarrolladores encuentran siempre una buena razón para crear cursores en sus procedimientos almacenados. Trate de evitar esto tanto como sea posible ya que estos son muy costosos en el procesador y la memoria del servidor, porque ejecuta una fila a la vez.

7. Un buen diseño de la base de datos. Para evitar el uso de joins excesivos al consultar datos. Hasta 10 joins en una sola consulta son normales, más de eso quiere decir que su diseño puede estar malo. Si usted tiene este problema, trate de normalizar su base de datos, compártale trabajo al DBA.

8. Utilice los roles para manejar la seguridad. Hay un montón de trabajo en la seguridad del servidor SQL para tratar de evitarlo mediante cuentas “sa” o sysadmin. Si usted no comprende cómo funciona la seguridad en la base de datos, tome su tiempo para hablar con el DBA y juntos preparen algunos usuarios / roles para usar en la aplicación y evitar el uso de “súper usuarios”.

9. Diseñar un sistema de auditoría adecuada. Una gran cantidad de proyectos no define el sistema de auditoría desde el principio y trata de hacerlo después de que el proyecto se implementa, gran error. Haga la gestión de preguntar al equipo administrativo / stakeholders de que tipo de auditoría será necesaria para el proyecto y aplíquela desde el inicio del proyecto.

10. Prepare el entorno de pruebas. Las pruebas es una de las mejores y más necesarias herramientas para garantizar que el proyecto va a funcionar. No dude en ayudar a los testers con cualquier información que necesiten para poner a prueba todo el proyecto. Si el proyecto fracasa la construcción del código es la primera implicada.

Estas reglas se pueden aplicar a cualquier otra base de datos sobre la cual se haga un desarrollo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s