Buenas prácticas de codificación para capas de acceso a datos de aplicaciones | SolidQ Summit 2012

Buenas prácticas de codificación para capas de acceso a datos de aplicaciones

REL300007

Enrique Catalá Bañuls Mentor – Relational engine

MAP 2012 – Microsoft Technical Ranger – Microsoft Certified Trainer

[email protected]

Enrique Puig Nouselles DPE – Relational engine MAP 2012 – Microsoft Technical Ranger – MCPIT SQL Server

[email protected]

Agenda

Patrones de acceso a datos

Entity framework Eager

Lazy

Stored procedure

Rendimiento

Nuevas arquitecturas DAL para SQL 2012 MERGE + TVP + SECUENCIAS

Otros lenguajes

Tipología de acceso Set-based solutions

Cursor-based solutions

Patrones de bajo nivel Dinámico

AD-HOC

Parametrizable

Estático

Stored procedures

Arquitecturas Modelo de conectividad

Conectada

Desconectada

Modelo de desarrollo

Manual

ORM

Patrones de acceso a base de datos

Bajo nivel

Motor relacional trabaja con conjuntos de información

Generan código espagueti

Solo funcionan en un único core Malísima gestión de recursos

Típico problema de: tengo 4 cores…si lanzo 4 cursores reviento el sistema

Generan tráfico de red excesivo

Consumo de CPU y E/S del orden de 100.000x ¿no te lo crees? espera a ver la demo


Bajo nivel: cursores

Facilidad de codificación aparente El developer de la app puede lanzar queries a su

antojo

Problemas de escalabilidad Escasa o nula reusabilidad de planes de ejecución Incremento de uso de CPU, Memoria y E/S

Problemas de seguridad Permisos SQL Injection habitual


Bajo nivel: ad-hoc

string str= "select name

from sys.tables

where name like ‘ " + variableWhere

-- qué ocurre si -- variableWhere = %';select 'hola mundo'

sp_execute Ejecuta un T-SQL preparado usando un handle

No recomendado uso manual

Utilizado por algunas dll antiguas ADO

Demasiado viaje ida-vuelta

sp_executesql Parametrizar consultas ad-hoc fácilmente

Recomendado siempre que tengamos que lanzar ad-hoc


Bajo nivel: parametrizable

sp_execute handle OUTPUT [

,bound_param ] [ ,...n ] ]

sp_executesql

[ @stmt = ] statement [ { ,

[ @params = ] N'@parameter_name data_type [ OUT | OUTPUT ][ ,...n ]' } { ,

[ @param1 = ] 'value1' [ ,...n ] } ]

Compilación de una o más sentencias T-SQL

Acepta múltiples parámetros de entrada y de salida

Punto de entrada preferente a SQL Server Mejora el desacoplamiento

Mejora el uso de recursos

Facilita desarrollos eficientes con equipos de trabajo especializados

Minimiza problemas de seguridad

Reutilización de código


Bajo nivel: stored procedures

DEMO DEMO Cursores vs query standard

Ad-hoc vs parametrización vs stored procedures


¿Por qué aparecen los ORMs?

Fundamentos

• Diferencia de roles

• Desarrollador vs. DBA

• Independencia de la

aplicación

• Uso de modelo de datos

• Abstracción de servidor de

base de datos

• SQL Server

• MySQL

• Oracle

• …

Más motivos

• Rechazo a T-SQL

• Manejo de cadenas para

acceso a datos

• Errores en tiempo de

ejecución vs. Compilación

• Uso de lenguajes más

familiares

• Es más “cool” usar EF o

JPA.

Pros Autonomía completa del desarrollador

Liberias automáticas de generación de código contra BBDD

Linq2Sql, EF,…

Tiempo de desarrollo reducido

Te sientes mas “cool” cuando hablas con tus compañeros

Contras Poca escalabilidad

Un DBD conoce mejor el motor que un desarrollador general

Dependencia total de aplicación cliente y del código fuente

¿Qué pasa si es desarrollador externo y nos deja?

Dejas de pensar en que la tecnología usada es “cool” cuando lo pones en producción


ORMs: Pros vs contras

Agenda



Lazy

Stored procedure

Rendimiento


Otros lenguajes

Entity framework

¿Cómo piensa un desarrollador?

Entity Framework

¿Cómo piensa un DBA?

EF: Entity Data Model

Entity Framework

Modelo de Datos

Modelo

Conceptual

• Entidades

• Relaciones

Modelo lógico

• Tablas

• Claves

Modelo físico

• Particiones

• Índices

Entity Framework

Entity Data Model

Mapping

Tabla

Tabla

Tabla

Tabla

Tabla

Nos olvidamos de la base de datos Solo importa el modelo conceptual

Trabajamos con un modelo de objetos Operaciones CUD

Consultas

Modelo de objetos

Eager Loading

Lazy Loading

Entity SQL

LinQ

Native SQL

Procedimientos almacenados

Entity Framework

Entity Data Model

Reducir líneas de código en capas de acceso a datos

Abstracción de motor de BD

Curva de aprendizaje pequeña C# o VB

LinQ

Modelo de objetos

Errores en tiempo de ejecución

Aplicación moderna

“Un gran poder conlleva una gran responsabilidad” Tío Ben (Spiderman)

Entity Framework

Ventajas para el desarrollador

DEMO DEMO Consultas con EF

Métodos Eager loading

Lazy Loading

Modelo objetos

LinQ

EntitySQL

NativeSQL

Procedimientos

¿Comparamos rendimientos?

Entity framework

¿Cómo programo consultas en Entity Framework?

DEMO DEMO Comparación de rendimiento de consultas en EF

Comparativa

Rendimiento por técnica

0

1000

2000

3000

4000

5000

6000

7000

1 2 3 4 5 6 7 8 9 10

Time (ms)

Lazy Loading

Eager Loading

LinQ

NativeSQL

SP

Comparativa

Native SQL + LinQ + SP

0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5 6 7 8 9 10

Time (ms) LinQ

NativeSQL

SP

Agenda



Lazy

Stored procedure

Rendimiento


Otros lenguajes

“Mi aplicación quiere propagar ‘n’ modificaciones a BBDD”

Aplicación posee estructura en memoria con información a procesar

DataTable por ejemplo si usamos .NET

Usuario modifica los datos Mediante un grid, por ejemplo se modifican ciertos datos

Usuario quiere guardar los datos Tiempo despues, queremos que todos los cambios se propaguen

Queremos minimizar bloqueos y maximizar el rendimiento

Arquitectura eficiente con SQL Server 2012

Problema a resolver

Cada operación se trata de forma independiente Elevado nº de idas y venidas al servidor es elevado

SQL Server no tiene información sobre todo lo que modificar Estrategia de bloqueos imposible de optimizar

3 planes de ejecución INSERT, UPDATE y DELETE

En el mejor de los casos…si se opta por AD-HOC…

Gestión ineficiente por parte de DAL


Propuesta de solución habitual

Una única operación

Una única ida-venida al servidor

SQL Server tiene información sobre todo lo que modificar

Estrategia de bloqueos optimizada

Gestión eficiente por parte de DAL

DAL no se preocupa de qué ha ocurrido con el conjunto de datos


Propuesta de solución eficiente

Fácil implementación Fácil mantenimiento Rápida de codificar Basada en características que aprovechan el motor TVP (parámetros de tipo tabla) Cláusula MERGE Secuencias

Tiene una pega…ningún ORM actual soporta TVP ¿Puedes sacrificar un poco de desarrollo a cambio de

gran escalabilidad?


Problema maestro-detalle

DEMO DEMO Arquitectura eficiente con SQL Server 2012

Agenda



Lazy

Stored procedure

Rendimiento


Otros lenguajes

JAVA: Driver JDBC y JPA

JAVA

Consideraciones JDBC

Selection Method

• Direct o Cursor

• Cadena de conexión

• SelectMethod

• Por definición se usa Direct

Ascii vs. Unicode

• sendStringParametersAsUnicode

• True o False

• Cadena de conexión

• Envió de cadenas como Unicode

siempre

• Impacto en rendimiento

• Suprime la indexación

• Conversiones implícitas

JAVA

SelectMethod=Direct

Aplicación

Memoria Datos

JAVA

SelectMethod=Cursor

Aplicación

Memoria Datos

DEMO DEMO JDBC: SelectMethod y sendStringParameterAsUnicode

JAVA

JDBC: Selection method pros y contras.

Direct

• Pros

• Información disponible

inmediatamente

• Mayor rapidez de iteración

• Más rápido

• Contras

• Mayor consumo de

memoria

• Aprovisionamiento de

memoria para el peor de

los casos

• Mayor carga en red

Cursor

• Pros

• Requiere poca memoria

• Más rapidez mostrando

datos en app

• Pide menor nº de filas

• Excepto Order By

• Contras

• Más lento

• Dispara actividad y CPU

en servidor

• Muchos roundtrips en

red

Java persistence API

ORM basado en Toplink e Hibernate

La versión Entity Framework de Java

Presenta los mismos problemas que EF

Soporta operaciones CUD

Métodos de consulta Modelo de objetos Java

JPSQL

NativeSQL

JAVA

JPA

DEMO DEMO Rendimiento de consultas JPA contra SQL Server

Agenda



Lazy

Stored procedure

Rendimiento


Otros lenguajes

Patrones de bajo nivel Stored procedure

Arquitecturas desconectadas

ORMs SI, pero aplicando buenas prácticas.

Combinados con procedimientos almacenados rinden bien

JDBC Tener en cuenta el selectMode y el envio de parametros Unicode

para no tener problemas de rendimiento.

Al final lo más óptimo siempre es programar lo más cerca del dato posible.

Conclusiones

Si quieres disfrutar de las mejores sesiones de

nuestros mentores de España y Latino América,

ésta es tu oportunidad.

http://summit.solidq.com/madrid/

Síguenos:

http://summit.solidq.com/madrid

Buenas prácticas de codificación para capas de acceso a datos de aplicaciones | SolidQ Summit 2012

Technology

Transcript of Buenas prácticas de codificación para capas de acceso a datos de aplicaciones | SolidQ Summit 2012