Campo dependiente de otros campos en varias tablas

Mira la que has montao, jejejeje

Hace tiempo que no se veian hilos de esta extension

SALUDOS.
julian-valencia-españa

Por supuesto Julian, que en esta disquisición eres el que menos has hablado.
A mi entender ambas formas son válidas.
Tenemos el ejemplo de un programa de contabilidad en el que los asientos es
el eje de la aplicación. En este caso hay una sola tabla en la que se indica
si el Tercero es cliente o proveedor.
Tenemos otro caso, de una Nave industrial que tenga varios almacenes para
sus productos. En éste caso, cuyo eje central son los movimientos de
distintos almacenes, yo optaría por dos tablas, compras y ventas desde las
que cargaría o abonaría los productos a los distintos almacenes.
Como verás, creo que no se puede generalizar, sino es más conveniente
analizar cada caso concreto. Yo he hecho aplicaciones con ambas opciones,
aunque a veces cuesta decantarse por una u otra.


"julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
news:#

Que conste que solo pregunto, y lo hago con la sana idea de que me deis
razones para decantarme por una forma u otra.

¿Por qué te parece mal juntar proveedores y clientes?

Si tienen o pueden tener los mismos campos, no le veo problema, y si a la
tabla le llamamos PERSONAS (fisicas o juridicas)?

Despues de tener esta tabla creada, nos damos cuenta que unas personas

solo

nos compran y otras solo nos venden, y entonces decidimos crear un campo

mas

para diferencias a unas de las otras.

SALUDOS.
julian-valencia-españa

OK.

Ya me sabe mal no poder decantarme por una opcion u otra de forma general,
pero como dijo alguien .

Una base de datos es el reflejo de una parte de la realidad, y como tal,
cada uno tenemos la nuestra, y la vemos bajo nuestro punto de vista.

Hace tiempo, cuando la gente no podia facilitar mas que un nuemro de
telefono, en una tabla de personas se ponia un campo que era telefono y
arreando.

Hoy en dia, cualquiera te da 2 moviles, el de casa, el del trabajo, etc., y
esto nos obliga a crear a las personas sin campo telefono, y a crear otra
tabla telefonos.

SALUDOS.
julian-valencia-españa

P.D.: Esto de las ñus me dijeron que era para resolver dudas y aclarar

ideas

Y no te dijo mamá que no hicieras caso a los extraños????? Que hay mucha
gente mala en este mundoooooooooo ;)

Eva Etxebeste
[MS MVP]
***IMPORTANTE*** Microsoft Security Bulletin MS03-039
http://www.microsoft.com/security/s...03-039.asp

No era mi intención generar polémica, ni mucho menos dármelas de
perfeccionista, estoy convencido que todo aquel que ha participado ha
comprendido que era una propuesta para solucionar un problema (NO LO DUDO).

Personalmente he llegado a las siguientes conclusiones:

1;- El modelo Entidad-Relación es una herramienta imprescindible para el
buen diseño de una bd.

2;- La normalización, en su justa medida, atada a las reglas de negocios
particulares es otra herramienta imprescindible

3;- Las tablas y las relaciones extraidas de los puntos (1) y (2) solamante
son contenedores de información CONSISTENTE (esto último gracias a las
relaciones).

4;- Logramos que una bd modelice una situación gracias a:
4.1;- Implementar la INTEGRIDAD DE LOS DATOS
4.2;- Una BATERÍA de consultas (en mi caso las bd que implemeto, un 90%
son consultas)
En definitiva hacer uso de la idea de conjuntos en contraposición del acceso
secuencial en el tratamiento de datos.

5;- MINIMIZAR en la medida de lo posible (esto depende del SGBD utilizado)
la consistencia del modelo usando "artificios" externos, como podría ser
código.

Bien, llegados a este punto tenemos que implementar la solución haciéndo uso
de algún SGBD, Access (JET 4) es una excelente herramienta, pero
particularmente (es una opinión muy personal) adolece de la falta de
DISPARADORES, creo que estos posibilitarían INFINITAMENTE la implementación
de la INTEGRIDAD DE DATOS, en definitiva podríamos implementar por completo
el modelo. Creo que la integridad referencial que meneja JET es un
subconjunto muy limitado que no abarca todas las posibilidades, si algún día
JET nos permitiera el uso de disparadores, creo que nos haría CAMBIAR POR
COMPLETO nuestra visión (quizás es sólo mía esa visión) de cómo JET entiende
la integridad DE LOS DATOS (concepto más amplio que la integridad
referencial, que él maneja)

Ya os digo que es una opinión personal, podría estar equivocado, en
definitiva para mí la idea de INTEGRIDAD REFERENCIAL que maneja JET es un
concepto REDUCIDO de la INTEGRIDAD DE LOS DATOS (concepto "teórico" en el
diseño de bases de datos)

En fin gracias!!!