Tabla de clientes, proveedores, registro fiscal

Hola Carlos,

El Sun, 11 Jan 2009 15:03:05 -0800 (PST), Carlos M. Calvelo escribió:

Hombre... 'normal' no será, pero que eso se vé mucho.. sin duda.
Y yo si lo veo... lo creo. :-)

Eso sí. Verse claro que se ve.


Saludos

El Sun, 11 Jan 2009 22:53:49 -0200, Jose Mariano Alvarez escribió:

Revisa el mensaje de error 414 .

¿Y eso por qué?

Saludos

El Mon, 12 Jan 2009 00:58:55 -0200, Jose Mariano Alvarez escribió:

Mi intención fue sugerir que revisara la teoría ya que parecía que estaba
modelando una base de datos relacional y todos los requerimientos no los
conocemos y hacer el análisis correspondiente es complejo e imposible en el
foro.

Pero le has sugerido que antes de decidir revise una teoría que no tiene
que ver con lo que preguntaba. Eso en mi pueblo no es muy normal.

Otra cosa importante a tener en cuenta, y que suele suceder frecuentemente,
es que por ahorro de interpretación (y por el uso de herramientas CASE),
muchas veces existe casi una correspondencia 1 a 1 entre el modelo lógico y
el físico. Por lo tanto hablar de separar y crear una tabla nueva para
evitar redundancias creo que puede y es generalmente entendido como un
mecanismo de normalización,

Esto no tiene ningún sentido. En la primera parte parece que llamas modelo
lógico al modelo conceptual y modelo físico al modelo lógico, y la
conclusión no tiene nada que ver con la premisa. Es como si digo: me llamo
Juan, por lo tanto tengo una bicicleta.

Además solo alguien que no sepa lo que es la normalización puede entender
que consiste en separar tablas para evitar redundancias sin más.

Por una parte difundes un gran error y a continuación sugieres revisar la
teoría que contradice lo que acabas de decir :-?

En cuanto al caso en particular, habría que determinar claramente la ventaja
de hacerlo. Es verdad que normalizar parece ser lo adecuado y por eso le
respondí que si coincidiendo con usted, sin embargo no puedo ser tan
categórico como usted, porque no puedo saber cuales de los atributos
relacionados a la clave primaria de la entidad "registro fiscal" son
dependiente funcionales porque eso lo definen los requerimientos funcionales
particulares y las simplificaciones que se pueden aplicar. A priori, el
modelo podría ser adecuado pero también podría ser erróneo.

Que líos te montas. Carlos hizo una pregunta muy concreta poniendo un
modelo muy esquemático para ilustrar ese problema en concreto. Y la
respuesta es muy clara independientemente de la complejidad del resto del
modelo. Es muy probable que haya que tener muchas más tablas que las del
ejemplo de Carlos, pero eso no era relevante en ese momento.

Por ejemplo en
mi país existen varios números fiscales otorgados por organismos
gubernamentales diferentes para cada persona/empresa/grupo económico.

Pues menudo lío. Pero si lees el mensaje de Carlos dice que en su país se
usa uno y basa precisamente en eso todo su razonamiento.

Me pareció que ser tan estricto en cuanto a los términos no aportaba valor
por eso fui algo mas laxo y seguiré siéndolo en pos de que la mayoría sea
beneficiada. .Espero usted sepa disculpar mis expresiones "inexactas".

Una cosa es ser laxo y otra dar respuestas surrealistas.


Saludos

Sí, asi es, el código fiscal es para la empresa en general (no cambia por
sucursal). Lo tendre en consideración.

gracias

<Jose TH >>> escribió en el mensaje
news:e$

Puede que esté bien para evitar duplicidades y el manejo se puede hacer
por vistas. Pero ojo, en el caso de empresas debes tener en cuenta si
ese codigo fiscal es el mismo sin importar que la empresa tenga o no
sucursales, ya que los datos de localización (dirección, teléfonos, etc.)
variarían por sucursal.



"Carlos" <carl> escribió en el mensaje
news:O$

Hola.

Normalmente en las aplicaciones uno ve las tablas de clientes y
proveedores con sus datos normales de codigo, nombre, direccion,
telefono, etc. etc.

En mi pais y creo que en la mayoria , se usa un numero de registro fiscal
para cada persona o empresa que compra o vende. Y la duda que tengo es si
no es conveniente tener en vez de la tipica tabla de clientes y la de
proveedores, tener una tabla con los registros fiscales y tener alli
mejor los datos comunes de nombre, direccion, telefono, aparte del codigo
fiscal ?
Sobre todo pensando que una misma persona o empresa puede ser tanto
cliente como proveedor.

Clientes
codigo, codigoFiscal, limiteVenta, etc.

Proveedores
codigo, codigoFiscal, limiteAsignado, etc.

CodigosFiscales
codigoFiscal, PersonaOEmpresa, nombre, direccion, telefono, etc.

Ahora, en caso de tenerlo asi, no seria muy complicadas las busqueda,
consultas, o las actualizaciones ?
valdria la pena?

Ya que tienes un campo de código fiscal que es clave te podrías ahorrar el
otro código.

lo que pasa es que el código fiscal es muy largo pero lo analizaré a ver que
tal.

por lo demas, muchas gracias, captaste muy bien la idea, ya voy viendo lo de
los triggers Instead Of para las vistas.