viernes, 8 de julio de 2011
sábado, 2 de diciembre de 2006
Es tan bueno escribir codigo SQL fuera del motor?
Bueno, esto es un clasico, muchos desarrolladores/empresas tienen por costumbre escribir todo lo relacionado a la base de datos desde fuera de ella (esto quiere decir no usar Procedimientos Almacenados y luego consumirlos desde el cliente). Durante tiempo existieron varias discusiones sobre este tema, los pros, los contras, etc, etc, es mas es una batalla de hace tiempo ya.
Ahora bien, el otro dia me ha tocado en un cliente hacer una migracion de su servidor 2000 a 2005, hay algunas sentecias de TSQL que ya no son mas compatibles con lo cual Microsoft permite con herramientas poder detectarlas,una de ellas es el Update Advisor, una herramienta de 2005 que se corre sobre una base de datos y analiza los cambios que se deberian hacer (antes - durante o posterior a la migracion), bien esto es excelente si el codigo esta en la base de datos, si el mismo esta fuera no hay forma con esta herramienta de poderlo detectar, entonces que se hace, se levanta una traza del profiler para analizar de todas las llegadas al motor cuales son incompatibles con 2005. Como se podran imaginar este metodo no es 100% seguro ya que TODAS las aplicaciones deberian ejecutar TODOS los modulos con TODAS sus combinaciones para poder asegurar esto, bueno ya tienen una idea de lo costoso no? de hecho a mi cliente el trabajo le salio 4 veces mas de lo normal y no se pudo asegurar el 100% y es mas, en una ventana de la aplicacion en una codincion estaba usando *= lo cual ya no es mas soportado y en el profiler no se vio porque no se ejecuto esa parte de la aplicacion durante los 20 dias que hemos dejado corriendo la traza, en resumen: el proyecto se alargo mucho mas de lo normal (ya que debimos poner la traza durante un tiempo prolongado para poder estar bien seguros), este tiempo tambien se represento en dinero y en dolores de cabeza para el cliente final, entonces, como vengo diciendo desde hace tiempo: es buena idea escribir codigo fuera de la bdd que sea de SQL? ya vimos en varias oportunidades que por seguridad no es buena idea, hay veces que por performance tampoco, pero ahora tambien se nos suma ESCALABILIDAD.....
Ahora bien, el otro dia me ha tocado en un cliente hacer una migracion de su servidor 2000 a 2005, hay algunas sentecias de TSQL que ya no son mas compatibles con lo cual Microsoft permite con herramientas poder detectarlas,una de ellas es el Update Advisor, una herramienta de 2005 que se corre sobre una base de datos y analiza los cambios que se deberian hacer (antes - durante o posterior a la migracion), bien esto es excelente si el codigo esta en la base de datos, si el mismo esta fuera no hay forma con esta herramienta de poderlo detectar, entonces que se hace, se levanta una traza del profiler para analizar de todas las llegadas al motor cuales son incompatibles con 2005. Como se podran imaginar este metodo no es 100% seguro ya que TODAS las aplicaciones deberian ejecutar TODOS los modulos con TODAS sus combinaciones para poder asegurar esto, bueno ya tienen una idea de lo costoso no? de hecho a mi cliente el trabajo le salio 4 veces mas de lo normal y no se pudo asegurar el 100% y es mas, en una ventana de la aplicacion en una codincion estaba usando *= lo cual ya no es mas soportado y en el profiler no se vio porque no se ejecuto esa parte de la aplicacion durante los 20 dias que hemos dejado corriendo la traza, en resumen: el proyecto se alargo mucho mas de lo normal (ya que debimos poner la traza durante un tiempo prolongado para poder estar bien seguros), este tiempo tambien se represento en dinero y en dolores de cabeza para el cliente final, entonces, como vengo diciendo desde hace tiempo: es buena idea escribir codigo fuera de la bdd que sea de SQL? ya vimos en varias oportunidades que por seguridad no es buena idea, hay veces que por performance tampoco, pero ahora tambien se nos suma ESCALABILIDAD.....
Porque no me puedo conectar a SQL2005
En los foros de noticia es muy frecuente que alguien tenga problemas a la hora de conectar a un SQL2005 Express Edition por ej, por lo general el mensaje de error que da es que no se encuentra el servidor disponible.
Bien, sql2005 es seguro por defecto y cuando ustedes por ej instalan un ExPress edition 2005 tienen hasta deshabilitado la opcion de poder conectar. Lo que se debe hacer en estos casos es entrar al SAC (Sourface Area Configuration) y desde la opcion de servicios habilitar las conexiones por tcp/ip.
Tambien es bueno recomendar que hay varias cosas deshabilitadas por default en sql2005, por ej el uso de CLR, el uso de XP_cmdShell, etc. Desde el mismo SAC podran habilitar estas opciones si desean usar esas features nuevas.
Bien, sql2005 es seguro por defecto y cuando ustedes por ej instalan un ExPress edition 2005 tienen hasta deshabilitado la opcion de poder conectar. Lo que se debe hacer en estos casos es entrar al SAC (Sourface Area Configuration) y desde la opcion de servicios habilitar las conexiones por tcp/ip.
Tambien es bueno recomendar que hay varias cosas deshabilitadas por default en sql2005, por ej el uso de CLR, el uso de XP_cmdShell, etc. Desde el mismo SAC podran habilitar estas opciones si desean usar esas features nuevas.
viernes, 1 de diciembre de 2006
Inicio
Hola, por fin me decidi a volver a tener un Blog :) hoy es mi primer dia aqui y espero poder tenerlo lo mas actualizado posible con todo lo que a mi me gusta (SQLSERVER) :)
Suscribirse a:
Comentarios (Atom)
