Carlos: Si es así. Coincidimos con eso. En ese caso es eficiente solo si accedes a un registro.
Veamos un ejemplo simple. Supongamos que quieres procesar un conjunto pequeño de datos de digamos 1000 registros de ventas provenientes de una interfaz (algo muy clásico y normal en las empresas) y quieres relacionarlo con los datos de los clientes que justamente es un ejemplo de esta tabla que mantiene la historia donde aplicas ese patrón mediante las fechas desde y hasta y la marca de actual (en tu caso hablaríamos de objetos). Aunque tengas los índices, tienes dos opciones, o debes bajarte todos los datos de clientes a una colección en memoria para accederlo de manera eficiente o haces los 1000 accesos a la tabla que aunque sea por índice es al menos varios órdenes de magnitud más lento. Justamente esto es en términos de bases de datos relacionales un JOIN de dos entidades para lo cual la base de datos es muchísimo mas eficiente. Obviamente esto no tiene sentido considerarlo para una operación individual de acceso a un único registro. Otra cosa importante es que si bien lo que propone Carlos no es lo mejor tampoco es lo peor. Entiendo que es más fácil y eficiente programar y diseñar de la manera que propones pero no es la manera adecuada a mi criterio. La base de datos es uno de los componentes principales de los sistemas y deben ser usados de la manera adecuada. Existen herramientas adecuadas para modelarlas y diseñarlas desde hace muchos años. Cada vez hay más problemas graves con las bases de datos ya que nunca se las considera en los diseños, ni siquiera de la manera en que Carlos la toma en cuanta. Saludos -- -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting On 10/29/07, Carlos Peix <[EMAIL PROTECTED]> wrote: > > > Hola Mariano, > > Perdonen si sigo bajo el mismo thread pero me parece que es util para alguien > (por lo menos para mi lo es :-) ). > > Entiendo que te referis al patrin Effectivity. Un patron parecido y mas > adecuado al caso es Temporal Property, en la definicion de Fowler. De todas > maneras, creo que te referis a la manera de obtener la propiedad actual, cosa > que en la implementacion mas sencilla consiste en obtener la propiedad > efectiva al dia de hoy (obligando a acceder a la coleccion). > > Casi siempre que he utilizado este patron he tenido que desnormalizar el > modelo dejando una referencia persistente a la instancia activa. Esto no ha > sido tanto por la performance del acceso a la propiedad como por el motivo de > hacer un query eficiente. Justo lo que vos mencionas, segun entiendo. > > Entonces, llego a la misma desnormalizacion pero por via diferente. Lo > importante es que en todos los casos, esta desnormalizacion siempre me ha > quedado oculta dentro del objeto en cuestion. > > Espero haber interpretado tu comentario. > > Carlos Peix > > > > ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jose Mariano Alvarez > Sent: Lunes, 29 de Octubre de 2007 09:21 a.m. > To: [EMAIL PROTECTED] > Subject: [dbms] Re: [dbms] Diseño de Base de Datos > > > > Ven carlos, eso es justamente lo que decia. > > Si sigues ese patron al pie de la letra segun Fowler utilizas de manera > ineficiente la base de datos y es muy probable que no puedas usar de manera > adecuada los indices. > > > Saludos > > -- > -------------------------------- > Atte. > Ing. Jose Mariano Alvarez > SQL Total Consulting > > > > > On 10/29/07, Carlos Peix <[EMAIL PROTECTED]> wrote: > > > > > > Hola Pablo, > > > > En mi opinion es clave identificar el motivo por el cual estas generando > > esas copias de la informacion. > > > > Si las estas generando por razones de auditoria, es muy probable que las > > copias no signifiquen nada para la logica de tu aplicacion. Normalmente > > esas copias o versiones de cada fila se consultan con aplicaciones > > especiales de auditoria (que vos mismo construyas). En este caso, lo mas > > comodo es hacerlo con triggers o con stored procedures, yo prefiero los > > triggers y asi lo hago cada vez que tengo esta necesidad. > > > > En cambio, si la copia de la informacion tienen un sentido en tu modelo > > (patron Effectivity por ejemplo), creo que es recomendable implementarlo > > del lado del codigo. > > > > Tambien es cierto que en las aplicaciones que son solo ABMs es dificil ver > > la ventaja de implementar la logica en uno u otro lado, ya que, en general, > > la logica es casi iniexistente. > > > > Por supuesto, estas son mis preferencias. > > > > Carlos Peix > > > > > > > > ________________________________ From: [email protected] [mailto: [EMAIL PROTECTED] On Behalf Of Pablo Maximo Mazzitelli > > Sent: Sábado, 27 de Octubre de 2007 01:35 p.m. > > To: [EMAIL PROTECTED] > > Subject: [dbms] RE: [dbms] RE: [dbms] Diseño de Base de Datos > > > > > > > > > > > > Mmmmm, a ver si entendi… yo tengo una aplicación sencillita. Un panel con > > botones que habilitan a distintos formularios de allta y modificacion. Otro > > tipo de opcion para hacer busquedas. O sea algo basico y estandar. Un > > tipico Alta, Baja, Modificacion y Consulta de datos pero con historial de > > datos. > > > > > > > > No entiendo bien del hecho de olvidarme de la base de datos ya que casi > > toda la aplicación esta basada en ella. O sea estoy casi siempre > > persistiendo. Mi duda vendria en el caso de la opcion de modicacion de > > datos donde tambien estoy persistiendo. > > > > > > > > Podrian abrirme mas la cabeza al respecto? > > > > > > > > Gracias > > > > Pablo > > >
