Tabla para tablas ID-Descripcion

No me parece en absoluto buena idea. Por un lado, no entiendo el ahorro que
puedas tener. ¿Tener menos tablas en tu base de datos? ¿Estamos hablando de
cientos de tablas menos? Creo que no...

Y aún en el caso de que te ahorraras no cientos, sino miles de tablas. ¿Cómo
mantienes la integridad de los datos? ¿Cómo aseguras que estás introduciendo
un valor correcto en las tablas? ¿Por aplicación? ¿Y si cambia la
aplicación, o hay un error en la lógica de la misma?

Penta, para eso existe la base de datos: si está bien diseñada, entre otras
cosas te valida la integridad referencial de forma nativa (por decirlo de
algún modo), sea cual sea la aplicación cliente.

Un saludo
-
www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

"Penta" escribió en el mensaje
news:
Estimados.
Utilizo SS2000
Estamos pensando en crear una tabla que contenga todas las tablas con
ID y Descripcion

Tabla_Maestra
Nombre_Tabla varchar(50)
Descripción_Tabla varchar(100)
ID Int
Descripción Varchar(50)

Quedaría algo asi:

Nombre_Tabla Descripción_Tabla ID Descripción
Ciudad Tabla de Ciudades 1 Santiago
Ciudad Tabla de Ciudades 2 Buenos Aires
Pais Tabla de Paises 1 Chile
Pais Tabla de Paises 2 Argentina



Las querys:

Select * from tabla_datos A Inner Join Tabla_Maestra B
On a.id=b.id and b.Nombre_Tabla='Ciudad'

O bien que en tabla Maestra el Id sea unico y no filttar por
b.Nombre_Tabla='Ciudad'

Espero sus opiniones y en caso que esto NO sea efectivo o los contra
seria estupendo sus comentarios.

Que me ahorro ? muchos mantenedores :)

PENTA.

On 29 mayo, 02:28, "Carlos Sacristan" wrote:

No me parece en absoluto buena idea. Por un lado, no entiendo el ahorro que
puedas tener. ¿Tener menos tablas en tu base de datos? ¿Estamos hablando de
cientos de tablas menos? Creo que no...

Y aún en el caso de que te ahorraras no cientos, sino miles de tablas. ¿Cómo
mantienes la integridad de los datos? ¿Cómo aseguras que estás introduciendo
un valor correcto en las tablas? ¿Por aplicación? ¿Y si cambia la
aplicación, o hay un error en la lógica de la misma?

Penta, para eso existe la base de datos: si está bien diseñada, entre otras
cosas te valida la integridad referencial de forma nativa (por decirlo de
algún modo), sea cual sea la aplicación cliente.

Muchas Gracias Carlos.
Hay veces que se me escapan cosas tan elementales por mirar algo
diferente.

PENTA.

A mí no me parece tan mala idea, en mi trabajo usamos algo parecido, una
tabla con clave, código alfanumérico, código Numérico, descripción. Este
tipo de tablas viene muy bien cuando se quiere que un campo acepte sólo
unos valores predeterminados.

Una utilidad para que también la hemos utilizado es: para después
traducir valores a distintos idiomas, pues lo que guardamos en la tabla
es el código alfanumérico o el numérico, sin poner la descripción. Por
lo que teniendo la clave y su código alfanumérico o numérico se tiene
una clave que luego los programas que manejan la base de datos, pueden
traducir a distintos idiomas, para mostrar información a los usuarios
finales.

No es lo mismo tener cientos de tablas código descripción que una que
las agrupe todas, en nuestra B.D., tendríamos que tener unas 152 tablas
con unas 2421 descripciones, en las que la mayoría no pasarían de los 10
registros, y a medida que va creciendo la base de datos ésta tabla
código descripción sigue creciendo.

Para asegurar que metes un valor correcto a parte de la integridad
referencial, existen los disparadores de inserción y actualización.

Esto es una cosa como la eterna discusión de usar nulos o no usarlos.

Es una decisión del proyecto la base de datos que usa y su entorno.

Salu2 Rafael Cano
desarrollo(arroba)rafacano.es
Jaén - España
Villamartín - Cádiz - España

El 29/05/2009 08:28, Carlos Sacristan escribió:

No me parece en absoluto buena idea. Por un lado, no entiendo el ahorro que
puedas tener. ¿Tener menos tablas en tu base de datos? ¿Estamos hablando de
cientos de tablas menos? Creo que no...

Y aún en el caso de que te ahorraras no cientos, sino miles de tablas. ¿Cómo
mantienes la integridad de los datos? ¿Cómo aseguras que estás introduciendo
un valor correcto en las tablas? ¿Por aplicación? ¿Y si cambia la
aplicación, o hay un error en la lógica de la misma?

Penta, para eso existe la base de datos: si está bien diseñada, entre otras
cosas te valida la integridad referencial de forma nativa (por decirlo de
algún modo), sea cual sea la aplicación cliente.

No entiendo muy bien tu primer ejemplo.

En cuanto a lo demás, el mal diseño (desde mi punto de vista) es que la
tabla tenga un ID y luego una descripción de todos los objetos que tengas
que almacenar (que es lo que decía Penta). Si el resto de las tablas apuntan
a ese ID (por medio de una FK), si por ejemplo quieres hacer referencia a un
nombre de país, ¿cómo validas que estás haciendo referencia efectivamente a
un país? ¿por el intervalo del número referenciado? ¿por que es negativo?
¿por que es superior a un valor dado?

Otra cosa es que la tabla "descripciones" sea algo similar a:

ID
Tipo
Idioma (opcional)
Descripción

Donde la PK de la tabla es ID+Tipo. Ahí sí que es posible tener una tabla
única de descripciones y que las tablas hagan referencia al registro
correcto no sólo desde el punto de vista de integridad referencial, sino
también, por decirlo de algún modo, desde el punto de vista lógico. Es
decir, podríamos tener que el código 1-P hace referencia al país "España", y
en la tabla de clientes, tener una FK en el campo "pais" a la tabla de
descripciones con un CHECK que valide que sólo se admiten registros del tipo
"P" (de países).

Para validar integridad referencial dejaría los triggers para validaciones
más complejas, pero éste creo que no es el caso.

Un saludo
-
www.navento.com
Servicios de Localización GPS

http://blogs.solidq.com/ES/ElRincon...fault.aspx

"Rafael Cano" escribió en el mensaje
news:

A mí no me parece tan mala idea, en mi trabajo usamos algo parecido, una
tabla con clave, código alfanumérico, código Numérico, descripción. Este
tipo de tablas viene muy bien cuando se quiere que un campo acepte sólo
unos valores predeterminados.

Una utilidad para que también la hemos utilizado es: para después traducir
valores a distintos idiomas, pues lo que guardamos en la tabla es el
código alfanumérico o el numérico, sin poner la descripción. Por lo que
teniendo la clave y su código alfanumérico o numérico se tiene una clave
que luego los programas que manejan la base de datos, pueden traducir a
distintos idiomas, para mostrar información a los usuarios finales.

No es lo mismo tener cientos de tablas código descripción que una que las
agrupe todas, en nuestra B.D., tendríamos que tener unas 152 tablas con
unas 2421 descripciones, en las que la mayoría no pasarían de los 10
registros, y a medida que va creciendo la base de datos ésta tabla código
descripción sigue creciendo.

Para asegurar que metes un valor correcto a parte de la integridad
referencial, existen los disparadores de inserción y actualización.

Esto es una cosa como la eterna discusión de usar nulos o no usarlos.

Es una decisión del proyecto la base de datos que usa y su entorno.

Salu2 Rafael Cano
desarrollo(arroba)rafacano.es
Jaén - España
Villamartín - Cádiz - España

El 29/05/2009 08:28, Carlos Sacristan escribió:

No me parece en absoluto buena idea. Por un lado, no entiendo el ahorro
que
puedas tener. ¿Tener menos tablas en tu base de datos? ¿Estamos hablando
de
cientos de tablas menos? Creo que no...

Y aún en el caso de que te ahorraras no cientos, sino miles de tablas.
¿Cómo
mantienes la integridad de los datos? ¿Cómo aseguras que estás
introduciendo
un valor correcto en las tablas? ¿Por aplicación? ¿Y si cambia la
aplicación, o hay un error en la lógica de la misma?

Penta, para eso existe la base de datos: si está bien diseñada, entre
otras
cosas te valida la integridad referencial de forma nativa (por decirlo de
algún modo), sea cual sea la aplicación cliente.

Carlos, perdón tienes razón, se me fué la pinza, no entendí lo que
escribió Penta.

Yo me refería a una tabla tipo diccionario como esta:

Tabla de clave descripción.

Clave RespuCod Orden Descrip
CANALTIPO CLIENTE 2 Cliente
CANALTIPO PRESCRIPTO 1 Prescriptor
CANALTIPO AGECOLABOR 3 Agente colaborador
TIPOALBARA NORMAL 1 Albarán normal
TIPOALBARA OTRAFACTUR 2 Otro albarán
TIPOALBARA ANULADO 3 Albarán anulado
TIPOFACTU NORMAL 1 Factura normal
TIPOFACTU RECTIFICAT 2 Factura rectificativa
TIPOFACTU ABONO 3 Factura rectificativa de abono
TIPOFACTU OTRAFACTUR 4 Otra factura
TIPOFACTU OTRAFACREC 5 Otra factura rectificativa
TIPOFACTU OTRAFACABO 6 Otra factura rectificativa de abono
TIPOFACTU PROVISION 7 Provisión de fondos

Tabla de facturas usa la clave TIPOFACTU para los distintos valorees del
campo con el mismo nombre.

Id TipoFactu FchFac
1 NORMAL 2009-03-23 00:00:00.000
2 OTRAFACTUR 2009-03-24 00:00:00.000
3 OTRAFACTUR 2009-03-24 00:00:00.000
4 OTRAFACTUR 2009-03-24 00:00:00.000
7 NORMAL 2009-03-25 00:00:00.000

Esta tabla por lo tanto se aprovecha para primero para saber que valores
acepta el campo TipoFactu en la tabla de facturas.

Aprovechamos esta tabla para generar códigos traducibles a otros
idiomas, juntando el campo Clave y RespuCod, entre otros. En verdad el
campo RespuDesc sólo es relevante para el programador y los que acceden
a la base de datos desde T-SQL pero para el aplicativo que muestra los
datos al usuario, en verdad lo que devuelve es el resultado de buscar la
clave generada en una tabla de idioma, que devuelve el RespuDesc, Traducido.

SELECT NumFac "Nº Factura",
dbo.DameTextoIdioma('TIPOFACTU' + TipoFactu, '0c0A')
"Tipo Facura en Español",
dbo.DameTextoIdioma('TIPOFACTU' + TipoFactu, '8016')
"Tipo Factura en Portugués",
FchFac "Fecha Factura"
FROM dbo.Facturas
WHERE FchFac >= '20090320'


Y por último para mostrar las distintas opciones de respuesta en un
orden determinado dentro del aplicativo aprovechando el campo Orden.
La clave CANALTIPO, siguiendo el ejemplo se mostraría por ejemplo en un
cuadro desplegable siguiendo el orden siguiente:
- Prescriptor
- Cliente
- Agente colaborador


Esta tabla más que nada ayuda a los programadores a estandarizar valores
a los campos de tablas que tienen unos valores predefinidos.

Podría tener una tabla diferente por cada agrupación respuestas posibles
a los campos y unirlos mediante FK.

Tabla Factura
FacturaId NumFac TipoFacuID,
1 B332-01 1
2 B333-01 1
3 C001-01 2


TipoFactuId TipoFactu
1 NORMAL
2 RECTIFICAT
3 ABONO
4 OTRAFACTUR
5 OTRAFACREC
6 OTRAFACABO
7 PROVISION

Pero para mi gusto prefiero tener una tabla tipo diccionario, que me
indique que significa cada clave. La tomo como una tabla del sistema de
la base de datos.




El 03/06/2009 09:38, Carlos Sacristan escribió:

No entiendo muy bien tu primer ejemplo.

En cuanto a lo demás, el mal diseño (desde mi punto de vista) es que la
tabla tenga un ID y luego una descripción de todos los objetos que tengas
que almacenar (que es lo que decía Penta). Si el resto de las tablas apuntan
a ese ID (por medio de una FK), si por ejemplo quieres hacer referencia a un
nombre de país, ¿cómo validas que estás haciendo referencia efectivamente a
un país? ¿por el intervalo del número referenciado? ¿por que es negativo?
¿por que es superior a un valor dado?

Otra cosa es que la tabla "descripciones" sea algo similar a:

ID
Tipo
Idioma (opcional)
Descripción

Donde la PK de la tabla es ID+Tipo. Ahí sí que es posible tener una tabla
única de descripciones y que las tablas hagan referencia al registro
correcto no sólo desde el punto de vista de integridad referencial, sino
también, por decirlo de algún modo, desde el punto de vista lógico. Es
decir, podríamos tener que el código 1-P hace referencia al país "España", y
en la tabla de clientes, tener una FK en el campo "pais" a la tabla de
descripciones con un CHECK que valide que sólo se admiten registros del tipo
"P" (de países).

Para validar integridad referencial dejaría los triggers para validaciones
más complejas, pero éste creo que no es el caso.

Salu2 Rafael Cano
desarrollo(arroba)rafacano.es
Jaén - España
Villamartín - Cádiz - España