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í.
Los de Microsoft me da la impresión de que están lanzados en una carrera a ver si pueden degradar el producto hasta el máximo posible… Personalmente creo que ADO.NET representa un cierto retraso con respecto a ADO (lo de trabajar desconectado y tal), pero lo de SQLServer2005, que no permite utilizar los campos de un ResultSet de forma no ordenada (si utilizas el campo 3 de un registro ya no puedes utilizar el 1 ni el 2, al menos con Java), algo que sí permitía el SQL2000……… vamos hombre, ¿pero qué clase de patán ha programado el puto driver?
Comment by Lek — August 31, 2006 @ 11:52 am
No sé como será fuera de .NET, porque yo siempre he conectado con un SQL Server ha sido a través del namespace System.Data.SqlClient, pero ya te digo que si utilizas la clase DataReader (que viene a ser algo parecido al ResultSet de JDBC, si no me falla la memoria) sí que se puede acceder a campos aleatoriamente. Eso sí, la clase está diseñada para ser accedida de forma secuencial, toda de una vez, porque permanece conectada a la base de datos por lo que, digamos, lo suyo es descargar toda la información lo antes posible y después desconectar de la BD (esto se hace por escalabilidad).
La otra opción es el DataSet, que es como una minibase de datos que se carga en memoria de un tirón y después se desconecta automáticamente de la BD. Cuando sea necesarios más datos o actualizar los de la BD con los que está manejando el cliente, se vuelve a conectar, se hace el volcado y se cierra otra vez. Una cosa parecida es el DataTable, que representa una sola tabla en lugar de BD.
No sé si todo esto está disponible para su invocación desde Java. Imagino que en Java habrá que usar algún puente JDBC-ODBC y quizás estas funcionalidades no están presentes, pero ya te digo que en el propio .NET hay un espacio de nombres System.Data.ODBC y que en principio tiene sus propias clases DataReader y DataSet con un comportamiento idéntico al que tendrían si fuera otro el conector a la BD utilizado (o al menos eso proclama Microsoft, que todos los conectores ofrecen la misma funcionalidad aunque diferente rendimiento).
Comment by Administrator — August 31, 2006 @ 4:15 pm
He trabajado con el DataSet y DataReader de .Net y aún así no me mola demasiado la forma de trabajar. Me parece una chonada (marranada) increíble.
Lo de los campos en 2005, te hablaba del driver JDBC, que es lo que conozco. Me lo dijo Chuchi y no me lo creía, así que lo probé, vino una racha de viento y… plafff: Cómo retroceder 15 años en un momento.
Comment by Lek — September 1, 2006 @ 8:20 am
Pues no sé muy bien qué es lo que no te gusta porque básicamente te permiten trabajar de las dos formas posibles:
- Conectado, utilizando un DataReader, mantienes la conexión a la BD abierta y vas sacando los datos. Consumes menos recursos en el cliente pero mantienes una conexión permanentemente abierta, lo cual supone un problema en el lado del servidor. Es más rápido.
- Desconectado, utilizando el DataSet, lo llenas cno el DataAdapter que ya se encarga él mismo de conectarse y desconectarse bajo demanda. Consumes más recursos en el cliente pero menos en el servidor, pero a cambio es mucho más escalable.
Vamos, que básicamente puedes escoger lo que más te guste. No sé si en Java habrá una “tercera vía”. En cualquier caso, si el proveedor de conexión de .NET provee la posibilidad de acceder con un DataReader a campos aleatorios, podría ser que si el RecordSet no la provee es porque no lo han implementado así los de JDBC y no porque no se pueda con SQLServer 2005…
De todas formas, no se me ocurre en qué tipo de consulta deberías necesitar recuperar una cierta cantidad de información pero acceder únicamente a un determinado campo “conocido”. Es decir, que lo normal es que si tú haces una select, recorras la información recuperada sin saber nada de dicha información. No deberías saber que tu tupla elegida está en la posición x.
Comment by Administrator — September 1, 2006 @ 10:00 am
En eso de acceder a campos “conocidos” te equivocas. Tu seleccionas de una tabla de, por ejemplo, personal todos los datos (o todos los que te interesan). A la hora de mostrarlos o tratarlos una vez recuperados, accederas a las columnas no necesariamente en el mismo orden que las recupera la sentencia SQL. Eso es lo que no permite el JDBC. Si la columna 1 es “nombre” y la 2 “apellidos” no puedes acceder primero a “apellidos” (ni por nombre ni número) para luego acceder a “nombre”. Si quieres, te pongo un ejemplo donde se vea más claro, porque mi explicación es… tendente a cero
Respecto a la 3ª vía, JDBC es bastante pobre, a mi criterio. Permite muchas cosas, pero está muy limitado en otras: Un statement = un resultset. Y punto; si quieres más resultados, abre más statements (!!). Creo que fue la chonada del .NET que no me moló (sí, lo considero una chonada). Aunque igual lo cambiaron con .NET 2.0, porque te hablo de hace 3 años que tuvimos que usarlo…
Resumiendo, que si tienes que sacar datos de una tabla a partir de datos de una consulta anterior, necesitas tener 2 objetos diferentes por encima del propio ResultSet, porque si no, pierdes el ResultSet inicial. Para mí, es un desperdicio de recursos (consumirán más dos statements “pequeños” con un resultset cada uno que uno “grande” con 2 resultset diferentes, seguro).
Y había alguna otra cosa, porque tuvimos que dar más vueltas que un tonto al comienzo… pero ya ni me acuerdo…
Comment by Lek — September 1, 2006 @ 10:54 am
Perdón, te había entendido mal. Creía que te referías a acceder a “tuplas” dispares en lugar de campos dispares. Es decir, pensé que querías acceder a la tupla 5 sin pasar antes por la 1,2,3 y 4. Lo que dices de los campos me dejas aún más a cuadros, porque ya te digo que con el DataReader tienes la opción de:
a) Sacar un “chorro” de Objects con todos los campos de la tupla y ya te encargas tú de darles el formato (tipo de datos) que tengan.
b) Escoges un campo concreto y ya le haces que te lo formatee usando el método correcto. Por ejemplo, haciendo un getInt32 del campo X.
Vamos, que te permite acceder en el momento que quieras al campo que quieras de la tupla en la que está posicionado en ese momento el DataReader.
En .NET si no recuerdo mal, se puede reaprovechar el Statement (en este caso es un objeto Command) y “recargar” tu DataReader o tu DataAdapter con el nuevo comando SQL (o procedimiento almacenado). Por otra parte, puedes crear un objeto DataAdapter con 4 comandos: selección, inserción, actualización y borrado. Con esto, cuando llenes tu DataSet con los datos y posteriormente los alteres, podrás persistir los cambios en la BD de una sola vez, pues el sistema se encarga de escoger el comando adecuado para cada situación. ¡A que te mola!
Comment by Administrator — September 1, 2006 @ 11:16 am
Yo no quiero recargar, yo quiero tener 2 DataReaders distintos con el mismo Command… creo que sería la equivalencia más correcta, ¿no?
Lo del JDBC, será cosa del driver, una chapuza para despedir al vago los cojones que lo hizo, pero bueno…….
Comment by Lek — September 1, 2006 @ 2:47 pm
DFF DDDD
Comment by LEIDY — February 27, 2008 @ 2:57 am