Estos proveedores de acceso a datos por su naturaleza, la de ser genericos, traia como consecuencia un bajo rendimientos en las operaciones. En terminos sencillos, lo generico es lento en contraparte de lo especializado.
Los proveedores como OLEDB y ODBC tienen que enfrentarse a diferentes base de datos como SQL Server, ORACLE, DB2, MS Access, etc. para obtener resultados y realizar operaciones de escritura.
El que mucho abarca poco aprieta, reza un viejo refran.
Felizmente, cada motor de base de datos liberó, posteriormente, sus propios interpretes para facilitar la vida de los developers y mejorar el performance del producto de software que accede a dicho motor de base de datos.
Estos nuevos interpretes estan totalmente especializados para realizar operaciones sobre aquellos motores para los cuales fueron liberados.
Por sentido comun, si estas especializado en algo, eres más rapido y eficiente en realizar operaciones en aquello que sabes hacer.
No arrastremos prejuicios acercar del performance de una aplicación en funcion al tiempo de respuesta de la operacion contra base de datos, cuando se utilizaban proveedores como OLEDB y ODBC.
Decir aquello: "... no hagas SELECT * FROM table, por que es muy lento, usa Stored Procedures...". Ya no tiene asidero, a estas alturas del partido.
Sin embargo en las operaciones de escritura, aun deberia usarse los omnipresentes Stored Procedures, pero como consecuencia de otros argumentos.
No comments:
Post a Comment