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.

Preguntas similare

Leer las respuestas

#1 Alejandro Mesa
03/05/2006 - 14:07 | Informe spam
Rebeca,

Cual es el problema, por uqe crees que este diseño no es adecuado?

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

Si puedes, lee este magnifico articulo de nuestro colega Carlos Sacristán.

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


AMB

"Rebeca Arias" wrote:

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.



Respuesta Responder a este mensaje
#2 Rebeca Arias
03/05/2006 - 14:30 | Informe spam
Hola Alejandro, gracias por tu respuesta.

El problema es que nunca me hasta ahora siempre me había encontrado con
tablas en las cuales existe un campo Id de tipo int e incremental que
identificaba de forma única a cada registro, pero nunca con este tipo de
claves compuestas.

De todas formas si me dices que el diseño es correcto pues me pondré las
pilas y desarrollaré sobre esa BBDD.

Un saludo

Rebeca.

"Alejandro Mesa" escribió en el
mensaje news:
Rebeca,

Cual es el problema, por uqe crees que este diseño no es adecuado?

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

Si puedes, lee este magnifico articulo de nuestro colega Carlos Sacristán.

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


AMB

"Rebeca Arias" wrote:

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.



Respuesta Responder a este mensaje
#3 Alejandro Mesa
03/05/2006 - 15:10 | Informe spam
Rebeca,

Leete primero el articulo del link. La cuestion no es que este bien o mal,
eso yo no lo se, lo que no necesariamente la clave primaria tiene que ser un
ID numerico que se auto incremente. La clave natural seguira siendo la mas
importante en el diseño, pues esta participa en las etapas de diseño
conceptual y logico, mientras que el ID unico (si es que te refieres a una
clave subrrogada) solo participa en la etapa de implementacion fisica.


AMB


"Rebeca Arias" wrote:

Hola Alejandro, gracias por tu respuesta.

El problema es que nunca me hasta ahora siempre me había encontrado con
tablas en las cuales existe un campo Id de tipo int e incremental que
identificaba de forma única a cada registro, pero nunca con este tipo de
claves compuestas.

De todas formas si me dices que el diseño es correcto pues me pondré las
pilas y desarrollaré sobre esa BBDD.

Un saludo

Rebeca.

"Alejandro Mesa" escribió en el
mensaje news:
> Rebeca,
>
> Cual es el problema, por uqe crees que este diseño no es adecuado?
>
> Si quieres evitar referenciar esta tabla usando una clave compuesta,
> entonces pudieras usar una clave subrrogada (esa palabra no me suena
> bien).
>
> Si puedes, lee este magnifico articulo de nuestro colega Carlos Sacristán.
>
> ¿ Claves naturales o artificiales ?
> http://www.helpdna.net/colab01.htm
>
>
> AMB
>
> "Rebeca Arias" wrote:
>
>> 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.
>>
>>
>>



Respuesta Responder a este mensaje
#4 Miguel Egea
03/05/2006 - 20:58 | Informe spam
A mí 75 bytes de clave primaria, más aún si se deja como clustered como está
por defecto si me parece una garantía de problemas, sobre todo si tienes
muchas referencias externas y en este caso usaría una clave artificial o
subrogada, pero estoy más que de acuerdo con Alejandro, es cuestión del
diseño global y las claves naturales son muy importantes.

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

"Rebeca Arias" escribió en el mensaje
news:O7%
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.


Respuesta Responder a este mensaje
#5 Victor Koch
03/05/2006 - 22:43 | Informe spam
Hola Rebeca,

Yo no veo nada de malo en ese diseño, es mas yo tengo todas mis tablas de
esa forma en cuanto a definición de claves se trata.
Creo que la pregunta para convercerte seria:

¿ Tener una clave por un campo identity me evita tener otros índices
compuestos por varios campos. ?

Un saludo, Víctor Koch.


"Rebeca Arias" escribió en el mensaje
news:
Hola Alejandro, gracias por tu respuesta.

El problema es que nunca me hasta ahora siempre me había encontrado con
tablas en las cuales existe un campo Id de tipo int e incremental que
identificaba de forma única a cada registro, pero nunca con este tipo de
claves compuestas.

De todas formas si me dices que el diseño es correcto pues me pondré las
pilas y desarrollaré sobre esa BBDD.

Un saludo

Rebeca.

"Alejandro Mesa" escribió en el
mensaje news:
> Rebeca,
>
> Cual es el problema, por uqe crees que este diseño no es adecuado?
>
> Si quieres evitar referenciar esta tabla usando una clave compuesta,
> entonces pudieras usar una clave subrrogada (esa palabra no me suena
> bien).
>
> Si puedes, lee este magnifico articulo de nuestro colega Carlos


Sacristán.
>
> ¿ Claves naturales o artificiales ?
> http://www.helpdna.net/colab01.htm
>
>
> AMB
>
> "Rebeca Arias" wrote:
>
>> 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.
>>
>>
>>


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