Tabla de clientes, proveedores, registro fiscal

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


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





"Carlos" <carl> wrote in message
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?

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?

Hola Carlos,

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

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

No lo creo.

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.

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

Clientes
codigo, codigoFiscal, limiteVenta, etc.

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

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

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

Hola Jose Mariano,

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

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.

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.

Si agregas una tabla mas es probable que requieras mas joins para
resolver tus consultas lo cual seria mas lento en las consultas,

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

Sugiero que revises la teoria
de normalizacion de bases de datos hasta la quinta forma normal y luego
decidas.

Podías haberlo hecho tú también.


Saludos

Las vistas actualizables tienen ciertas restricciones que sugiero
revisarlas.
http://technet.microsoft.com/es-es/...80800.aspx



Saludos

Ing. Jose Mariano Alvarez
SQLTotal Consulting


(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" wrote in message
news:

Hola Carlos,

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

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

No lo creo.

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.

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

Clientes
codigo, codigoFiscal, limiteVenta, etc.

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

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

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