informacion sobre tipo de tablas

[Casimiro Noteví]

[sarcastic]
gabrielflowers, ¿te conformas con esa explicación tan somera que te ha dado el compañero Delphius?... no, no te rindas: exígele los ejemplos que estás pidiendo y que tanto necesitas para aprender todo eso tan complejo de "tablas maestras, submaestras, historicas, etc.", complejo para todos menos para el amigo Delphius, que es el único que sabe.
[/sarcastic]



Habrase visto...

[[Delphius]]

Como no me llegan al correo los avisos de nuevos mensajes no he vuelto por aqui... y al volver me doy con esto.
Creo que me veo obligado a intervenir.

De entrada te digo que por favor no te enojes:

gabrielflowers, yo no soy ningún experto en el tema... ha decir verdad llevo 4 años manejando los conceptos que implica base de datos. Y por si deseas saber: no soy ingeniero (aun). Me falta tan solo una materia (mejor dicho tesis) por si deseas saber.
Si conozco y domino estos conceptos se deberá a que me paso diariamente entre 5 a 8 horas buscando e interpretando elementos del dominio y armando redes de entidades como ejercicio de rutina (si aunque no lo creas, a veces... lo hago al mismo tiempo junto a otras actividades).

Y a pesar de ello... creo que hay gente que domina mejor el arte de las base de datos. Si dichas personas no intervinieron antes se debe a que:
1. El tema es simple y tus palabras no daban a entender cual es tu verdadera problemática. Lo cual fue el verdadero problema aquí.
2. No tienen tiempo libre.

Si recuerdas, te había comentado que el tema es simple. No tiene demasiada ciencia... de ingeniero a ingeniero te digo que no te centres en un solo comentario. Como ingeniero de seguro que te enseñaron a que primero se debe buscar alternativas y no quedarse con la primera.

Y, lamento mucho que te lo diga.. pero ¿Como ingeniero que eres... no haz sido capaz de dar una mejor explicación de tu problema, o dudas? No es que esté enojado contigo... pero ha decir verdad (mil disculpas que lo diga) no se que esperar de que un ingeniero en sistemas no sepa entender lo que implica tabla Maestra, subMaestra, Histórica.
No me creo el sabelotodo... pero es que todos de manera directa e indirecta te estabamos haciendo saber que por empezar el tema es muy simple.
No se como habrá sido tu formación profesional. Pero si no sabes esos conceptos en pocas líneas, o si no lo habías visto durante el cursado de tu carrera... Hemos empezado mal.

Me alegro que te haya servido de algo lo que dije. Pero como bien lo ha señalado Neftali: hablar del tema nos puede llevar tiempo. Tiempo que no todos, estamos dispuesto a disponer.
Si ofrecí exponer aquel texto al que tu tomaste y aceptaste como válido es porque estaba cansado de ver el mismo comentario por tu parte... y decidí tomarme el tiempo y buscar las palabras más simple para que se entendiera.

Y disculpa que lo diga: Neftali, egostar y Casimiro tienen la razón.
Te hemos dicho que tus palabras no eran las adecuadas para el propósito de tu pregunta. Si hubieras buscado otros términos y palabras, las respuestas podrían ser otras.

No quiero iniciar problemas... te doy una buena bienvenida al foro. Como recomendación, lee la guia de estilo. Toma esto como un hecho de risa... y recordaremos a este mal entendido en la taberna con humor.
No digo que hiciste mal en poner tu pregunta... simplemente empezaste mal... y todavia estas a tiempo.
No queremos problemas... pero es que aqui exigimos un poco más de colaboración por parte de quien pregunta para poder dar las mejores respuestas.

A todo esto.
Saludos,

[gabrielflowers]

bueno, lei tu intervencion, y antes que nada yo ya he hecho algunas BD para uno que otro sistema de informacion en la universidad, mira pero el concepto de tabla maestra, submaestra e historica recien la escuche trabajando en el desarrollo de un ERP, y mira que no es culpa mia, ni la de mi univ de no exponer los conceptos de ese tipo de tabla, pues cada universidad tiene diferente tipo de enfoque, algunas son mas empresariales, otras mas tecnicas, etc etc
y sobre ,mi pedido veras que era sencillo, solo queria ejemplos de aplicacion de tablas maestras, submaestras, historicas, claro previamente ya tenia una idea sobre todo ello, pero buscaba alguien mas docto en ese aspecto, alguien con mas experiencia que yo, que me explicase en que caso usa cada una, nada mas, no hay misterio en eso
y ademas te digo que no he empezado mal, pues esta no era mi primera intervencion en este foro, ya antes plantee preguntas en este foro, y obtuve repuestas satisfactorias
quizas al principio fui muy breve, pero ya luego, trate de ser mas explicito

pdta:no quiero hablar mas, me fatiga hablar ya, si para mi el tema concluyo hace rato, con tu (breve) aportacion
gracias, saludos a todos

[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