[OT] Re: Editor de php
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.
Reply to: