¿tabla sin pk?

Hay varias cosas que no cierran. Usted dice que todos los 5 (o 6) campos
forman la PK, es decir que identifican a la fila... pero también dice que
algunos de esos campos admiten nulos.

Entonces no es cierto que esos campos forman una PK.

Qué es lo que modela usted en esa tabla? Puede explicarlo para no estar
hablando teóricamente?

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Sergio" wrote:

Hola:

Tengo algunas tablas que están formadas por 5 o 6 campos donde todos
ellos serían la PK. Hasta ahí ningún problema. Pero auque
conceptualmente todos esos campos forman la PK, algunos de ellos
pueden tener NULL, por lo que SQL Server no me deja que formen la PK.
Ahora mismo lo estoy solucionando con un índice único agrupado de los
5 o 6 campos y sin definir una PK en la tabla. Estaba pensando si este
índice es o no similar a una PK (por lo menos es único y agrupado) en
lo relativo a rendimiento,etc. Además no cabe duda de que es un poco
chocante ver una tabla sin PK. ¿Debería agregar una PK aunque fuera
con un autonumérico (aunque que no me gusta guardar nada que no sea
relevante)? ¿Cuá es vuestra opinión?
Gracias y un saludo.

Pues en vez de NULL metele espacios en blanco o cero segun sea el tipo de
los campos que segun tu deban ser Null.
Pero de que tienes que tenerle su PK claro que si. No es necesario el
autonumerico pero tampoco se puede descartar como opcion

"Sergio" escribió en el mensaje
news:
Hola:

Tengo algunas tablas que están formadas por 5 o 6 campos donde todos
ellos serían la PK. Hasta ahí ningún problema. Pero auque
conceptualmente todos esos campos forman la PK, algunos de ellos
pueden tener NULL, por lo que SQL Server no me deja que formen la PK.
Ahora mismo lo estoy solucionando con un índice único agrupado de los
5 o 6 campos y sin definir una PK en la tabla. Estaba pensando si este
índice es o no similar a una PK (por lo menos es único y agrupado) en
lo relativo a rendimiento,etc. Además no cabe duda de que es un poco
chocante ver una tabla sin PK. ¿Debería agregar una PK aunque fuera
con un autonumérico (aunque que no me gusta guardar nada que no sea
relevante)? ¿Cuá es vuestra opinión?
Gracias y un saludo.

Gracias por vuestras respuestas.

Primero el ejemplo de tabla:

CREATE TABLE [dbo].[MaxUnitsPerOrder](
[CompanyID] [nvarchar](10) NOT NULL,
[MarkID] [nvarchar](20) NOT NULL,
[FamilyID] [nvarchar](20) NULL,
[SubFamilyID] [nvarchar](20) NULL,
[Units] [int] NOT NULL,
CONSTRAINT [IX_MaxUnitsPerOrder] UNIQUE CLUSTERED
(
[CompanyID] ASC,
[MarkID] ASC,
[FamilyID] ASC,
[SubFamilyID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

En este ejemplo siempre habrá un valor en CompanyID y en MarkID, pero
a partir de ahí y en función de si encuentro nulos o no en FamilyID y
SubFamilyID me están indicando si las "máximas unidades por pedido" se
aplica sólo a la marca o también a la familia o también a la
subfamilia (por cierto la jerarquía marca, familia y subfamilia es
sencilla y creo se entiende).

Lo quiero guardar todo en una tabla porque no quiero hacer 3 tablas
(que sería otra solución) es decir, por ejemplo:

MaxUnitsPerOrderMark
MaxUnitsPerOrderFamily
MaxUnitsPerOrderSubFamily

aquí está claro que resolvería el problema pero estamos migrando la
aplicación y hemos pensado que es mejor una sola tabla.

Poner ceros o espacios lo había pensado, pero como son campos
alfanuméricos, imagina que una familia por ejemplo es un 0 (ya se que
es un surrealista, pero podría haber conflictos, aunque ciertamente
parece improbable...) y además personalmente leo mejor los nulos que
los valores "dummy", de hecho soy un anti-dummy ;-)

Yo creo que si tiene que tener PK, que en eso coincidimos todos ¿no?
le voy a meter un autonumérico ¿qué os parece?

Un saludo.

On 25 jun, 00:53, "Eduardo" wrote:

Pues en vez de NULL metele espacios en blanco o cero segun sea el tipo de
los campos que segun tu deban ser Null.
Pero de que tienes que tenerle su PK claro que si.  No es necesario el
autonumerico pero tampoco se puede descartar como opcion

"Sergio" escribió en el mensajenews:
Hola:

Tengo algunas tablas que están formadas por 5 o 6 campos donde todos
ellos serían la PK. Hasta ahí ningún problema. Pero auque
conceptualmente todos esos campos forman la PK, algunos de ellos
pueden tener NULL, por lo que SQL Server no me deja que formen la PK.
Ahora mismo lo estoy solucionando con un índice único agrupado de los
5 o 6 campos y sin definir una PK en la tabla. Estaba pensando si este
índice es o no similar a una PK (por lo menos es único y agrupado) en
lo relativo a rendimiento,etc. Además no cabe duda de que es un poco
chocante ver una tabla sin PK. ¿Debería agregar una PK aunque fuera
con un autonumérico (aunque que no me gusta guardar nada que no sea
relevante)? ¿Cuá es vuestra opinión?
Gracias y un saludo.

Por cierto, lo que lo modelo en la tabla es lo siguiente (quizás no ha
quedado claro en el anterior post):

Hay una jerarquía de productos que es marca, familia y subfamilia.
Un producto pertenece siempre a una subfamilia (de ahí luego se extrae
a que familia y marca pertenece).
En un pedido puede haber reglas de máximas unidades por pedido en
función de la jerarquía de productos.
Por ejemplo, que de la marca 5 no haya más de 10 unidades, pero además
de la familia RG de la marca 5 no puede haber más de 7 unidades, etc..
Con la anterior tabla, en una sola tabla guardo cualquier combinación
de restricción de unidades por pedido en función de la jerarquía y
además me sirve para validar X número de reglas, desde la más
restrictiva (más afinada y profunda en la jerarquía) hasta la menos
restrictiva pero que en cualquier caso ambas coinciden.
Por ejemplo.

CompanyID, MarkID, FamilyID, SubFamilyID, Units
520 , 5 ,NULL , NULL , 10
520 , 5 , RG , NULL , 7

El Wed, 25 Jun 2008 01:29:46 -0700 (PDT), Sergio escribió:

Lo quiero guardar todo en una tabla porque no quiero hacer 3 tablas
(que sería otra solución) es decir, por ejemplo:

MaxUnitsPerOrderMark
MaxUnitsPerOrderFamily
MaxUnitsPerOrderSubFamily

Pues es una solución mucho mejor.

Si quieres tener una tabla con todo pues te haces una vista después.


Saludos
Alfredo