Últimos mensajes - Powered by IBM

Palabras claves

Opiniones sobre diseño de tablas.

03/05/2006 - 12:29 por Rebeca Arias | Informe spam

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.

Siga el debate

21 respuestas

Tengo una respuesta

Preguntas similare

Duda sobre sobre diseño de tablas.

Leer las respuestas

#11 Alfredo Novoa

05/05/2006 - 10:56 | Informe spam

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

Responder a este mensaje

#12 Miguel Egea

05/05/2006 - 11:26 | Informe spam

:) 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

Responder a este mensaje

#13 Carlos Sacristán

05/05/2006 - 11:51 | Informe spam

El artículo es (como dice al principio del mismo) un resumen de un hilo
de este mismo grupo en el que opinaron un montón de personas, todas ellas
grandes profesionales (por lo tanto el mérito no es mío). 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.

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. Y esto último no lo digo con ningún tipo de
mala intención.

Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 3 May 2006 05:07:01 -0700, Alejandro Mesa
wrote:

>Si quieres evitar referenciar esta tabla usando una clave compuesta,
>entonces pudieras usar una clave subrrogada (esa palabra no me suena

bien).

Clave sustituta o clave sustitutiva suenan mejor.

>Si puedes, lee este magnifico articulo de nuestro colega Carlos

Sacristán.

>
>¿ Claves naturales o artificiales ?
>http://www.helpdna.net/colab01.htm

A mi no me parece bueno. Cualquiera que crea que Celko es un gran
profesional es que no tiene ni idea :-)

Saludos
Alfredo

Responder a este mensaje

#14 Rebeca Arias

05/05/2006 - 12:03 | Informe spam

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

Responder a este mensaje

#15 Miguel Egea

05/05/2006 - 12:14 | Informe spam

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

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5

Busqueda sugerida