Maxi, Te aseguro que no nos castiga. Disfruta hacer las cosas de esa manera sin pensar en las técnicas que se diseñaron específicamente para aprovechar las bases de datos relacionales. .
En fin, mas allá de los chistes de la frase anterior, creo que cuando las bases de datos orientadas a objetos sean una realidad cotidiana (y obviamente sirvan para algo mas que solo unos pocos datos) podre aceptar la idea de Carlos de solo diseñar desde las condiciones funcionales. No discuto obviamente el diseño de las aplicaciones pero si el de las base de datos RELACIONALES que para mi no son una consecuencia sino parte del eje de diseño.. Es mas, voy a arriesgar una opinión, no creo que nunca las bases de datos orientadas a objetos tengan el 10% del éxito de las bases relacionales y en cambio se va a llegar a bases de datos con un intermedio entre ambas. Creo que lo mejor siempre es aprovechar las técnicas que te hacen sentir mas seguro a la hora de diseñar.. La suerte que tenemos es que debido a que no toman en cuanta estos detalles al diseñar es que tenemos mucho trabajo. Saludos -- -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting On 10/26/07, Maxi accotto <[EMAIL PROTECTED]> wrote: > > Jaja, como te gusta castigarnos J > > > > ----------------------------------------------------------- > > Microsoft MVP en SQL Server > > Mentor asociado en SQLTotalConsulting > > Excelencia en servicios y consultoria SQLServer > > www.sqltotalconsulting.com > > ----------------------------------------------------------- > > > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Carlos Peix > *Enviado el:* viernes, 26 de octubre de 2007 11:57 a.m. > *Para:* Maxi > *Asunto:* [dbms] RE: [dbms] Diseño de Base de Datos > > > > Otra sugerencia? > > > > Si, olvidate (relativamente) de la base de datos hasta que necesites > persistir, normalmente diseñas mas libremente en estos casos, salvo el caso > de Maxi o Mariano donde ya el daño cerebral es severo e irreversible :-)))) > > > > OUCH!!!, esta era la lista de base de datos, no la de DDD :-)... > > > > Carlos Peix > > > > ------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Pablo > Maximo Mazzitelli > *Sent:* Viernes, 26 de Octubre de 2007 11:24 a.m. > *To:* [EMAIL PROTECTED] > *Subject:* [dbms] Diseño de Base de Datos > > Carlos, acabo de darle una vista general al articulo que me pasaste y > realmente es lo que necesitaba. Lo mio esta orientado hacia la aplicacion > pero tambien necesitaba saber la estructura ideal para soportar un historial > de los datos. Te lo agradezco realmente. > > > > Cualquier otra sugerencia mas es bienvenida. > > > > Saludos y Gracias > > *Carlos Peix <[EMAIL PROTECTED]>* escribió: > > Hola Pablo, > > > > La opcion que te paso Maxi es una posibilidad, sin embargo hay varias, > dependiendo de lo que necesites en tu aplicacion. La propuesta de Maxi es lo > que se llama un Audit Log, esta orientado a registrar todo cambio producido > en cierta estructura de datos. Lo mas normal es que tambien se registre el > usuario que realizo la modificacion y la fecha y hora. > > > > Aqui tenes un catalogo mas amplio de las posibilidades, esta visto desde > el punto de vista de la aplicacion mas que desde la base de datos (no podia > ser de otra manera en un post mio :-) ) pero seguramente te va a servir. > > > > http://martinfowler.com/ap2/timeNarrative.html (en ingles) > > > > Carlos Peix > > ------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Pablo > Maximo Mazzitelli > *Sent:* Jueves, 25 de Octubre de 2007 09:59 p.m. > *To:* [EMAIL PROTECTED] > *Subject:* [dbms] [dbms] Diseño de Base de Datos > > Amigos, > > > > Estoy dando mis primeros pasos en el diseño de base de datos y me encontré > con el siguiente problema a resolver. > > Se trata de una tabla que guarda ciertos datos de clubes como ser Nombre, > Ciudad, Provincia pero que además almacena Dirección del Club, Teléfono, > etc. La intención es que la base de datos y en particular la tabla guarde > los datos actuales pero además datos históricos. Es decir, que hoy puedo > tener la dirección y teléfono del club pero también tener la posibilidad de > saber cual era la dirección y el teléfono del mismo club 2 temporadas atrás. > > > > Mi pregunta seria saber que es recomendable para armar tablas que guarden > datos históricos. La opción que manejo son crear una tabla para aquellos > datos fijos tales como el Nombre, Ciudad, Provincia y otra con aquellos > datos que sean variables entre años distintos como Dirección, teléfono y > adosarle un campo donde se establece la fecha o temporada de modificación > junto con el id de asociación del club correspondiente. > > > > Alguien puede decirme si esto es correcto o existe alguna idea mejor?. Es > importante aclarar que mi idea es usar esta base de datos en una aplicación > que haga alta, baja y modificación pero que permita ver valores de años > anteriores. > > > > Desde ya les agradezco la ayuda de antemano. > > > > > > __________ Información de NOD32, revisión 2619 (20071026) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > > > ------------------------------ > > > El Mundial de Rugby 2007 > Las últimas noticias en Yahoo! Deportes: > http://ar.sports.yahoo.com/mundialderugby > >
