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.

Advertisements

Software development technologies (Introducing SAL: Software Assembly Line)- Tecnologías de desarrollo de software


When searching on internet to find the best method to create or modify software what will we find? A LOT of methods, architectures, patterns, etc. How can we deal with that? what to trust? If we know someone that is using some of these methodologies and it’s working fine, we can start with that, but what if we don’t? Just to list some of the actual methodologies (to know more about any of them, just search the name listed plus the word methodology):

  1. Waterfall
  2. EVO
  3. Crystal
  4. EUP
  5. AUP
  6. EssUP
  7. OpenUP
  8. MSF
  9. FDD
  10. CMMI
  11. PMBOK
  12. Prince2
  13. DSDM
  14. RUP
  15. LeanSD
  16. USDP
  17. XP
  18. Scrum
  19. Prototype
  20. Spiral
  21. ……and a lot more

So, what is the main goal of all of these methods? Answer: to create excellent software. And all they have the same sources as well: Stakeholders, Processes and Data. Nothing else, so when in this life this becomes so complicated?

Trying to get the best results people or engineers use existing methods to create new ones.

Starting with the fact that the source to create software is Always the same we can deduct this:

  1. Stakeholders, processes and data are the sources to create the software.
  2. We need to understand in the most exact way the requirements for the software talking with stakeholders until we and they are complete sure everything related is correctly written.
  3. Create a design for the new software and show it to the stakeholders until its accepted making the proper changes.
  4. Start to develop the software.

And I call that: SOFTWARE ASSEMBLY LINE

This is needed for any of the existing methodologies, the difference is how we use the sources. What I can tell right now is that We cannot create software if the source is not telling us exactly what they need. Once we know what to do and the design is accepted, we are done. How to construct the software is just a matter of what the stakeholders want (web, desktop, mobile, Tablet, tv, or any device).

All these methodologies are good enough to create software, We just need to know the proper one and go through that. Or We can just: create software by using SOFTWARE ASSEMBLY LINE – “SAL”. If you need the Methods and specifications for SAL, kindly live me a message.

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

Al buscar en Internet los mejores métodos para crear o modificar el software que vamos a encontrar? Una gran cantidad de métodos, arquitecturas, patrones, etc ¿Cómo podemos lidiar con eso? en qué confiar? Si conocemos a alguien que está usando alguna de estas metodologías y está funcionando muy bien, podemos empezar con eso, pero lo que si no lo hacemos? Sólo para enumerar algunas de las metodologías actuales (para saber más sobre cualquiera de ellos, sólo buscar la palabra metodología más el nombre listado): 1.Waterfall 2.EVO 3.crystal 4.EUP 5.AUP 6.EssUP 7.OpenUP 8.MSF 9.FDD 10.CMMI 11.PMBOK 12.Prince2 13.DSDM 14.RUP 15.LeanSD 16.USDP 17.XP 18.Scrum 19.Prototype 20.Spiral 21 ……. y mucho más

Así que, ¿cuál es el objetivo principal de todos estos métodos? Respuesta: crear un excelente software. Y todos ellos tienen las mismas fuentes, como son: las partes interesadas (stakeholders), procesos y datos. Nada más, por lo que, cuando en esta vida, esto se volvió tan complicado?

Tratando de obtener los mejores resultados los ingenieros y otras personas utilizan métodos existentes para crear otras nuevas metodologías.

Empezando por el hecho de que la fuente de la creación de software es siempre la misma, podemos deducir lo siguiente: 1.Stakeholders, los procesos y los datos son las fuentes para crear el software. 2.Se debe entender de la manera más exacta los requisitos para el software que hablando con los stakeholders hasta nosotros y ellos estemos completamente seguros que todos los requisitos relacionados están escritos correctamente. 3.Crear un diseño para el nuevo software y mostrar a las partes interesadas hasta su aceptación haciendo los cambios adecuados. 4.Iniciar a desarrollar el software.

Y esto lo llamo: SOFTWARE LÍNEA DE MONTAJE (SLM o SAL en inglés)

Esto es necesario para cualquiera de las metodologías existentes, la diferencia es la forma en que utilizamos las fuentes. Lo que puedo decir ahora es que no podemos crear software si la fuente no nos dice exactamente lo que necesitan. Una vez que sabemos qué hacer y el diseño es aceptado, hemos terminado. Cómo construir el software es sólo una cuestión de lo que los stakeholders quieren (web, escritorio, portátiles, Tablet, tv, o cualquier dispositivo).

Todos estos métodos son lo suficientemente buenos para un proyecto, sólo necesitamos saber el adecuado y listo. O podemos simplemente: crear software utilizando SOFTWARE LÍNEA DE MONTAJE – “SLM”. (Software Assembly Line SAL). Si desea los métodos y especificaciones puede dejarme un mensaje.

Software Design Patterns / Patrones de Diseño de Software


Software Patters are just “Solutions to recurring problems in software development”, its independent from the development tool and language. Better than antipatterns, We can see these as good examples on how to create good software, because almost everything is already studied and analyzed, we must take advantage of that previous knowledge and stop inventing the wheel everytime.
Patterns is not just “code reuse” its the “whole” knowledge for a solution. Thinking in all created software must “change” or “grow” to keep alive, the patterns are the best way to do these changes without reconstruct most of the code everytime.
Each time we need to create new software, a design must be applied, if We use design patterns, we can guarantee success as the pattern is being success in many projects.
There are many kinds of patterns to use, but the main goal for each one is to have the following characteristics:

1. Client should always call the abstraction (interface) and not the exact implementation.
2. Future changes should not impact the existing system.
3. Change always what is changing.
4. Have loose coupling
*Inheritance ( Very coupled )
*Composition
*Aggregation
*Association
*Dependency
*Realization ( Least couple )

Some examples of Design Patterns to search for are:
MVC (Model View Controller) separates the representation of information from the client side (user’s interaction). Must be identificable Data, Business Rules, Login and Functions.

MVP (Model View Presenter) is derivated from MVC, but the Presenter handles all the presentation logic. This facilitate automated unit testing and improve the separation of concerns in the presentation logic.

There are other propietary patterns for Microsoft’s development tools like MVVM, MVPVM. You can search them to understand specifically about them.

Summary: Design Patterns in Software Development are only templates that allow us to work quickly and safetly(for results) when creating software.

********************************************************************Español:
Patrones de Software son sólamente “Soluciones a problemas recurrentes en desarrollo de software”, es independiente de la herramienta de desarrollo y lenguaje. Mejores que los antipatrones, podemos verlos como ejemplos de cómo crear buen software, porque casi todo ya ha sido estudiado y analizado, debemos tomar ventaja de ese conocimiento previo y parar de inventar la rueda cada vez.
Los Patrones no son sólo “Reutilización de código”, son el conocimiento “completo” de una solución. Pensando en que todo software creado debe “cambiar” o “crecer” para mantenerse vivo, los patrones son el mejor camino para realizar estos cambios sin tener que reconstruir la mayoría del código en cada momento.
Cada vez que necesitamos crear nuevo software, un patrón de diseño debe ser aplicado, si lo hacemos, podemos garantizar un éxito tanto como el patrón siempre lo ha tenido en muchos proyectos.
Existen muchas clases de patrones para usar, pero el principal objetivo de cada uno debe tener las siguientes características:

1. El Cliente debe llamar la abstracción (interface) siempre y no la implementación exacta.
2. Los cambios futuros no deben impactar el sistema existente.
3. Cambiar siempre lo que necesita cambio.
4. Mantener acoplamiento flexible
*Herencia ( Muy unido )
*Composición
*Agrupamiento
*Asociación
*Dependencia
*Realización ( Menos unido )

Algunos ejemplos de Patrones de diseño para buscar son:
MVC (Modelo Vista Controlador) separa la representación de la información de la interfaz de usuario. Deben identificarse Datos, Reglas de Negocio, Acceso usuario y funciones.

MVP (Modelo Vista Presentador) derivado de MVC, pero el presentador realiza todo el manejo de presentación y lógica. Esto facilita pruebas unitarias automatizadas y mejora la separación de inquietudes de la lógica de presentación.

Existen otros patrones propietarios para herramientas de desarrollo Microsoft como son MVVM, MVPVM solo para citar algunos que no son de dominio público en cuanto a la herramienta de desarrollo.

Resumen: Los Patrones de Diseño para Desarrollo Software son solo plantillas que nos ayudan a trabajar más rápidamente y con seguridad(de resultados) cuando realizamos software.