XML vs. Cadenas con separadores.

Hola Jose:
Entre las dos alternativas que nos brindas, creo que es claro que la de
XML tiene ventaja.
Uno de mis super OT's la forma de tratar de convencerlos en mi criterio:
a) Darles la razon :) efectivamente en un formato XML facilmente el
espacio que se ocupara es de 2/3 veces mas grande que si lo usaras con un
separarador. Diles que sabes lo importante que es para la BD y para el
trafico de red el que se consuma hasta 3 veces mas espacio.
b) Luego que ellos estan claros que entiendes es problema desde su
perspectiva, es mas facil que te escuchen. Es muy importante primero tratar
de entender y luego tratar de ser entendido (Covey).
c) Luego empiezas con la evidencia, hice pruebas y resulta que hacer
30,000 consultas a la Tabla con separadores toma 1:20 y con XML 2:30, y el
espacio consumido sube 100 Kb a 300 Kb. (Claro que debes hacer las pruebas
previamente)
d) Luego haces una comparacion XML se parece mucho al HTML, no tanto por
la forma de los documentos sino por el impacto que tienen en Internet, antes
en Internet los documentos se grababan en Texto y mucha gente penso que como
HTML era tan grande (2 o 3 veces mas grande que el archivo de Texto) que
nadie usaria el HTML, y a pesar de esto HTML es el ahora sinonimo de
internet para muchos usarios, por supuesto se espera que los mismo ocurra
con XML y la aplicaciones, una aplicacion que no use XML esta en camino a la
obsolecencia.
e) Luego trata con franqueza de estimar las diferencias entre darle
mantenimiento a un formato XML y a un separado de comas, busca en tus
"memorias" los desastres que hayan ocurrido con el formato de separador y
usalos de ejemplo. Algo como para agregar una propiedad actualmente tenemos
que hacer y luego ... y mas adelante ... y si como en tal ocasion nos
pasa entonces tardamos , con XML este problema pudimos haberlo
resuelto en
f) Y asi sucesivamente, si finalmente no funciona es bueno tener
documentado el proceso y tu opinion de FORMA ESCRITA. Pero con frecuencia a
mi me resulta este tipo de razonamiento (Stephen R. Covey).
En cuanto a si hay forma de manejar este asunto, si si la hay, no estoy
seguro que sea la mejor opcion en tu caso, pero definitivamente es algo que
debes evaluar y es "NORMALIZAR" las propiedades, en algo mas o menos como:
TABLA Usuarios (NombreUsuario, ... )
TABLA Propiedades (NombrePropiedad, EsColleccion, ...)
TABLA PropiedadesUsuarios(NombreUsuario, NombrePropiedad,
ValorPropiedad)
TABLA ColleccionPropiedadesUsuarios)(NombreUsuario, NombrePropiedad,
Numero, ValorPropiedad)
Espero te sirva,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Jose escribio:
Mostrar la cita

Hola a todos.
Tengo una duda que quisiera compartir para ver si alguien me orienta:

Tengo una tabla de usuarios de mi aplicación en un servidor SQL y en
uno de sus campos quiero guardar las propiedades de estos en forma
encriptada. La idea inicial fue crear una cadena con separadores para
todas sus propiedades, encriptarla y guardar en el campo. Al levantar
el sistema busco ese campo desencripto, hago split en función a mis
separadores y comienzo a organizar mi ojeto usuario con las
propiedades que levante. Eso funciona muy bien pero es engorroso a la
hora de agregar algo nuevo ya que hay que hacerlo al final de la
cadena para que no perdamos las ya guardadas.

Luego se me complico todo cuando muchas de las propiedades del
usuario se fueron haciendo más complejas: colecciones,
jerarquías,etc... Obviamente se me complicó ya que debo usar
separadores distintos y claro está el procedimiento que levanta la
configuración se complico tambien.

Hice una prueba con XML, guardando las propiedades del objeto y es
fenomenal, facil de levantar y agregar nuevas propiedades. La idea
fue la misma en vez de guardar mi engorrosa cadena guardo una cadena
XML con la configuración del usuario. Todo muy bien hasta que me
pusieron una piedra de tranca mis superiores... Ellos afirman que el
XML hace que la cadena que antes con separadores era de un tamaño X
ahora es 2X o 3X más grande. obviamente la cadena ahora es más grande
(el doble o triple) que antes y eso no lo puedo refutar. Pero las
ventajas que he encontrado en trabajarlo así son grandes más no se
que puntualizarles para que acepten esta cadena XML. A parte hay
cosas que desconozco, como ¿que será más rápido levantarlo como se
hizo al principio o a través de XML?

¿Quisiera saber la opinión de ustedes? ¿Tienen ellos la razón?, ¿para
este tipo de información a guardar no vale la pena usar XML?
Si tengo la razón yo, que argumentos puedo tomar para convencer a mis
superiores. ¿hay otra forma de manejar el asunto?

De antemano gracias y disculpen lo largo.