On Fri, 10 Aug 2001, Rodrigo Castro Hern�ndez wrote: > Preambulo. > Ok el sistema va a manipular una gran cantidad de cosas como por ejemplo: > Contabilidades, RRHH, planilla, etc ,etc todo lo com�n y corriente y un > poco mas. O.K. Igual ser�a interesante ver cu�l producto es el que usan como medida. S�, por ejemplo, hablan de Oracle - un producto s�per maduro y poderoso - est�n hablando de otro nivel compl�tamente distinto de escalabilidad y funcionalidad del que conseguir�an con postgreSQL. Por otro lado, tambi�n estar�an hablando de un nivel de costos muy diferente. Lo mismo si hablan de DB2. (Y ni qu� decir si en realidad est�n con m�quinas grandes, en vez de micros o minis). Si est�n hablando de Sybase o MS-SQL (�o Informix? No conozco lo suficiente para clasificarlo...), ya est�n m�s cerca de nosotros, aunque todav�a a una escala distinta. Aqu�, si no se habla de funcionalidad ex�tica (bases de datos distribuidas o integraci�n con alg�n producto de escritorio de MS, por ejemplo), posiblemente se podr�a comparar a nivel de costo/beneficio. Si est�n hablando de productos menores, indudablemente podemos comparar postgreSQL con lo que sea y salir adelante en la comparaci�n global de fortalezas y debilidades. > NO vieron en postgres una herramienta optima para el manejar, cambios en > alguna medida dram�ticos en una base de datos en produccion. En una base de datos en producci�n no tiene por qu� haber cambios dram�ticos. Eso se llama un error de dise�o, y no es algo que uno quiera promover en su producto. Esta parece ser la premisa de la mayor�a de sus quejas. Claro, si hubieran hablado de "cambios dram�ticos" en una base de datos en desarrollo, ser�a todav�a m�s rid�culo, porque ser�a un asunto de comodidad, no de optimidad. > Apezar de que hay soluciones para las funciones incompletas o no > implementadas en postgres vieron una debilidad muy fuerte en este sentido. Espec�ficamente �cu�les? Parece que no analizaron beneficios adicionales como que no hay costos de licencias, que se pueden integrar programas completos directamente a la BDD y ese tipo de cosas. > Me hicieron la consulta sobre rendimiento y manifeste mi preocupaci�n en > cuanto al desempe�o , claro que es una lastima que Jaime no haya tenido el > chance de correr las evaluciones en este sentido, para tener una base > t�cnica y cient�fica concreta. L�stima. Este es uno de los puntos m�s importantes. Definitivamente postgreSQL no es la base de datos m�s r�pida de todas, ni mucho menos, pero tampoco es mala. De igual manera, se debe tener una idea clara de la clase de rendimiento que se necesita: comprar Oracle "porque es m�s r�pido" para luego tener dos o tres tablitas de cien registros es como meter un clavo con una bola para demoler edificios. El punto es que una base de datos m�s r�pida vale la diferencia de costo s�lo si se requiere la rapidez/escalabilidad/lo que sea. > Aparte la constancia no parece ser una de > las cualidades de postgres en este sentido.[2] �Constancia? �Huh? Adem�s, falt� la referencia :P > Tiene limities en el manejo de los constraints a la hora de darles un drop > especificamente a ellos Dise�o, a mi gusto. > No es Sql92 estandar o no cumple con sus especificaciones en algunas > areas de importancia como el create > table, el drop que mencionane anteriormente y asi varias. Lo cierto es que todas las BDD comerciales tienen inconsistencias con SQL92 (adem�s de un mont�n de extensiones propietarias). Por supuesto es triste cuando se limita la funcionalidad, pero se debe evaluar son cu�les funciones se requieren para el proyecto en particular. Si el costo de usar otra base de datos es mayor que el costo de arreglar o circumvenir las limitaciones espec�ficas de postgres, sigue siendo una buena opci�n. > Punto importante , el manejo de los object large es evidentemente > incomodo, les mostre el procedimiento de backup que llevamos , y es obvio > que aunque es funcional se presta para cometer errores. �Cu�l usar�an? �C�mo les gustar�a que fuera? No s� cu�l base de datos lo hace, por si misma, mejor que postgres. Cierto que varias bases de datos tienen interfaces bonitas para manejar BLOBs, pero esto no hace la BDD inherentemente mejor. La funcionalidad de las herramientas asociadas es parte de lo que uno eval�a a la hora de escoger un DBMS y es, probablemente, uno de los puntos en los que se est� m�s atrasado. > Grant no se puede dar permiso a columnas. Pero s� se puede crear una vista con s�lo las columnas necesarias y hacer el grant sobre esa vista. Con el sistema de reglas (que es espec�fico a postgreSQL) es m�s f�cil lograrlo y, en un futuro muy cercano, va a ser completamente transparente. (i.e. table.column todav�a no est� soportado directamente en CREATE RULE, pero no falta mucho para que lo est�). > El enfoque de la bd es mas tirado a lo tecnico, universitario y no al > negocio cosa que no lo hace malo pero si importante. Completamente de acuerdo, pero esto no significa que no est� preparado para muchas de las situaciones en las que la gente opta por un producto comercial "porque lo conozco"||"porque est� probado"||"porque lo barato sale caro". > Luego Postgres tiene muchas cosas muy tuanis que realmente compensan esas > cosillas raras que no se resuelven con RTFM (Read The Facinant Manual) :-D Cada herramienta en su nicho. Saludos, -alf -- �Desea desuscribirse? Escriba a [EMAIL PROTECTED] con el tema "unsubscribe".
