Re: OT Ficheros o BBDD

On 9/28/06, tomcask o_o <tomcask(at)gmail(dot)com> wrote:
> Hola a todos, puede ser que esto sea un off-topic.
>
> A ver quiero implementar un sistema de gestion de ficheros html para una web
> rollo cacheado y todo eso mi principal duda consiste en:
>
> Que merece mas la pena servir las peticiones de los usuarios a traves de
> ficheros .html, que son actualizados cada x tiempo segun los contenidos de
> la BBDD, o directamente traer los contenidos de la BBDD.
>
> Ya se que lo normal seria grabar los contenidos en la bbdd y a traves de un
> lenguaje de servidor montarlo y escupirlo todo, pero estoy dandole vueltas a
> la cabeza sobre un sistema de cacheo y me parece que seria mucho mas potente
> utilizar ficheros estaticos y en el servidor correr unos programitas que
> cada cierto tiempo se dediquen a editar los ficheros que hayan sido
> modificados leyendo los cambios de una bbdd.
>

me parece que quieres buscarle 5 patas al gato...

> Que os parece? ser compasivos por favor....
>
> Por cierto otra duda postgre puede ser suficientemente rapida para proyectos
> web, he leido por ahi que es un poco lenta, pero teniendo en cuenta que una
> web con acceso a bbdd bien programada no tendria que escupir un peso maximo
> en de unos 30KB( como muchisimoooo), me parecen pocos datos y creo que
> postgre debe ser igual que mysql no?
>

hace 5 años atras era un hecho reconocido que MySQL era mas rapido que
postgres (al menos si usas tablas MyISAM), la razon era que las tablas
MyISAM no soportan transacciones es decir que si ejecutabas ROLLBACK
los datos que hubieras insertado en la transaccion no desaparecen de
hecho no tienen ningun tipo de mecanismo de seguridad contra fallos
(por lo tanto no usaba tiempo en asegurar los datos)... tampoco
soportan FOREING KEYs asi que tampoco revisaba la integridad
referencial de los datos... es decir que un insert solo hacia insert y
un update solo update... para colmo no soportaba subconsultas, vistas,
triggers no otras maravillas asi que los SELECTs debian ser siempre
simples, no podias hacer consultas muy complejas... obvio que era
mucho mas rapido y simplista...

si usas tablas INNODB en cambio el rendimiento era muy similar a
postgres en cuanto a INSERT, UPDATE, DELETE... en cuanto a los SELECTs
aun era igual de simplista...

hoy en dia MySQL ya soporta subselects, vistas y alguna forma simple
de triggers... y hoy en dia la rapidez de MySQL es solo historica (si
usas tablas MyISAM aun obtienes rapidez pero no te lo aconsejo si
quieres tus datos)... ya no hay nadie, que sea objetivo por supuesto,
que diga que MySQL es mas rapido sino quiza igual o mas lento que
postgres...

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook