SQL Server - Tabla de clientes, proveedores, registro fiscal

Asked By Carlos on 10-Jan-09 08:40 AM
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?




Jose Mariano Alvarez replied on 10-Jan-09 01:45 PM
Si, podrias, solo que deberias analizar por un lado los requerimientos
funcionales de tu aplicacion y luego de aplicar la normalizacion de tu base
de datos definir si esa normalizacion te aporta valor o en tu modelo
funcional podrian ser atributos del cliente y evitar la entidad registro
fiscal. Si agregas una tabla mas es probable que requieras mas joins para
resolver tus consultas lo cual seria mas lento en las consultas, pero seria
mas rapido y menos peligroso actualizarlas.  Sugiero que revises la teoria
de normalizacion de bases de datos hasta la quinta forma normal y luego
decidas.

--


Saludos
------------------------
Ing. Jose Mariano Alvarez
SQLTotal Consulting

Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0
(Cambia los ceros por O y saca lo que sobra)

------------------------
IMPORTANTE
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
------------------------

Por favor tratar de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el problema
también ayuda.
Jose TH replied on 10-Jan-09 02:55 PM
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.
Alfredo Novoa replied on 11-Jan-09 11:32 AM
Hola Carlos,

El Sat, 10 Jan 2009 09:40:57 -0400, Carlos escribió:


No lo creo.


Si, mucho mejor. Es muy común que haya empresas que sean tanto clientes
como proveedores.


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


Para nada, y además es más fácil mantener los datos consistentes por que si
cambia un dato de un tercero solo tienes que actualizarlo en un sitio.

Si quieres que las consultas y las actualizaciones sigan siendo tan
sencillas como antes puedes usar vistas actualizables.


Saludos
Alfredo Novoa replied on 11-Jan-09 11:46 AM
Hola Jose Mariano,

El Sat, 10 Jan 2009 16:45:40 -0200, Jose Mariano Alvarez escribió:


Menudo lío te estás montando. La normalización no tiene nada que ver con lo
que pregunta Carlos, y en todo caso habría que decidir si es conveniente
antes de aplicarla y no después :-)

Además estás confundiendo el modelo funcional con el modelo lógico. La
normalización se aplica al modelo lógico. Se pueden usar modelos lógicos
diferentes para los mismos requerimientos funcionales.


Hay cosas mucho más importantes que un incremento marginal en los tiempos
de algunas consultas.


Podías haberlo hecho tú también.


Saludos
Jose Mariano Alvarez replied on 11-Jan-09 04:16 PM
Las vistas actualizables tienen ciertas restricciones que sugiero
revisarlas.
http://technet.microsoft.com/es-es/library/ms180800.aspx

--


Saludos
------------------------
Ing. Jose Mariano Alvarez
SQLTotal Consulting

Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0
(Cambia los ceros por O y saca lo que sobra)

------------------------
IMPORTANTE
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
------------------------

Por favor tratar de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el problema
también ayuda.
Alfredo Novoa replied on 11-Jan-09 05:32 PM
El Sun, 11 Jan 2009 19:16:51 -0200, Jose Mariano Alvarez escribió:


... ninguna de las restricciones se aplica a actualizaciones que se lleven
a cabo por medio de desencadenadores INSTEAD OF.
Carlos M. Calvelo replied on 12-Jan-09 10:08 PM
Hola Jose Mariano,

On 11 jan, 22:16, "Jose Mariano Alvarez"

Las vistas que no hubieran sido actualizables a causa de ciertas
restricciones, s=ED pueden serlo utilizando otros mecanismos que
sugiero se revisen:
http://technet.microsoft.com/es-es/library/ms175521.aspx
(Enlace desde la p=E1gina que tu has aconsejado)

Sugiero tambi=E9n que revises tu primera respuesta al OP.
Eso me parece mucho mas importarte para el OP que ponerse a
discutir qu=E9 vistas son, o no son, actualizables.

Saludos,
Carlos
Carlos M. Calvelo replied on 12-Jan-09 10:08 PM
Hola Alfredo,

ores
.

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

Saludos,
Carlos
Jose Mariano Alvarez replied on 11-Jan-09 07:53 PM
Revisa el mensaje de error 414 .

--


Saludos
------------------------
Ing. Jose Mariano Alvarez
SQLTotal Consulting

Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0
(Cambia los ceros por O y saca lo que sobra)

------------------------
IMPORTANTE
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
------------------------

Por favor tratar de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el problema
también ayuda.
Jose Mariano Alvarez replied on 11-Jan-09 09:58 PM
Alfredo:

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. Hoy por hoy también me encuentro permanentemente con modelos que
representan objetos, lo cual tanbien hace difícil definir cual es la mejor
forma y ahí no podríamos hablar de dependencias funcionales y de
normalización deberíamos pensar en el modelo adecuado de persistencia.

Es verdad que puede haber varios modelos lógicos de base de datos que
respondan a los requerimientos funcionales de la aplicación, como usted
dice, así como puede ser que un único modelo lógico pueda responder a varios
modelos funcionales.

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, aun sin el correspondiente análisis de las
dependencias funcionales tal como lo define la teoría.

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. Por ejemplo en
mi país existen varios  números fiscales otorgados por organismos
gubernamentales diferentes para cada persona/empresa/grupo económico. En ese
caso el numero de teléfono que propone almacenar no parece adecuado como
atributo de la entidad. "registro fiscal" y si parece mas adecuado en una
entidad "Empresa/Persona" o ("Party") como suelen expresar los modelos
americanos y tener una entidad de registros fiscales con solo los atributos
que si dependen funcionalmente de la clave de registro fiscal.


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".


--


Saludos
------------------------
Ing. Jose Mariano Alvarez
SQLTotal Consulting

Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0
(Cambia los ceros por O y saca lo que sobra)

------------------------
IMPORTANTE
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
------------------------

Por favor tratar de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el problema
también ayuda.
Alfredo Novoa replied on 11-Jan-09 10:56 PM
Hola Carlos,

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


Eso sí. Verse claro que se ve.


Saludos
Alfredo Novoa replied on 11-Jan-09 11:07 PM
El Sun, 11 Jan 2009 22:53:49 -0200, Jose Mariano Alvarez escribió:


¿Y eso por qué?

Saludos
Alfredo Novoa replied on 12-Jan-09 12:13 AM
El Mon, 12 Jan 2009 00:58:55 -0200, Jose Mariano Alvarez escribió:


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.


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 :-?


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.


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.


Una cosa es ser laxo y otra dar respuestas surrealistas.


Saludos
Carlos replied on 12-Jan-09 07:45 PM
Sí, asi es, el código fiscal es para la empresa en general (no cambia por
sucursal).  Lo tendre en consideración.

gracias
Carlos replied on 12-Jan-09 07:51 PM
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.
Carlos replied on 12-Jan-09 08:01 PM
Gracias por la sugerencia aunque en realidad fue como lo planteé, es un solo
numero fiscal, como una cédula para cada persona fisica o juridica (empresa)
que hace operaciones comerciales de compra o venta, para fines de reportes
de impuestos.
Como dice Alfredo Novoa, la pregunta no estaba asociada directamente con
normalizacion.  De todos modos, gracias por tu ayuda.
Alfredo Novoa replied on 13-Jan-09 05:24 AM
Hola Carlos,

El Mon, 12 Jan 2009 20:51:00 -0400, Carlos escribió:


Ah, bueno. Es que en mi país son bastante cortos.


Saludos