informacion sobre tipo de tablas

[Casimiro Noteví]

Perdón, por si acaso me he 'pasado'.
Bienvenido.

[cacho22]

Hola foro, soy nuevo aqui, asi q disculpen si hago algo mal...

Me parecio muy interesante la explicacion q dio delphius acerca de los tipos de tablas...Yo soy desarrollador de programas orientados al manejo de Base de Datos, y en base a la experiencia se me han presentado ciertos problemas en el manejo de tablas historicas.

Aca les doy un ejemplo muy claro, en una base de datos de inventarios (que es la mas comun, para estos casos). en el año 2005 (solo un ejemplo) se añadió el cliente "CAINCO SRL" con codigo 35, posteriormente se hicieron 'ventas' a este cliente todo el 2005 y 2006, es decir se registro en la tabla ventas registros con este cliente (id 35) y se emitieron reportes para saber el historico de ventas a este cliente de 2005 y 2006, todo ok!. Aca viene el problema... el 1ero de enero de 2007 se modifica el nombre del cliente (en la tabla clientes) 'CAINCO SRL.' a 'DAHER S.A' y se siguen haciendo las ventas todo el 2007; Aca viene el problema (repito de nuevo) en el reporte historico que hago desde el 2005 al 2007... me salen ventas que hice al usr. DAHER S.A. siendo q este no existia en el 2005 y donde quedaron las ventas al usr. CAINCO SRL.?

Se q este es un mal manejo de la información, lo correcto deberia ser crear un nuevo cliente. (DAHER SRL) y dejar al cliente. anterior sin cambio (CAINCO), para q todo esto funcione correctamente.

Hay alguna otra alternativa de solucionar estos problemas? Que tipo de anomalia seria esta? En que casos se tendria que preveer esta situacion? Como se podria mantener una información correcta en la base de datos atravez del tiempo y Que manera optima se recomedaria para estos casos?

Gracias foro.

[[Delphius]]

Hola cacho22,
Bievenido a clubdelphi.

No se si seré el más adecuado para responderte, pues como he dicho antes... es seguro que hay gente que domina mejor esto.

Yo defiendo la idea de que todo depende del negocio. Sobre todo lo refierido a la base de datos, que es donde queda asentada toda la información (mejor dicho los datos).

Viendo lo que expones, yo apresuradamente diría que se trata de un error del concepto del dominio. Pero como sabemos, un error de dominio no es un error sino una interpretación del dominio a un nivel de abstracción determinado. Es decir que el diseño de la tabla y/o de la base de datos responde a una solución de menor nivel de complejidad ("complejidad" en cuanto a medida de implementar la solución en base a la abstracción) que la necesaria actualmente.
Por tanto la anomalia no es de sistema sino más bién que se debe a un cambio a nivel del dominio (lo cual es muy frecuente).

Una solución que yo consideraría es implementar un histórico de movimientos de los clientes. Es decir que ante cualquier operación ABM se quede acentado de dicho cambio. Vulgarmente decimos: "Un cliente puede tener muchos movimientos a su nombre y/o razón social" Por lo tanto una solución sería implementar una Tabla MovCli que lleve constancia (como mínimo) de:
1. el ID del cliente (obvio)
2. Fecha de la operación (movimiento)
3. Tipo de operación (alta, baja, modificación)
4. Campos necesarios para llevar la información anterior

De modo que para llevar el dichoso histórico debe "cruzarse" dicha info con los movimientos y no solo con la tabla Clientes.

Lo que dije es un modelo simple, es una idea... y como toda idea debe ajustarse y refinarse.
Espero que se me entienda...

Al menos asi lo veo yo.
Saludos,

[cacho22]

Saludos estimado Delphius:

Exactamente, lo mas aconsejable seria tener un historico de las ABM (altas,bajas,modificaciones) que ha hecho el USR a la tabla clientes, esto se puede hacer automaticamente en manejadores de base de datos ultimos (mediante triggers) quedando la ultima version del reg. en la tabla (en este caso clientes).

Si entendi bien, si quiero sacar un reporte de ventas de un lapso de tiempo largo, por ej. del 2005 al 2007 tendria q cruzar las tablas ventas con h_cliente (historico de cliente) para sacar una información mas correcta, en vez de ventas con cliente?.

Si es esto, desarrollar el reporte me resultaria mas complejo, sin embargo sacaria una información coherente.

No crees que una mejor alternativa seria 'bloquear de por vida' el nombre o razon social para los clientes una vez que estos ya han realizado un movimiento en la tabla ventas?, es decir, nunca mas dejar modificar el nombre o razon_social para este cliente una vez este haya realizado una compra?

Gracias por tu respuesta tan rapida....

Saludos

[[Delphius]]

Empezado por cacho22

Saludos estimado Delphius:

Exactamente, lo mas aconsejable seria tener un historico de las ABM (altas,bajas,modificaciones) que ha hecho el USR a la tabla clientes, esto se puede hacer automaticamente en manejadores de base de datos ultimos (mediante triggers) quedando la ultima version del reg. en la tabla (en este caso clientes).

Si entendi bien, si quiero sacar un reporte de ventas de un lapso de tiempo largo, por ej. del 2005 al 2007 tendria q cruzar las tablas ventas con h_cliente (historico de cliente) para sacar una información mas correcta, en vez de ventas con cliente?.

Si es esto, desarrollar el reporte me resultaria mas complejo, sin embargo sacaria una información coherente.
Saludos

Hola de nuevo cacho22.
Tu lo haz dicho, obtener el histórico ahora es más complicado... es el precio que se paga cuando se elevan los "requisitos".

Empezado por cacho22

No crees que una mejor alternativa seria 'bloquear de por vida' el nombre o razon social para los clientes una vez que estos ya han realizado un movimiento en la tabla ventas?, es decir, nunca mas dejar modificar el nombre o razon_social para este cliente una vez este haya realizado una compra?
Saludos

Yo al comienzo he dicho que no se si soy el más indicado. Por lo que no soy dueño de la verdad absoluta. Y lo que he planteado no deja de ser una simple idea (mejor dicho alternativa).
Lo que dices es correcto. Correcto en cuanto al dominio que tu estás estudiando y entendiendo.
Pero... claro... como todo análisis, no es único. Tu desarrollo es una representación de tu entendimiento y si consideras que la razón social y/o el nombre de un cliente no puede ser alterado. Todo tu sistema lo reflejará y seguirá funcionando en cuanto la realidad se apegue a tu concepto del problema.

En fin... será cuestión de "gustos". La idea de hacer fijo los datos del cliente funciona, pero no es la única. Y hay otros factores que entran en juego: la progragación de requisitos y funcionalidades.

Imponer una restricción (que el cliente no pueda cambiar su razón social ha dejado de ser un requisito, ahora en tu concepto es una restricción) podría provocar cambios en el modo de operar tu sistema. Una restricción nunca debería cambiar a lo largo del ciclo de vida, por tanto condiciona al sistema (entendido a este como el todo: el software, la base de datos, etc) muy fuertemente y lo sujeta a un modelo rígido de la realidad.

Considero que si uno se plantea interrogantes es porque hay un elemento o punto del análisis y/o del dominio que no ha sido totalmente comprendido (o más común que sea opuesto o ambiguo a una parte de si mismo) Y hasta que en tu concepto no esté totalmente forjada la idea y comprensión seguirá siendo un elemento débil.

Por ejemplo: puede darse el caso que dependiendo de la razón social de tu cliente se computen ciertos descuentos, impuestos o algunas reglas de negocio. Si los datos de tu cliente necesitan ser fijos y como dices... que ante el cambio de razón social debe agregarse un nuevo cliente... esta imposición puede que lleve consigo una inconsistencia en algún otro punto del sistema si no se tienen las precuaciones y el debido análisis de las situaciones.

Ojo... no digo que tu planteo está mal. Como he dicho: podría traer consecuencias, no quiere decir que vas a tener problemas. No aseguro ni niego nada. Tu planteo debe ajustarse al mejor concepto de la realidad que tu comprendas.

Puedo aceptar tu propuesta y la aceptaré siempre y cuando considere que el modelo del diseño me lo permita. Y haya considerado (en lo que mi poca experiencia me lo diga) que implementarlo de dicha manera no traiga consigo malestares.

Esto te lo digo por lo que he visto en mi último trabajo. Uno cree que lo diseñado funciona y funciona hasta que viene el señor cambio y te lo da vuelta. Me ha tocado ser "DBA" y he encontrado un diseño que ha venido funcionando... pero claro... cuanto más me empapé del negocio puede ver y ser testigo de las complicaciones y artilugios que se tuvieron que implementar en el sistema para conseguir manteniendo la consistencia. He llegado a percatarme de que con unos pocos cambios en las tablas se hubieran solucionado algunos males.

Bueno en fin... no deja de ser un planteo. Y es así como se vive en el desarrollo del software: vivimos en un mundo en que se desea controlar pequeños y grandes caos y somos nosotros quienes deben darle cierto orden. Simulando la realidad e irnos preparandonos hacia los posibles nuevos cambios.

Sería muy interesante escuchar otros puntos de vista.
Saludos,

[cacho22]

Delphius:

Me parece muy importante tu opinion y mucho mas al saber que trabajaste o trabajas como DBA, yo igualmente soy DBA en mi empresa, y actualmente estoy en el proceso de analisis de un nuevo sistema para el manejo de caja y como tu dices uno no es dueño de la verdad, sin embargo tu opinion es muy respetable y me abre muchas ideas alternativas para solucionar los problemas q a futuro se puedan presentar.

Respecto a lo que citaste:

Imponer una restricción (que el cliente no pueda cambiar su razón social ha dejado de ser un requisito, ahora en tu concepto es una restricción) podría provocar cambios en el modo de operar tu sistema. Una restricción nunca debería cambiar a lo largo del ciclo de vida, por tanto condiciona al sistema (entendido a este como el todo: el software, la base de datos, etc) muy fuertemente y lo sujeta a un modelo rígido de la realidad.

de nuevo tienes toda la razon, por q si bien uno pone esta restriccion en todo el ciclo de vida del software o programa, puede ser q por ordenes superiores se te obligue a modificar la tabla citada, en este caso la razon_del_cliente, entonces todo el analisis ya no funcionará y esto llevará a inconsistencias futuras.

Por eso como tu dices, imponer esta restriccion haria el modelamiento de la realidad demasiado rigido (segun el caso, o la comprension q uno tenga).

Por tanto, sabiendo q en un futuro se tenga necesariamente que cambiar el nombre de ciertos clientes (yo creo q seran muy pocos en el transcurso de los años) el planteamiento q tu sugieres seria realizar los reportes de ventas cruzando la tabla de historico de clientes (h_cliente) con la tabla ventas?, claro q como decias:
es el precio que se paga cuando se elevan los "requisitos". Sin embargo el resultado es "obtener una información coherente y sin incosistencias" q es lo que uno busca.

Me parece que este diseño lo deben utilizar el servicio de impuestos internos de mi pais, por q en sus reportes t dan una información muy coherente de todo lo que hiciste en un lapso de tiempo prolongado.

Me es muy importante saber tu opinion, o plantear otra solución alternativa a las dos q se estan analizando de este caso en específico, gracias por tu colaboracion.

Saludos
cacho22

[[fjcg02]]

Pienso que las solución no está ni en una de las propuestas ni en la otra, pero sí en las dos.

En serio, bajo mi punto de vista, el problema es de uso. Dudo que un cliente cambie de nombre, de tipo de compañía ( SRL a SA ) y no cambie de NIF - nº de identificación fiscal -, es decir el DNI para entendernos.

En el caso de que cambie el NIF, el cliente es nuevo, por lo que habría que haberse creado un nuevo cliente y asignarles las ventas a ése.
También puede darse el caso de que se haya registrado mal el nombre de un cliente por error, por lo que debería permitir la aplicación cambiarlo, aunque sea de una manera restrictiva y sabiendo lo que se hace.

Por lo tanto, yo dejaría la aplicación como está, ya que según mi opinión, está bien.

Espero haber aportado algo, aunque no tenga nada que ver con las tablas maestras, submaestras ni históricas.

He dicho.

Saludos

[cacho22]

Exactamente, en el ejemplo que estamos tratando, yo pienso q se tendria q restringir el nombre_del_cliente para que no se modifique, y si en algun caso se tiene q modificar, eso lo haga el DBA, claro q tendria q ser un pequeño detalle como por ejemplo arreglar una letra mal escrita o aumentarle un pqueño detalle, pero es importante saber bien que es lo que se esta haciendo, porque si se va cambiar completamente el nombre_del_cliente esto llevaria a una inconsistencia real.

Talvez si conoces alguna direccion q hable de estos temas o parecidos te estaria muy agradecido.

Muchas gracias por tu colaboración.