Hola gente
--- El jue 18-sep-08, Gunnar Wolf <[EMAIL PROTECTED]> escribió: > De: Gunnar Wolf <[EMAIL PROTECTED]> > Asunto: Re: [pgsql-es-ayuda] Hola > Para: "marcelo Cortez" <[EMAIL PROTECTED]> > Cc: pgsql-es-ayuda@postgresql.org, "Danier Marante Jacas" <[EMAIL PROTECTED]> > Fecha: jueves, 18 de septiembre de 2008, 1:50 pm > marcelo Cortez dijo [Wed, Sep 17, 2008 at 10:33:15AM -0700]: > > Hola > > > > Para mi el tema de las bases de datos de objetos y los > otros metodos de mapear objetos tiene un eje de diferencia > muy grande y conceptual > > que termina siendo por donde pasa todo. la identidad. > > En el paradigmade objetos esta asegurada la identidad > todo objeto es identico a si mismo y esa identidad es > unica,( perdon por la redundancia). > > (...) > > la diferencia entre mapear en una base de objetos y > una base relacional es como si por ejemplo , > > todas las mañanas tomara mi auto para ir al trabajo y > luego al llegar a casa lo desarmo todo en cajitas numeradas > y a la mañana siguiente lo volviera a ensamblar y asi ... > siempre ... > > Volviendo al tema , creo que el pivot esta en la > identidad. > > No exactamente. Todo objeto en un lenguaje limpiamente OO > tiene > también un ID. Veamos el siguiente ejemplo, en Ruby Si pero yo me referia a que en una base de objetos no hace falta ni tiene sentido un id. dije bien , no tiene el menor sentido. pero claro eso es dificil de digerir :( . Lo que pasa es que los que conocemos como objetos en verdad son aproximaciones, en objetos verdaderos deberiamos hacermos la pregunta, de que clase seria el id ?.. Tampoco tienen sentido las validaciones, porque? tengo un combobox o cualquier otra forma de presentacion de la informacion, por ejemplo seleccione una calle ... Cuando eligen una y me devuelve el "resultado" lo que obtengo es una calle. no un string. que sentido tiene preguntar ,,, es una callle? tiene altura? que localidad? no lo tiene porque YA ES .., es una calle. del mismo modo los objetos no disponen de un campo id. en los ambientes de objetos los objetos no exponen su "id" lo tienen dentro de ellos es posible preguntar por algo "similar" al id pero en gral tiene poco sentido. salvo en casos muy particulares y para las bases donde estos objetos se guardan no , no necesitan eso. en las bases relacionales o sistemas de mapeos la UNICA manera de que no se desarme todo es usar el id , tiene un costo.. Hay que administrarlo.. para mi esto responde mas a razones historicas que verdaderas necesidades, en verdad crean mas problemas de los que solucionan OJO hablo del punto de vista de los objetos mapeos y bases de objetos ... desde este punto de vista lo digo. Grandes problemas de ingenieria trae aparejado esto , y vuelvo a repetir en objetos.. Para saber si hablamos de lo mismo cuando hablamos de objetos deberiamos ser capaces de responder estas sencillas preguntas todas afirmativamente para poder decir .. SI! es de objetos.. a) es la clase un objeto ? b) son los procesos un objeto? c) son los numeros objetos? d) son todos objetos?? a) es re importante pero no me extendere sobbre ello. b) c) son solo ejemplos de d) que es el meollo de la situacion. leer d) pero afirmando , SI SON TODOS OBJETOS!! si responde a todo eso si Congratulaciones !!!! ud si esta hablando de objetos!!! :) saludos a todos mdc para los amantes de los links http://en.wikipedia.org/wiki/Gemstone_Database_Management_System http://workshop99.ircache.net/Papers/rodriguez-abstract.html > (estoy usando la > consola interactiva, irb): > > Vamos a crear dos objetos con información aparentemente > idéntica: > > >> cadena1 = "una cadena" > => "una cadena" > >> cadena2 = "una cadena" > => "una cadena" > > Verificamos si, a nivel comparación, son iguales: > > >> cadena1 == cadena2 > => true > > Y vemos sus respectivos IDs: > > >> cadena1.object_id > => 69996972347440 > >> cadena2.object_id > => 69996972340800 > > Entonces, claramente, estos dos objetos son iguales, mas no > son el > mismo objeto. > > ¿Cómo puedo hablar de lo mismo en un modelo > relacional como el de > PostgreSQL? > > Voy a crear una tabla muy sencilla, con solamente una > columna, y > poblarla de datos del mismo modo: > > test=# CREATE TEMP table cadena (datos text); > CREATE TABLE > > solserv_test=# INSERT INTO cadena (datos) VALUES ('una > cadena'); > INSERT 0 1 > solserv_test=# INSERT INTO cadena (datos) VALUES ('una > cadena'); > INSERT 0 1 > > Si consulto esta tabla, tengo -del mismo modo que en el > ejemplo > anterior- dos registros independientes, aunque casualmente > idénticos > (cosa que, obviamente, no quieres ver en una BD de > producción ;-) > > test=# SELECT * from cadena; > datos > ------------ > una cadena > una cadena > (2 rows) > > No me meto en este momento en más detalles - Cada > registro sigue > siendo únic, tiene un identificador interno, tan interno > como el > object_id de Ruby (que en realidad no es muy utilizable > más que para > propósitos demostrativos para el usuario común). > > -- > Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / > 1451-2244 > PGP key 1024D/8BB527AF 2001-10-23 > Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 > 27AF Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/ -- TIP 4: No hagas 'kill -9' a postmaster
