Hola Mariano, Gracias por seguir la discusion.
Creo que no me explique correctamente. En el caso que planteo Pablo, tendrias una colección de direcciones con su correspndiente periodo de validez (fecha desde hasta) y la ultima direccion tendria un rango abierto en su extremo superior, esto es, la FechaHasta de validez de la direccion con valor null o con valor MaxDate (prefiero lo primero). La desnormalizacion que yo hago (cuando la evidencia demuestra que es encesaria) es dejar una referencia a la direccion activa en el objeto principal (ademas de la coleccion). Esto, en terminos de la base de datos, significa que la tabla Clientes tendira una columna que se llamaria IdDireccionActual, una FK a la tabla de direcciones. Probablemente esta columna tendria un indice. La ventaja de esta optimizacion es que puede hacerse si alterar la interfaz del objeto Cliente. Habias entendido esto? Por otro lado y creo que fuera del ambito de este thread esta el caso donde se procesa logica en el query, por ejemplo, validar los mil registros que vos mencionas contra los datos del cliente. Esto es otra cosa distinta. Yo no hago esto en un SP, aunque reconozco que la velocidad de proceso puede ser muy superior. Hay un thread que mantuvimos con Maxi en el 2004 por este tema, con ejemplos de codigo (de el y mios), como siempre en casos de arquitectura, con soluciones validas pero con final abierto, dependiendo de lo que priorice cada uno :). Carlos Peix > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of > Jose Mariano Alvarez > Sent: Lunes, 29 de Octubre de 2007 01:08 p.m. > To: [EMAIL PROTECTED] > Subject: [dbms] Re: [dbms] Diseño de Base de Datos > > 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 > > > > > > > > __________ Información de NOD32, revisión 2623 (20071029) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > >
