Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

Opiniones sobre diseño de tablas.

03/05/2006 - 12:29 por Rebeca Arias | Informe spam
Ayuda Hacer una pregunta
Hola a todos de nuevo,



Resulta que en mi empresa tenemos querealizar un desarrollo atacando a una
BBDD en SQL 2000 de la que ya está tirando otra aplicación.

El caso es que me han pasado el modelo de datos de la BBDD y personalmente
creo que el diseño no es el más adecuado y que desarrollar sobre esa BBDD
podría traernos futros problemas, principalmente creo que problemas de
rendimento en cuanto tenga un nº considerable de registros (hay que tener en
cuenta que ya hay una aplicación tirando de esa BBDD), además de que nos
complicaría mucho codificar sobre ese modelo.



Yo creo que el principal fallo de está en todo el tema de las claves e
indices y el tipo de los campos, pero ojo, es una opinión personal que a lo
mejor está equivocada.

Esta es la estructura de una de las tablas , aunque todas tienen el mismo
diseño.

Os agradecería vuestra opinión en cuanto al diseño y si considerais que nos
es correcto el porqué.



TABLA



Cod_Expediente VARCHAR(15) No admite nulos

Cod_Obra VARCHAR(15) No admite nulos

Cod_Servidor VARCHAR(15) No admite nulos

Cod_Orden VARCHAR(15) No admite nulos

Cod_Orden_Nuevo VARCHAR(15) No admite nulos

Nombre VARCHAR(50) Si admite nulos

Direccion VARCHAR(100) Si admite nulos



INDICES

COLUMNAS



Clave Cod_Expediente

Cod_Obra

Cod_Servidor

Cod_Orden

Cod_Orden_Nuevo



Os agrdezco cualquier opinion al respecto.



Un saludo,



Rebeca.
email Siga el debateRespuesta 21 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#16 Rebeca Arias
05/05/2006 - 12:17 | Informe spam
Y por cierto, estoy viendo tablas en las que la clave primaria tiene hasta 8
campos VARCHAR(15).

Un saludo

Rebeca

"Rebeca Arias" escribió en el mensaje
news:
Hola a todos de nuevo,

Bueno, la verdad es que no pensaba que el hilo iba a crear esta polémica.

Bajo mi cortisima experiencia y escasos conocimientos esa es la impresion
que me ha dado el diseño, la impresión que comenta Miguel Egea, que si 4
o5 campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los orígenes
de los futuros problemas de rendimiento, y esos problemas son los que
quiero evitar.

Gracias por todos vuestros comentarios.

Un saludo

Rebeca.



"Miguel Egea" escribió en el mensaje
news:
:) Bueno No defenderé yo a Celko, yo tampoco estoy de acuerdo con él en
muchas cosas, de hecho sí que uso claves subrogadas cuando las considero
necesarias :).

En cualquier caso, y hablando de diseño de base de datos lo que creo que
estamos todos de acuerdo es que si 4 o5 campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los orígenes
de los futuros problemas de rendimiento.

Gracias por tus comentarios, enriquecen el conocimiento del grupo.

Saludos

Miguel Egea Gómez

SQLServer MVP

Director de Servicios Corporativos

Solid Quality Learning Iberoamericana



"Solid Quality Learning es el proveedor global en el que puede confiar
para obtener soluciones y educación avanzada para la plataforma completa
de sistemas de bases de datos de Microsoft."

www.SolidQualityLearning.com


"Alfredo Novoa" escribió en el mensaje
news:

Hola Miguel,

On Thu, 4 May 2006 20:50:50 +0200, in microsoft.public.es.sqlserver
you wrote:

Hola Alfredo, Yo aunque no comulgue con Celko en todo lo que dice si
creo
que es un gran profesional, al menos su fama mundial así lo dice :)



Más que fama es infamia. Celko tiene una malísima reputación entre los
expertos en bases de datos. Muchos recomiendan ignorarle
completamente.

En cualquier caso lo que dices es cierto solo a medias, Si el campo
identity
lo usas como primary key, y pones un unique key sobre tu clave compuesta
absolutamente todos tus joins podrías hacerlos por ese identity,



Todos no, solo los que dependan de la clave a la que sustituye el
"identity". En el ejemplo de Rebeca no creo que pueda construirse
ninguna consulta útil haciendo un join sobre todos los campos.

tabla rows reserv data index unused

foo 10000 1808 KB 1104 KB 608 KB 96 KB

foo2 10000 1880 KB 648 KB 1080 KB 152 KB




Contra esto no se puede decir nada aparte de quejarnos por lo poco
eficientes que son los índices en SQL Server.

Si no queremos tener el campo "identity" en nuestro modelo lógico, una
solución podría ser crear una tabla con el campo identity que sea solo
visible para el DBA y crear una vista actualizable que no incluya ese
campo.


Saludos
Alfredo








Respuesta Responder a este mensaje
#17 Alfredo Novoa
05/05/2006 - 12:17 | Informe spam
Hola Rebeca,

On Fri, 5 May 2006 12:03:38 +0200, "Rebeca Arias"
wrote:

Hola a todos de nuevo,

Bueno, la verdad es que no pensaba que el hilo iba a crear esta polémica.

Bajo mi cortisima experiencia y escasos conocimientos esa es la impresion
que me ha dado el diseño, la impresión que comenta Miguel Egea, que si 4 o5
campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los orígenes
de los futuros problemas de rendimiento, y esos problemas son los que
quiero evitar.



Hay muchos más posibles problemas (y más importantes) además de los
problemas de rendimiento. Lo que pasa es que nos haría falta muchísima
más información para poder dar opiniones más detalladas.


Saludos
Alfredo
Respuesta Responder a este mensaje
#18 Alfredo Novoa
05/05/2006 - 12:22 | Informe spam
On Fri, 5 May 2006 11:51:45 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Citar a Celko es
sólo una parte del mismo, y si te lo has leído verás que lo que se intenta
es exponer las ventajas e inconvenientes de las dos opiniones.



Ya, a lo que yo me refería es a que como dicen los americanos estabas
luchando contra un hombre de paja.

Por mi parte no tengo ningún inconveniente en que amplíes el contenido
del artículo para hacerlo más rico e interesante para todos nosotros,
siempre y cuando tus conocimientos en el tema sean lo suficientemente
amplios como para conseguirlo.



Conozco bastante bien la teoría, aunque bastante poco sobre SQL
Server, siempre he usado otros sistemas.

Cuando tenga un rato le echaré otro vistazo con más calma al artículo.


Saludos
Alfredo
Respuesta Responder a este mensaje
#19 Rebeca Arias
05/05/2006 - 12:27 | Informe spam
Perdona Miguel porque no me expliqué bien.
Sí que te he entendido bien.

Gracias.

Un saludo

Rebeca.

"Miguel Egea" escribió en el mensaje
news:
Pero no me entiendas mal, que he simplificado mucho, el tema es que esas
deberán seguir siendo claves únicas, lo dice el negocio, pero en mi
opinión yo crearía una clave alternativa para acceder a la información.

Saludos
Miguel Egea
"Rebeca Arias" escribió en el mensaje
news:
Hola a todos de nuevo,

Bueno, la verdad es que no pensaba que el hilo iba a crear esta polémica.

Bajo mi cortisima experiencia y escasos conocimientos esa es la impresion
que me ha dado el diseño, la impresión que comenta Miguel Egea, que si 4
o5 campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los orígenes
de los futuros problemas de rendimiento, y esos problemas son los que
quiero evitar.

Gracias por todos vuestros comentarios.

Un saludo

Rebeca.



"Miguel Egea" escribió en el mensaje
news:
:) Bueno No defenderé yo a Celko, yo tampoco estoy de acuerdo con él en
muchas cosas, de hecho sí que uso claves subrogadas cuando las considero
necesarias :).

En cualquier caso, y hablando de diseño de base de datos lo que creo que
estamos todos de acuerdo es que si 4 o5 campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los
orígenes de los futuros problemas de rendimiento.

Gracias por tus comentarios, enriquecen el conocimiento del grupo.

Saludos

Miguel Egea Gómez

SQLServer MVP

Director de Servicios Corporativos

Solid Quality Learning Iberoamericana



"Solid Quality Learning es el proveedor global en el que puede confiar
para obtener soluciones y educación avanzada para la plataforma completa
de sistemas de bases de datos de Microsoft."

www.SolidQualityLearning.com


"Alfredo Novoa" escribió en el mensaje
news:

Hola Miguel,

On Thu, 4 May 2006 20:50:50 +0200, in microsoft.public.es.sqlserver
you wrote:

Hola Alfredo, Yo aunque no comulgue con Celko en todo lo que dice si
creo
que es un gran profesional, al menos su fama mundial así lo dice :)



Más que fama es infamia. Celko tiene una malísima reputación entre los
expertos en bases de datos. Muchos recomiendan ignorarle
completamente.

En cualquier caso lo que dices es cierto solo a medias, Si el campo
identity
lo usas como primary key, y pones un unique key sobre tu clave
compuesta
absolutamente todos tus joins podrías hacerlos por ese identity,



Todos no, solo los que dependan de la clave a la que sustituye el
"identity". En el ejemplo de Rebeca no creo que pueda construirse
ninguna consulta útil haciendo un join sobre todos los campos.

tabla rows reserv data index unused

foo 10000 1808 KB 1104 KB 608 KB 96 KB

foo2 10000 1880 KB 648 KB 1080 KB 152 KB




Contra esto no se puede decir nada aparte de quejarnos por lo poco
eficientes que son los índices en SQL Server.

Si no queremos tener el campo "identity" en nuestro modelo lógico, una
solución podría ser crear una tabla con el campo identity que sea solo
visible para el DBA y crear una vista actualizable que no incluya ese
campo.


Saludos
Alfredo












Respuesta Responder a este mensaje
#20 Rebeca Arias
05/05/2006 - 12:32 | Informe spam
Hola Alfredo,

Perdona que te moleste tanto, pero así un poco por encima me podrías decir
que más problemas podría ocasionar el utilizar este diseño?, teniendo además
en cuenta que hay hasta 8 campos clave VARCHAR(15).

Gracias de nuevo.

Un saludo,

Rebeca.

"Alfredo Novoa" escribió en el mensaje
news:

Hola Rebeca,

On Fri, 5 May 2006 12:03:38 +0200, "Rebeca Arias"
wrote:

Hola a todos de nuevo,

Bueno, la verdad es que no pensaba que el hilo iba a crear esta polémica.

Bajo mi cortisima experiencia y escasos conocimientos esa es la impresion
que me ha dado el diseño, la impresión que comenta Miguel Egea, que si 4
o5
campos varchar(15) son la clave
primaria es que hay algo que no está bien y podrá ser uno de los orígenes
de los futuros problemas de rendimiento, y esos problemas son los que
quiero evitar.



Hay muchos más posibles problemas (y más importantes) además de los
problemas de rendimiento. Lo que pasa es que nos haría falta muchísima
más información para poder dar opiniones más detalladas.


Saludos
Alfredo

Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida