PFC II - SQL Server 2005
¿ Por qué si necesito tener definido un puerto concreto para el servidor SQL Server 2005 para lograr que me conecte Visual Studio 2005 con él desde el explorador de servidores? Respuestas sin solución. No es la única que se me está planteando en estos primeros días trabajando con dicho servidor de bases de datos. Tenía experiencia previa con SQL Server 2000 y parecía más sencillo y, por tanto, más fácil de usar. Menos opciones, menos programas de gestión y aplicaciones esotéricas del estilo a “SQL Server Surface Area Configuration” que vienen ahora con las versiones adultas de este SGBD.
¡Qué difícil es encontrar un buen manual introductorio! Es decir, el típico que te indica qué tienes que hacer en los pasos más habituales. Por ejemplo, que me cuente que lo más probable es que a las primeras de cambio me salga ese mensaje de error reclamándome activar el acceso mediante “Named Pipes” porque de lo contrario no voy a poder trabajar “correctamente” con el servidor. Uno que te diga qué esquema es más seguro, si seguridad integrada con las cuentas de usuarios de Windows o seguridad gestionada con usuarios del propio SQL Server (yo sigo sin tenerlo claro, aunque leí por ahí que era más seguro lo primero). Dejo aquí un enlace interesante para empezar a trabajar, aunque en este caso esté orientado a SQL Server 2005 Express:
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_0005.asp
Resuelta la instalación y conexión con SQL Server empiezan las dudas filosóficas sobre la arquitectura. Son las de siempre que uno hace una aplicación que, de alguna forma, tiene que usar y conectar con la base de datos:
- ¿Debería crear una cuenta específica (ya sea en Windows o en el propio SQL Server, según la autenticación escogida) o uso la “genérica”, que si no me equivoco es la Network Service (me parece que es sobre la que corre ASP.NET (IIS vamos) y, por tanto, la que va a lanzar las peticiones que mi aplicación web haría sobre la base de datos? Si ni siquiera tengo claro el esquema por defecto, como para saber escoger el mejor esquema.
- ¿Inserto el código SQL en la propia aplicación o utilizo procedimientos almacenados? Ésta es más fácil de responder, es mejor usar “Stored Procedures” siempre que sea posible, además de ser más seguros. En cualquier caso, hay que usarlos mediante consultas “parametrizadas” con el operador “?” para evitar cualquier tipo de inyección SQL. Esto puede resultar algo “engorroso” pero mi escasa experiencia en el campo de la seguridad me hace pensar que “seguridad” y “engorroso” van frecuentemente unidos.
- ¿Creo un par de clases para aislar las reglas de negocio de la aplicación de la base de datos, haciendo que dichas reglas llamen a los procedimientos por mí dispuestos de recuperación y actualización de la información, o por el contrario hago que las reglas creen la conexión a la BD, llamen al SP correspondiente y después cierren dicha conexión? ¿Siguiendo el primer esquema podría implementar un pool de conexiones lo cual haría mucho más eficiente la aplicación aunque podría, imagino (que no lo sé) generar algún tipo de problema si se acabaran esas conexiones (problema de escalabilidad)? ¿La abuela fuma?
En fin, tengo más dudas que certezas, si alguien se anima a responder a alguna de ellas, estaría terriblemente agradecido. Si yo salgo de alguna de ellas con conocimientos firmes, ya iré comentándolo por aquí.
