El vie, 18-05-2007 a las 17:59 -0300, Alvaro escribió: > Roberto C. Sánchez escribió: > > On Fri, May 18, 2007 at 02:49:03PM -0300, Alvaro wrote: > > > >>> > >>> > >> No entiendo bien a que te refieres, dices que no funcionan los triggers, > >> vistas, reglas y solo consultas SQL usando PDO?
No es eso, hiciste el comentario de que con PDO, /sólo con cambiar el constructor/ una aplicación para PostgreSQL iría en MySQL, Oracle, ... Lo que quería decir es que una cosa es que la librería soporte varios backends de forma transparente, y otra cosa muy distinta es que sólo con eso una aplicación pueda funcionar sin cambios (sólo en el constructor) en todos los sistemas que soporte la librería. Ya que para que esto funcionase, todos los SGBDs tendrían que hablar el mismo idioma (o tendrías que restringirte al subconjunto que entiendan todos), y aunque lo hablasen, no siempre lo interpretan igual: http://sql-info.de/mysql/gotchas.html http://sql-info.de/postgresql/postgres-gotchas.html Y si buscas un poco encontraras otras para cualquier otro SGBD. En resumen, no todos los SGBDs hablan el mismo idioma, ni lo interpretan igual, ni todos los optimizadores son iguales. Además, todos tienen extensiones con las que seguramente obtendrás un mejor rendimiento y/o un desarrollo más sencillo. Y si empezamos a meternos con niveles de aislamiento, tablas no transaccionales como las MyISAM, pero que puedes usarlas en "transacciones" (sí, se atreven a llamarlo así) junto con otras tablas transaccionales obteniendo unos "exóticos" resultados en caso de abortar la transacción, ... vamos que hay infinidad de niveles a los que discutir esto, y habrá también infinidad de opiniones, la mía es que el rendimiento de una BD es algo a maximizar, no se debe sacrificar por nada, y si necesitas portabilidad la programas explícitamente. Por supuesto, hablando para aplicaciones medianamente serias, para cosas simples todo esto es irrelevante. > >> De que manera el desarrollo y el depurado se hacen más simples sin usar > >> PDO? Me has entendido mal, son más simples si no te limitas por la ilusión de la portabilidad, y programas todo lo que se pueda en el SGBD. En el caso particular de postgres (últimamente no uso otra cosa), en la mayoría de aplicaciones, el 90% del código SQL puedes tenerlo en la propia BD, en funciones SQL, PL/pgSQL, vistas y triggers. El desarrollo de esto lo haces directamente en la BD, y puedes validarlo de forma sencilla desde el terminal interactivo (psql). Si esto se programase "a pelo" en el lenguaje de programación que se vaya a usar, validar la capa de acceso a datos no será tan trivial, y el rendimiento siempre será inferior. > > Yo creo que lo que dice es que si una se impone la limitación de usar > > solamente consultas SQL, sin triggers, vistas y lo de mas, que uno puede > > usar PDO. Pero, si uno quiere usar las herramientas mas potentes > > (triggers, vistas, &c.) entonces se te va complicar mucho tratar de > > hacerlo de una forma que se puede portar fácilmente de una plataforma a > > la otra. Eso era Roberto, supongo que me podría haber ahorrado este tocho, bastante OT para esta lista, pero ya que lo he escrito ahí va ;) > Tendría que responder Eduardo, pero suponiendo que eso quizo decir... > Yo no tengo un gran conocimiento de bases de datos, pero tengo entendido > que los triggers, vistas, etc. son programados con scripts sql, no entiendo > que rol cumple un driver de abstracción de bases de datos sobre estos temas. No es eso, obviamente a PDO le da lo mismo lo que soporte tu SGBD, pero si tu delegas parte de la programación/validación a triggers y demás, si quieres poder utilizar varios SGBDs y alguno no soporta esto, pues no vas a poder usarlo (no por PDO, sino porque no será portable). > Por otra parte me tome la molestia de ver la documentación de php5 sobre el > driver NO PDO de pgsql y no vi ninguna función que haga referencia al manejo > de triggers etc. Los triggers se usan internamente, los dispara el SGBD cuando se produce el evento seleccionado. No se invocan desde un lenguaje de programación. http://www.postgresql.org/docs/8.2/interactive/trigger-definition.html http://www.postgresql.org/docs/8.2/interactive/sql-createtrigger.html > Asi que por lo pronto en PHP no perdemos funcionalidad > en usar > PDO sino que la incrementamos. Personalmente lo que más me preocupa cuando trabajo con BDs es la eficiencia (sí, soy un poco paranoico en esto ;). Aunque la verdad es que desconozco la diferencia de rendimiento entre ambos. Suelo usar pqxx en C++ ;) > Creo que el error radica en utilizar un driver especifico, o abstracto > de base de > datos para crear la base de datos y crear las tablas etc. Me parece lo > mas coherente > elaborar scripts de creación de tablas, triggers, drops, vistas, > secuencias en ANSI SQL92 > o SLQ99, de esta forma el script sería portable a un monton de bases de > datos profesionales y la gestión de las mismas transparente al driver > que utilizamos. No hago más que repetirme, pero lo diré una vez más, IMHO, eso no es más que una falacia, el desarrollo así puede parecer muy portable, hasta que empieces a usar otro SGBD. En ese momento te darás cuenta de que has sacrificado funcionalidad en la BD, para conseguir una portabilidad mediocre. Aunque como todo en este mundo, para gustos colores. En fin, que lo que critiqué no fue PDO, sino tu feliz e inocente visión de la portabilidad. PDO ayuda al ofrecer un API unificada, pero para obtener una portabilidad real, eficiente y sin sorpresas, se debe realizar una capa de acceso a datos, y especializarla por cada SGBD que se pretenda utilizar. De hecho, encontrarás muchas aplicaciones serias con componentes especializados para cada SGBD. Por ejemplo Bacula: # apt-cache search bacula-director bacula-director-common - Network backup, recovery and verification (Director common files) bacula-director-mysql - Network backup, recovery and verification (Director daemon) bacula-director-pgsql - Network backup, recovery and verification (Director daemon) bacula-director-sqlite - Network backup, recovery and verification (Director daemon) bacula-director-sqlite3 - Network backup, recovery and verification (Director daemon) Espero haber sido ahora más claro, de lo que no me cabe duda es de que sí he sido más pesado ;) Un saludo, Edu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
