Opiniones sobre diseño de tablas.

Es muy impresiso dar una respuesta acertada sobre la pregunta ya que existen
otras variables que desconocemos.
Suponiendo que Cod_xxx son codigos, un codigo convella a la identificacion
de un concepto.

Ej.

Maestro Expedientes
Cod_Expediente varchar(15)
Nombre_Expediente varchar(30)
Otros_campos ...

La tabla abajo descripta contiene muchos codigos, con lo cual se nutre de
otros maestros.
Esto esta bien por diseño.

En tal caso las tablas maestros son las que estan mal, ya que

Cod_Expediente int (4) ó bigint
1,2,3,4 (Incremental)
ID_Expediente varchar(15)
"ABX343" (numero interno de la empresa)
Nombre_Expediente
"Expediente Municipal de Obras y Desarrollo ABX-343"

De esta forma se logra una tabla principal agil a la hora de incrementarse
compuesta por diversos codigos que "UNEN" a los conceptos luego a evaluar.
Para normalizar el diseño, es necesario utilizar un PK (Primary Key)
Es decir, a la tabla ponle un ID bigint (incremental)
El campo Cod_Expediente seria un FK (Foreign Key)
Y el campo Cod_expediente de la tabla maestro seria un PK

Recuerda.

Maestro de expedientes Tabla principal
Cod_Expediente PK <|< Cod_Expediente FK
nombre ID
PK
...
Nombre
Direccion

Recuerda II: Es muy subjetivo dar una opinion certera en base a la exposion.
Espero que te sirva.

Saludos,

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.

On Wed, 3 May 2006 17:43:14 -0300, "Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> wrote:

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. ?

Esta es la cuestión. Las claves candidatas de la tabla no las debes de
eliminar. Si añades una nueva clave sustituta, la tabla siempre va a
ocupar más espacio por que añades un índice nuevo sin eliminar los que
ya existen.

Saludos
Alfredo

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

On Wed, 3 May 2006 06:10:02 -0700, Alejandro Mesa
wrote:

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.

Cualquier atributo visible por los programadores o el resto de los
usuarios es parte del diseño lógico.

Saludos
Alfredo

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

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, lo que es
muy muy eficiente, por su ordenación, por su tamaño, (fijate 60 bytes frente
a 4 a la hora de hacer un index scan es como 15 veces más eficaz) Por otra
parte en espacio de índices ahorarás de forma global, sobre todo si
necesitas varios índices..
Este es un ejemplo
create table foo ( a varchar(15) not null,b varchar(15) not null,

c varchar(15) not null,d varchar(15) not null,

fecha datetime default getdate(),

constraint pk_foo primary key (a,b,c,d) )

go

create table foo2 ( id int identity (1,1) primary key,a varchar(15) not
null,b varchar(15) not null,

c varchar(15) not null,d varchar(15) not null,

fecha datetime default getdate() )

go

create unique index ak_foo2 on foo2 (a,b,c,d)

go

declare @aux varchar(15)

set @aux='1233456789'

declare @i int

set @i00

while @i<10000

begin

insert into foo (a,b,c,d) values(@aux,@aux,@aux,cast(@i as varchar(10)))

insert into foo2 (a,b,c,d) values(@aux,@aux,@aux,cast(@i as varchar(10)))

set @i=@i+1

end

go

exec sp_spaceused 'foo'

exec sp_spaceused 'foo2'

go

tabla rows reserv data index unused

foo 10000 1160 KB 1104 KB 16 KB 40 KB

foo2 10000 1616 KB 648 KB 880 KB 88 KB

reserved-unused

foo 1120

foo2 1616

go

create index ix_aux1 on foo (fecha)

create index ix_aux1_2 on foo2 (fecha)

go

exec sp_spaceused 'foo'

exec sp_spaceused 'foo2'

go

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


go

create index ix_aux2 on foo (b,a)

create index ix_aux2_2 on foo2 (b,a)

go



"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 3 May 2006 17:43:14 -0300, "Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> wrote:

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. ?

Esta es la cuestión. Las claves candidatas de la tabla no las debes de
eliminar. Si añades una nueva clave sustituta, la tabla siempre va a
ocupar más espacio por que añades un índice nuevo sin eliminar los que
ya existen.

Saludos
Alfredo