Rendimiento de la Programación Orientada a Objetos (POO)

Hola,

Mantengo un portal web de un gran volúmen de visitas y bastante movimiento en cuanto a peticiones MySQL (unas 300 por segundo) y demomento está programado para PHP4.

Bien, se me ha metido en la cabeza hacer la versión dos del portal con PHP5 y Programación orientada a Objetos, he empezado a ello y me surje un problema base que no me deja dormir (pesadillas y sudores por la noche)...

Actualmente tengo algo parecido a:

1. Conecta a la BD.
2. Dame campo1, campo2, campo3 de las 10 últimas noticias.
3. Pinta campo1, campo2 y campo3 en un bucle.
4. Libera acceso a la BD.

Y cuando iba a mudar el módulo de noticias a la orientación de objetos me encuentro con un problema... ¿Cómo lo hago?

1. Un objeto, Varias SQL: En el objeto noticia creo un método que devuelva identificadores de noticias y posteriormente recorro ese array de identificadores para volver a hacer una consulta a la MySQL para obtener esos valores y recojer los atributos de mi objeto noticia.
2. Una SQL, Varios objetos: En el objeto noticia creo un método capaz de sacar un listado de noticia con todos los campos que necesite e instancie un objeto noticia para cada registro de la BD devuelvo.

¿Qué implica decidirse por uno o por otro? Pues mucho! Puesto que en estos momentos, por cada visitante se ejecuta una sola sentencia SQL para sacar un listado de noticias con sus campos, pero migrar el sistema a POO implica ejecutar muchas más sentencias o bien crear tantos objetos en memoria como noticias haya.

¿Qué me recomiendan?

Haber...

Migrar a OOP no incrementa las llamadas a SQL ni las reduce. Eso va en función de tu lógica. Las llamadas a la DB reducelas lo mas que sea posible, pero también debes cuidar de no traerte información innecesaria.

Cada llamada a la BD gasta un ligero porcentaje de CPU(dependiendo de la complejidad del proceso), la información que mantengas gasta RAM. So tienes que ser equilibrado y analizar bien que información necesitas en que momento.

Ahora que si quieres optimizar aun mas esto, mysql tiene una opción para guardar en CACHE los SQLs mas complejos.
http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

Gracias por tu respuesta, pero todo eso ya lo sé. Sé que existe el query caché y, lógicamente, no voy a incrementar más consultas SQL si no las necesito, hay que optimizar, eso está claro, pero en el caso que he comentado más arriba... ¿cómo lo solucionarías tu? ¿cómo esos métodos del objeto noticia, un getAllNews que devuelva sólo un array de identificadores para luego recorrerlo y hacer una consulta de título, texto y más campos para cada identificador? (lo que supone multiplicar las sentencias: 1 devuelve los identificadores y 1 por cada identificador)

Si yo tengo 10 noticias en la base de datos, a esa manera de hacer, para listarlas realizo 11 consultas a la base de datos con la POO.

Un saludo.

Yo haría algo similar a tu opción 2.


Recuerda que la clase que tiene el método getAll, puede ser Noticia y la instancia de cada noticia(un row de bd) podria ser otra clase llamada EntidadNoticia.

Saludos

Entonces, tú, en vez de consumir recursos de la base de datos... ¿consumirías memoria del servidor? ya que entiendo que cada objeto creado consume su parte de memoria... ¿si tengo 1000 noticias crearé 1000 objetos EntidadNoticia en memoria? La aplicación sería todo lo potente que yo quiera, sí, pero también necesita un servidor dedicado para correr y parte de otro!

Yo he estado realizando pruebas y en cuanto a tiempo de respuesta, es más veloz peticionar la SQL que crear los objetos, que a su vez consume más memoria, pero lo veo exagerado.

Pero bueno, al fin y al cabo esa es la cuestión... Para 1000 noticias, o 1001 SQL (tal y como lo he explicado arriba), o 1000 objetos en memoria, hagan sus apuestas!

Es usable mostrar mil noticias en una página? yo creo que no. Yo mira para los listados uso una clase DataSet de un framework propio. Con mi dataset, convierte el bd resource en Array y así lo muestro. Tu si solo quieres listarlos no los conviertas a Entity solo muestralos y ya. Generalmente los entity los usas para operaciones de CRUD.