SQL Server Performance Forum – Threads Archive

Uso de campo null

Buenas Luis Martin, este post es de un amigo, pero tambien estoy involucrado, trabaje con el en otra empresa y domino esos sistemas al derecho y al reves, espero me puedas ayudar a esclarecer muchas dudas con el uso de un campo que puede almacenar valor null. Saludos
Tengo una BD de Almacenes (Control de Ingresos y Salidas de todos los
Motivos ; Produccion, x Compra, x Servicio) todo lo manejo mediante 2
tablas (cabecera y detalle), se almacena un promedio de 50000 registros
mensuales,existen 22 campos en la tabla cabecera y 30 en la tabla de
detalle,
y x Cada transaccion existiran 4 campos nulos en la tabla cabecera y 3 en la
tabla detalle aproximadamente ya que no todas las transacciones tienen los
mismos datos.
Ahora existe un nuevo analista que quiere dividir la tabla de movimientos
en 3 entidades una de ingresos x guia
otra de ingresos a planta y otra de movi x servicios,
dice q eso para q no exista muchos nulo x tabla q no es optimo pero a mi me
parece q seria lo contrario
la verdad quisiera saber si alguien pudiera darme algunas sugerencias de
esto Mi otra inquietud es que tengo hecho unos maestros de codigos, de tela, hilos, avios, etc, pero cada uno tiene una tabla, todos serian articulos, pero se genero campos como largo, peso, ancho, color, etc etc, todos con codigos, o sea, la descripcion es concatenada asi como el codigo que llega a ser en avios hasta 64 caracteres, pero como pk no lo tengo, sino un campo de 7 caracteres ahora quiero juntar todos en una tabla articulos, para eso aumento un campo que diga que tipo de articulo es, pero eso lleva a que junte los campos comunes y no comunes de estos maestros, y este codigo aumentaria drasticamente a 98 caracteres, algo de 24 campos de propiedades, que tan aconsejable seria, ya que si codifico un papel, tendria articulo ’02’, material plastico(254), y los demas campos como huecos, peso, precio con valor null, que tanto tengo que hacer una optimizacion, si gustas, me comentas para enviarte los scripts de todas las tablas, ahora en la noche lo hago en mi casa y te los envio. Muchas gracias

Al parecer las dos tablas no estÃ¡n normalizadas y, tambiÃ©n al parecer, la apertura en tablas de acuerdo al concepto del ingreso tenderÃa a normalizar esas tablas. Si fuera asÃ, es correcto el pensamiento del nuevo analista. Ahora, en ambos casos el tema de los nulos no hace a la optimizaciÃ³n, si a esto llamamos performance.
Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided â€œAS ISâ€ with no warranties for accuracy.

Ahora yo digo que si se trata de darle fascilidad al sistema tanto en su desarrollo como en su mantenimiento posterior, no seria mas complejo, y es mas, si las dos tablas que tengo, cabecera y detalle de movimiento, al quebrarlas de acuerdo al esquema del nuevo analista, se que reduciria en algo la existencia de nulos pero no serian las consultas mas complejas o si en caso yo quiero buscar un movimiento, tendria que hacer la busqueda en tantas tablas haya generado, para las impresiones de kardex, donde se observa los movimientos generales, tendria que hacer un select union y order by a la data, que tanto es mi problema como para evitar esos campos nulos. Las tablas han sido normalizadas hasta la 3era forma, bueno actualmente el sistema esta bajo un desarrollo muy bajo nivel de profesionalismo por decirlo ya que casi todos los stors fueron hechos con sql dinamico, al fusionar las tablas de cada almacen, obtendremos unas mega tablas, faciles para hacer selects y otras cosas pero cuando haga un reordenamiento de base de datos, seria una catastrofe, comento pues ahora estoy en una compaÃ±ia de seguros y aqui no nos preocupamos porque el script demore o no, esta optimizado al maximo como he podido revisar y cuentan con un servidor que si en desarrollo el scrip demora 20 seg. en el servidor es 3 seg., pero en el otro negocio se trata de un servidor compatible P IV de 1G ram, disco IDE, y estan evaluando juntar las tablas, eso me pedira mas servidor, y mas si el nuevo analista propone rehacer los sistemas pero en .net, y no estan considerando que la empresa no es casa de software, que tendra que comprar las licencias, horas hombre para el desarrollo, etc etc, por ahora solo tienen autorizacion para vb6 y sql2000, y mas si no van a negociar el sistema una vez terminado, por eso mi inquietud, quieren migrar a .net, y fusionar tablas, ya que son 4 almacenes, todo en 2 tablas y luego estas 2 separarlas con el fin de no tener muchos null.

Amigo fjac_pe Buenos Dias. Por mi parte te diria que te olvides del tema de los nulls. Lo que primero hay que saber es que es lo que quieren lograr.
1) Que sea mas performante la BD (mas rapida en las consultas o en los inserts-update-delete)
2) Mejorar su extructura, ver de normalizarla (en el caso que no lo estuviera) para luego realizar un analisis de tunning
3) Tienen errores y por eso quieren modificarla. Bueno perdona todas mis preguntas pero primero antes de dar ninguna opinion quisiera saber a donde queres llegar. Luego vemos que se puede hacer! Abrazo The Pipo The Pipo Dba.

Lo que tengo es contamos con un codigo de producto muy amplio de 64 caracteres y otro campo equivalente de 8 digitos, y el primero es el que usamos para relacionar, muy mal hecho, usaremos el de 8 para relacionar, segundo, el tener muchos maestros nos lleva a usar sql dinamico para agilizar la programacion ya que no tenemos que hacer selects ni nada, basta con indicar las nuevas tablas en un maestro de configuracoin y listo, asi como generar las tablas de los nuevos almacenes y ya, bueno queremos fusionar las tablas de almacenes y maestros, pero al hacerlo sobre los maestros, tendria muchos null debido a que es una codificacion estructurada, no se trata de un campo codigo y descripcion, sino un juego de varios campos cuya combinacion de codigos da un codigo y la concatenacion de las descripciones de estos campos el nombre de nuestro articulo, ahora el proceso de valorizacion de almacenes actualiza estas tabla, si el almacen mas grande demora 15 min en una buena maquina, y el mas chiquito demora 1 min, al juntarlos, todos se pondran mas lentos, y la valorizacion incluso es muy compleja, se trata de traslado de costos y precios de un almacen a otros, digamos que el hilado sale y se convierte en tela cruda, luego la tela cruda se tiÃ±e y genera tela acabada, todo se anexa por orden de produccion para realizar su respectiva valorizacion, y como dice el analista nuevo, si separa las tablas creo que este proceso demoraria mas. Lo peor que hicimos fue valernos del sql dinamico para realizar nuestras consultos y los procesos de reordenamiento de kardex, ahora si los uno en dos tabla, solo se trata de manejar una variable de tipo de almacen y no una para el nombre de tabla que fue el origen de todo esto, pues un script con sql dinamico hace lento el rendimiento, pero tambien hay otro almacen llamado prendas, donde se trata de un codigo de articulo, codigo de color y talla, este cambia el modo de operar la informacion, ya que si manejo un registro por cada uno, tendria: detalle
ot1 codigoarti1 rojo s 10
ot1 codigoarti1 rojo m 20
ot1 codigoarti1 rojo l 20
ot1 codigoarti1 celeste s 30
ot1 codigoarti1 celeste l 10 y para evitar esto, mejor doy una tabla mas que tenga detalle
ot1 codigoarti1 rojo Item1
ot1 codigoarti1 rojo Item2 sub-detalle
ot1 Item1 s 10
ot1 Item1 m 20
ot1 Item1 l 20
ot1 Item2 s 30
ot1 Item2 l 10 y evito duplicar mucha informacion, por eso este almacen preferiria manejarlo separado. Errores tenemos si pero yo creo que mas se trata de servidor que soporte, porque el proceso de reordenamiento de almacen, no sabemos en que momento un articulo no actualiza correctamente y cuando procesamos nuevamente todo, funciona correctamente. Espero haberme explicado.

"no sabemos en que momento un articulo no actualiza correctamente"
Esta es la falla que queres solucionar? Bueno para mi por el tipo de falla pasaria por la programacion, mas haya de como tenes la BD. Luego para mejorar los tiempos de incercion deberiamos ver el tema de indices. Por desgracia mucha ayuda en la programacion no te puedo dar ya que no me especializo en eso. Estoy trabajando en performance de BD. Bueno diariamente miro el foro y si te puedo ayudar lo hare. Igualmente tambien tenemos a LuisMartin que la tiene mucho mas clara que yo. Abrazo
The Pipo Dba.

Es un tema muy complicado, cuando hicimos el proceso de reordenamiento, lo hacemos generando un cursor que almacena informacion de los items a procesar, tanto si se trata de un articulo como todo el almacen, el uso diario de la aplicacion es donde se presenta este problema, que el usuario informa que un stock esta mal, pero si manda a reprocesar todo el almacen que de hecho es algo muy pesado, lo llega a realizar, lento pero seguro, y cuando el usuario da salida a algun elemento del almacen, se desencadena el mismo script pero para tanto items esten en pantalla y tambien funciona correctamente, el decir que no sabemos, debe ser problema de bloqueos, quiza un usuario le da salida y otro tambien pero lo extraÃ±o es que entre los proceso de guardar la informacion, abro una transaccion por lo cual el otro usuario no puede grabar nada hasta que el otro usuario no termine, por ahora estamos haciendo seguimiento en el analizados de sql para ver por ahi alguna anomalia durante el dia laboral, pero por ahora nada, todo sale bien. Respecto a los indices, no puedo crear muchos, porque al hacer la insercion, que es lo mas usado, se prolonga mucho el tiempo de respuesta, la ayuda que me estan dando, me vale mucho, el problema principal para mi es ver que tan rentable o bueno seria fusionar las tablas, y modificar el sistema, quizas ese error de stock desaparezca o aumente, no se realmente lo que pueda pasar, por mi parte estare modificando las tablas y vere como cargarle la informacion, que no es mucha solo es 1.5 gigas en data de movimientos.

Para detectar el error, probastes usando el profile y analizar la sentencia que dio el error? El profile te tomaria todo lo ejecutado contra la base, por lo que si la falla esta en el codifo la vas a poder encontrar. El profile ejecutalo desde otra PC (no del servidor) para evitar que te quedes sin espacio, ya que el mismo crece bastante. Mi concejo es que lo dejes todo el dia corriendo, y si pasa el error analises en esa franja de tiempo haber que se ejecuto. (( Consejo, los cursores atentan contra la performance del motor, no te aconsejo usarlos. Estas sacando la virtud de SQL de tomar todo y ejecutarlo contra un proceso que se ejecuta lineal )) Saludos desde Argentina
The Pipo Dba.

Es buena idea la de Pipo. Tienes que configurar adecuadamente el profiler para encontrar el error.
Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided â€œAS ISâ€ with no warranties for accuracy.

Ok, y como configuro el profiler adecuadamente, si lo he usado pero dandole siguiente a todo, y un amigo me refirio filtrar la informacion que quiero hacer seguimiento, e incluso indicar a que tablas se les puede hacer seguimiento, para evitar el registro de todos los eventos innecesarios para mi verificacion. Nuevamente muchas gracias, veo que me falta un mundo por conocer y ya estoy pensando en aprender sql 2005

Una manera fÃ¡cil es filtrar por el un usuario que utilize el query para tener solamente quÃ© se ejecuta.
Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided â€œAS ISâ€ with no warranties for accuracy.

]]>