Gracias Hernán y a todos los demás por la información super rica y experiencias. La verdad, recién me inscribo, pero según parece esta lista está buenísima. Hay mucha mas gente de la que me imaginaba, buena onda y experiencia. Según parece, muchos aca usan Dolphin y VisualWorks. ¿Los usan en ambientes laborales? ¿nadie se animó con el Squeak? ¿es peor en que aspectos? ¿Dolphin, funciona sólo en Windows? si es asi, esto ya lo descarta de mi horizonte. Saludos y gracias nuevamente.
r. On 8/7/06, Hernán Galante <[EMAIL PROTECTED]> wrote: > > Hola, > Hace un buen tiempo que trabajo con Gemstone/S, con lo cual > puedo contar algunas experiencias. Nunca he usado un esquema tipo > Omnibase ni otro esquema de persistencia pasivo en forma comercial y por > bastante tiempo, con lo cual me limito a opinar sobre Gemstone/S. > El trabajo es muy diferente a usar una base SQL. El trabajar con > objetos no es fácil de entender y a mucha gente le deja más tranquila > hacer un SQL y ver sus datos ahi tranquilitos, sin que ninguna magia de > GC se los vuele :-) > Una cosa es que en un esquema de objeto JAMAS tenés un join > largo, si pasa esto es porque se está violando la encapsulación de los > objetos del modelo en algún lugar o falta que otros objetos se conozcan > entre si, etc. > No me imagino otra manera de poder escribir una consulta en > Smalltalk larga. > Los problemas que podés encontrar en un esquema de persistencia > con objetos son: > > a) Congestión de la red. Traerse los objetos al cliente y el > problema que ocasiona que los objetos viajen por la red. Entonces tenés > mecanismos de proxies que ayudan a que solo viaje lo estrictamente > necesario. > > b) Espacio en disco. Generalmente crecen mucho con la actividad > de las transacciones, se crea mucha basura que luego es actividad del > GC, los extents se agrandan y la única manera de bajar el espacio > ocupado en disco por los extents de una base es un Backup/Restore. Esto > es por la arquitectura multigeneracional que usan. El único motor SQL > que sabía que era multigeneracional era Interbase, y también se > resolvían muchos problemas de la misma manera que en Gemstone (Sweep + > B/R). > > c) Actividad del GC. Cuando hay mucha actividad en la base se > genera mucha basura, esta cantidad de basura genera mucha actividad del > GC. Como sabemos un GC es un proceso de mucho stress en el ambiente con > lo cual puede tirar abajo la performance. Para evitar esto hay muchas > técnicas, por ejemplo, Gemstone/S tiene 5 tipos diferentes de GC, que > ayudanm a aliviar esta actividad. También hay otra técnica en la se > puede desactivar el GC, a costo de consumir disco, y en una base espejo > paralela ir corriendo en GC, marcar los OOP de los objetos que van a > morir y luego correrla (en horarios con menos actividad) sobre la base > productiva. > > Como se ve, hay muchas cosas por las que preocuparse en una BO, > y ninguna tiene que ver con los problemas que se sucitan en un motor > SQL. > Con respecto a lo que decía Ramiro, seguramente se refiere al > punto a), traerte todo la colección de objetos persistentes al cliente > para luego consultarlo y quedarte con uno, es una locura. Si la red es > local, quizás ni se note, pero si es Wan puede ser que tarde siglos en > moverse, y es lógico. Lo que el menciona sería un remotePerform: en la > base. Esto lo provee Gemstone/S, o la otra solución es traer proxies, y > que estos a medida que vas consultando vaya trayendo de manera onDemand > lo que requiere. Hay varias técnicas de resolución. > > Saludos, > Hernán.- > > Pd. Es un tema muy interesante :-) > > -----Mensaje original----- > De: [email protected] > [mailto:[EMAIL PROTECTED] En nombre de Ramiro Diaz Trepat > Enviado el: Lunes, 07 de Agosto de 2006 09:27 a.m. > Para: [email protected] > Asunto: [clubSmalltalk] Re: OmniBase > > > On 8/7/06, GallegO <[EMAIL PROTECTED]> wrote: > > > > Bruno BB (st) escribió: > > > Lo que tenes que tener cuidado es que un ODBMS no es una RDBMS, y se > > > trabaja de forma diferente. > Si, pero el lenguaje de query sigue siendo necesario, al menos algo como > el que está proponiendo Magma. En vez de navegar todo desde un root > Dictionary. > Por más que sea un modelo de objetos, siempre que necesites hacer > consultas complejas que involucren varios joins de mucho volumen, vas a > tener que hacerlas con un lenguaje de consulta (aunque no sea SQL) para > que las resuelva el motor de base de datos y no las resuelvas vos a > nivel de lenguaje con #collect, #select, etc. Lo que sería -creo- muy > ineficiente. > Me alegro de escuchar que OmniBase le anduvo muy bien a mucha gente. La > última vez que lo probé sobre Squeak/Linux tenía un problema de locks > que aún no habían resuelto. Pero escuchando todos estos comentarios > favorables, voy a volver a probarla. > Pero por ahora, me inclino por Magma por que le están dando bola a la > forma de hacer consultas. > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk. -~----------~----~----~----~------~----~------~--~---
