Buenas prácticas de codificación para capas de acceso a datos de aplicaciones | SolidQ Summit 2012
Click here to load reader
-
Upload
solidq -
Category
Technology
-
view
3.984 -
download
5
description
Transcript of 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
Enrique Puig Nouselles DPE – Relational engine MAP 2012 – Microsoft Technical Ranger – MCPIT SQL Server
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
Patrones de acceso a datos
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
Patrones de acceso a datos
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
Patrones de acceso a datos
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
Patrones de acceso a datos
Bajo nivel: stored procedures
DEMO DEMO Cursores vs query standard
Ad-hoc vs parametrización vs stored procedures
Patrones de acceso a datos
¿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
Patrones de acceso a datos
ORMs: Pros vs contras
Agenda
Patrones de acceso a datos
Entity framework Eager
Lazy
Stored procedure
Rendimiento
Nuevas arquitecturas DAL para SQL 2012 MERGE + TVP + SECUENCIAS
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
Patrones de acceso a datos
Entity framework Eager
Lazy
Stored procedure
Rendimiento
Nuevas arquitecturas DAL para SQL 2012 MERGE + TVP + SECUENCIAS
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
Arquitectura eficiente con SQL Server 2012
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
Arquitectura eficiente con SQL Server 2012
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?
Arquitectura eficiente con SQL Server 2012
Problema maestro-detalle
DEMO DEMO Arquitectura eficiente con SQL Server 2012
Agenda
Patrones de acceso a datos
Entity framework Eager
Lazy
Stored procedure
Rendimiento
Nuevas arquitecturas DAL para SQL 2012 MERGE + TVP + SECUENCIAS
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
Patrones de acceso a datos
Entity framework Eager
Lazy
Stored procedure
Rendimiento
Nuevas arquitecturas DAL para SQL 2012 MERGE + TVP + SECUENCIAS
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: