Foreign Key de Vista

Hola Jesús,

On 5 feb, 23:35, Jesús wrote:

Espera un momento,

De momento no me muevo, pero cuando venga el sueño... :)

Con la alternativa 2, es decir con una sola tabla, puedes hacerlo todo sin
incluir el tipo en la clave primaria.

Permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
EsVenta bit NOT NULL DEFAULT 0,
EsProduccion bit NOT NULL DEFAULT 0,
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(EsProduccion = 0 OR ProduccionObjetivo IS NOT NULL),
CHECK(EsVenta = 0 OR PrecioVenta IS NOT NULL),
CHECK(EsVenta = 1 OR EsProduccion = 1)
)

No permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1,2)),
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(TipoArticulo <> 2 OR ProduccionObjetivo IS NOT NULL),
CHECK(TipoArticulo <> 1 OR PrecioVenta IS NOT NULL),
)

Muy creativo. Pero... ufff! Es que son muchos campos, de los que
hablaba Francisco, que no son comunes.
Yo realmente me quedaría con tres tablas. Y para este caso
controlaría que cada Articulo tiene que tener un ArticuloVenta
o un ArticuloProducción, pero no los dos (clave distribuida).

Saludos,
Carlos

Es que no sabemos que es lo que se está modelando. Que
es lo que dá lugar es este rollito. :-)

Quería decir: "Que es lo que dá lugar A este rollito."

Vamos, que me refiero al va y viene de interpretaciones
que estamos dando todos.

(Por si acaso... que sabe Dios como se habrá podido interpretar eso.)

Saludos,
Carlos

Pues yo me quedaría con una sola tabla, es más sencillo y eficiente. Es
verdad que habrá muchos nulos, pero los nulos ocpuan poco espacio, y ,
aunque son un engorro, después de tanto tiempo y de tanto de lidiar tanto
con ellos, hasta les he tomado cariño y me he hecho amigo de ellos :-)

Saludos:

Jesús López



"Carlos M. Calvelo" escribió en el mensaje de
noticias
news:
Hola Jesús,

On 5 feb, 23:35, Jesús wrote:

Espera un momento,

De momento no me muevo, pero cuando venga el sueño... :)

Con la alternativa 2, es decir con una sola tabla, puedes hacerlo todo sin
incluir el tipo en la clave primaria.

Permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
EsVenta bit NOT NULL DEFAULT 0,
EsProduccion bit NOT NULL DEFAULT 0,
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(EsProduccion = 0 OR ProduccionObjetivo IS NOT NULL),
CHECK(EsVenta = 0 OR PrecioVenta IS NOT NULL),
CHECK(EsVenta = 1 OR EsProduccion = 1)
)

No permitir que un artículo sea las dos cosas al mismo tiempo:

CREATE TABLE Articulos
(
CodArticulo int NOT NULL PRIMARY KEY,
TipoArticulo tinyint NOT NULL CHECK(TipoArticulo IN (1,2)),
NombreArticulo varchar(20) NOT NULL,
PrecioVenta decimal(9,2) NULL ,
ProduccionObjetivo int NULL ,
CHECK(TipoArticulo <> 2 OR ProduccionObjetivo IS NOT NULL),
CHECK(TipoArticulo <> 1 OR PrecioVenta IS NOT NULL),
)

Muy creativo. Pero... ufff! Es que son muchos campos, de los que
hablaba Francisco, que no son comunes.
Yo realmente me quedaría con tres tablas. Y para este caso
controlaría que cada Articulo tiene que tener un ArticuloVenta
o un ArticuloProducción, pero no los dos (clave distribuida).

Saludos,
Carlos

On 6 feb, 16:13, Jesús wrote:

Pues yo me quedaría con una sola tabla, es más sencillo y eficiente. Es
verdad que habrá muchos nulos, pero los nulos ocpuan poco espacio, y ,
aunque son un engorro, después de tanto tiempo y de tanto de lidiar tanto
con ellos, hasta les he tomado cariño y me he hecho amigo de ellos :-)

Ah! Tenemos un 'nulólogo' entre nosotros. Nadie es perfecto :)
Si... son muy cariñosos los nulos.

Aunque no estoy de acuerdo en general, en este caso me
refería específicamente a que los checks en tu ejemplo no
están aportando mucho a esa 'sencillez' y 'eficiencia'.

Saludos,
Carlos