^TiFa^, no entiendo entonces porque dices que SQLite tiene problemas de seguridad. Es un archivo binario en servidor que tan siquiera es accesible por url. Lo pregunto porque no había oído antes críticas en ese sentido y me dejas preocupadx. Es cierto que habías dicho que era binario, no te había entendido.

Por otro lado, con lo de una docena me refería a personas leyendo el modelo, no escribiendo en él. En la mayoría de esos proyectos, con la notable excepción de las wikis, solo la administración va a escribir en el modelo, así que no hay colisiones. E incluso en el caso de las wikis, las probabilidades de que se creen colas de escritura de más de 2 personas son bajas, más de 3 ínfimas.

Por otro lado, tengo entendido que el consumo de MySQL no es tan bajo, piensa que esta disusión sería tonta si habláramos de ordenadores medianamente actuales, pero te hablo de Pentium I y alguna vez hasta de algo más antiguo que no apetece tirar.

Nakp, no tendrás datos que lo confirmen no? Precisamente me quiero evitar hacer yo mismx el benchmarking, porque me quitaría mucho tiempo.

Los proyectos "no pueden crecer" porque si pudieran hacerlo ya no los hospedaría en esos servidores y por lo tanto ya no usarían esos CMS.

El caso es que no va a haber cientos de usuarios conectándose a la base de datos simultáneamente, van a ser proyectos de enfoque local en los que mayormente solo la administración modificará el modelo y las consultas simultáneas a este rara vez superarán la docena.

Como puedes ver son cosas pequeñas (como la mayoría de blogs que hay por ahí y usan mysql, dicho sea de paso) así que creo que poner el límite en sqlite no es descabellado. Ya me dirás que opinas.

Es más, lo que yo me preguntaba es si habría una ganancia de rendimiento si, en ocasiones, decidiera usar un modelo de datos flat-file en lugar de sqlite. Quiero saber hasta que punto podría llegar a valer la pena.

Por otro lado, SQLite no usa un archivo de texto plano (flat-file) como me parece entender que sugieres, sino un binario. Prueba a abrir con un editor de textos.

No lo pases por dirección (GET) sino por POST. al form le pones method="POST" en lugar de method="GET" y en el otro php en lugar de acceder a las variables mediante $_GET["nombre"] hazlo con $_POST["nombre"].

La idea es usar hardware obsoleto como servidores web, así que el cuello de botella se encuentra en la potencia de ese hardware. Por lo tanto lo que quiero no es decidir de que manera almaceno los datos en función de como van a crecer los proyectos sinó crear CMS's muy ligeros que se adapten a la poca potencia del hardware para que los proyectos sean los que se adapten. No se si me estoy explicando, jeje.

Entonces lo que busco es la manera de diseñar una manera de almacenar datos lo más ligera posible siempre teniendo en cuenta que limitaciones tiene eso (gestión de colisiones, poca escalabilidad, etc). Tal vez me he precipitado mucho al decir que la mejor opción era una flat-file database (concepto que excluye a SQLite, porque me refería a esto).

La cosa es que normalmente el hardware nunca es un problema. Si algo es poco eficiente se compra hardware mejor y listos. Se priorizan otras cosas. Por eso no se suele tener en cuenta que MySQL y otras maneras de almacenar datos son bastante pesadas para según que hardware antiguo, y a veces realmente innecesarias. SQLite funciona muy bien en proyectos medianos, y fuera del mundo empresarial casi todos los proyectos son a lo sumo medianos!

La pregunta entonces sería: Hasta que punto SQLite es ligero? Es casi tan ligero como usar un triste archivo xml? Porque claro, si es tan ligero tal vez no vale la pena que me complique la vida con las limitadas flat-file database.

Hola, como ya comenté en otro hilo, estoy recopilando información, consejos e ideas para conseguir resucitar hardware obsoleto de ese que con tanta facilidad se encuentra al lado de contenedores y usarlo como servidor web. Sin embargo, en el fin de conseguir que todo sea lo más ligero posible no solo interviene el software de servidor sino también la manera en la que están diseñados los sitios hospedados.

Así que de paso voy a diseñar algún que otro CMS muy ligero y muy sencillo pensado específicamente para estar hospedado en estos servidores.

En lo que a almacenamiento de datos se refiere, pienso que en muchas ocasiones puede resultar interesante usar "bases de datos" en archivos planos (flat-file) (en casos en los que la base de datos tenga más uso ya será mejor ir a por sqlite).

El objetivo final es la eficiencia, y una pésima gestión del modelo de datos me la echaría al traste. Me gustaría saber si alguien me podría dar consejos para diseñar todo lo que sería el convenio que podría seguir para almacenar datos en archivos, si me recomendáis que use XML, y sino, como parseo los datos de la forma más ligera posible. Truquillos, ideas y consejos para hacerlo todo más eficiente vamos.

Un saludo y muchas gracias.

Muy interesante, porque precisamente lo que me trae un poco de cabeza es que en algunos benchmark dejan en mejor lugar a PHP4 pero son comparativas hechas con el mismo código. Sospecho, y cosas como estas hacen que crezca mi sospecha, que aprovechando todo el potencial de PHP5 tal vez esas comparativas cambien.

Por cierto, algún motivo relacionado con la eficiencia para usar SMF1 en lugar de SMF2?

Gracias por la ayuda.

Hola, estoy trabajando en recuperar ordenadores obsoletos y usarlos como servidores optimizando sus recursos. Por ello quería saber de alguna comparativa de rendimiento entre PHP4 y PHP5 que tenga en cuenta las características y particularidades de ambas versiones, pues no me importa adaptarme a cierta manera de programar si resulta más eficiente.

Me son útiles tanto enlaces, datos que recopiléis vosotrxs mismxs e incluso experiencias personales. Cualquier consejo es bien recibido.

Saludos y muchas gracias.