mejor rendimiento en el servidor

[1000i1]

Hola,

Estoy haciendo algunas pruebas de OO y me ha surgido una duda. Se trata de un sistema donde los usuarios tiene una lista de objetos. Me han surgido 2 ideas para implementarlo y me pregunto cual me dara mejor rendimiento en el servidor.

Es mi primer intento de hacer un sistema programado en OO y para tener siempre disponible mi objeto usuario lo tengo en $_SESSION['usuario'] lo cual no se si es una buena practica, tambien acepto sugerencias sobre esto.

1 - Cada vez que en una página quiera imprimir la lista de objetos (lo cual sera frecuente) llamar a $usuario->mostrarObjetos(), lo cual comporta muchas llamadas a el SGBD y no se si esto puede saturar mucho el servidor.

2 - Añadir a la clase usuario el objeto $listaObjetos. De esta manera, de vez en cuando trendre que actualizar esta variable, pero el numero de llamadas al SGBD sera notablemente inferior, pero no se que repercusion puede tener en el uso de memoria en el servidor, ya que estara en $_SESSION.

Todo esto es teniendo en cuenta que la lista de objetos estara siempre rondando los 20-50 objetos de media.

Muchas gracias de antemano.

PD: No habia visto la subseccion de OO, si alguien me lo mueve ahi se lo agradecere porque yo no se como se hace. Perdon por el despiste.

[MarioNunes]

No entiendo esa idea,

Por cada usuario sacas una lista de objetos? y por que no creas el objeto con sus propiedades la primera vez que creas la instancia?

Luego lo único que haces es acceder a los valores de la clase... las variables que puedes obtener pueden ser también arrays :P

Un saludo.

[1000i1]

Mmm... a ver diria que tu idea y la mia son la msima, pero es que me hago unos lios escribiendo.... Lo que pregunto es si es mejor al crear el usuario obtener su lista y guadarla como atributo de la clase, u obtener la lista cada vez que la necesite.

Supongo que me quedare con la primera porque me parece obvio que es mucho mas eficiente. Pero bueno a lo mejor alguien lo ve de otra manera.

Lo que ahora no se es si es bueno esto que hago de guardarlo todo en $_SESSION, porque diria que no es una gran manera de hacer las cosas, si alguien tiene algo que decir al respecto se agadece.

Hasta luego.

[GatorV]

Lo que tu te refieres se le conoce como "cacheo" es decir para evitar estar haciendo multiples consultas a la base de datos, haces todos tus procesos y guardas la copia por X segundos, cuando pasan esos X segundos generas una copia nueva y asi, esto en sitios muy grandes hace muy eficiente la busqueda en la base de datos.

Saludos

[dashtrash]

Buenass..
He encontrado por casualidad este foro mientras buscaba otra cosa, y me ha parecido interesante esta pregunta...
He programado durante 8 años C++, durante 2 java, y durante 6,PHP.Y la pregunta original, es más interesante de lo que parece.
No es un problema de cacheo.
Es un problema inherente a la programación orientada a objetos aplicada a todo.Yo era un defensor de la OOP, hasta que empecé a usar PHP y programar para la web, donde sus problemas son obvios.
Supongamos que tu estructura de clases es :
-CUsuario
-CObjetoUsuario
Supongamos que las tablas son:
-USUARIO
-OBJETOUSUARIO. Objetousuario tiene un campo ID_USUARIO, que indica a quien pertenece (suponemos que 1 objeto sólo pertenece a 1 usuario,relación 1-n)
El orden "orientado a objetos" sería algo así como:

1) Obtener la lista de objetos pertenecientes al usuario (1 query)

2) Por cada uno de esos objetos, crear una instancia de CObjetoUsuario, pasandole el ID de OBJETOUSUARIO. (1 query por cada uno de los CObjetoUsuario)

Resultado: tantas queries como OBJETOUSUARIO tengas, + 1.
Resultado 2: supón que, OBJETOUSUARIO, en su constructor, inicializa otros objetos dependientes de él.Y supón que, en un caso particular, tú sólo quieres sacar el nombre del objeto, y no quieres hacer nada con sus posibles subobjetos....Puedes seguir multiplicando el número de queries que se hacen...

Cuando esto se resuelve en SQL, con 1 sola query.

Esto lo he visto MUCHAS veces en código de todo tipo...Comercial, open-source,etc,etc.Bucles de creaciones de objetos, con queries anidadas.Cada objeto suele estar definido en su propio php3, con lo cual el programador no es consciente muchas veces de lo que está ocurriendo.

Que se puede hacer de otra forma?Claro...pero el modelo empieza a complicarse *bastante*...Tanto que, personalmente, uso OOP sólo donde la herencia tiene sentido, o como forma de agrupar funciones.
Para el resto (incluyendo la elaboración del interfaz de usuario, y obtener datos a mostrar en la web), existen sistemas de plantillas y xml/xsl que lo hacen muy bien (en vez de crear aberraciones como CTable,CContainer....).

El problema es hacer 1 query con aquello que sabemos que se puede resolver en 1 query.Usar caché como forma de "evitar" 100 queries (cuando puedes evitarlo), no es solución.
Y,siendo PHP un lenguaje interpretado, tiene muchisimas formas más flexibles que la OOP para resolver gran parte de los proyectos web, sin perder rendimiento.Yo opto por la generación de código.

[GatorV]

Estimado dashtrash:

Aun si hicieras PHP en forma procedural tendrias el mismo problema si tienes un mal disenio de tu sistema y su infraestructura.

Lo que tu planteas, es problema de disenio, no de OOP o Tablas, si tu programas bien tu sistema, aunque sea 100% en OOP, no tendras problemas con 100 Querys, o que no sepas que hace tu sistema, ya que puedes eficientar procesos y usar mucho cacheo. Pero siempre y cuando que el disenio de tu sistema y su infraestructura sean lo suficientemente poderosas para darte esa flexibilidad.

El rendimiento es relativo si tu disenio e infraestructura son solidas, puedes hacer un sistema 100% OOP mas eficiente que en forma procedural, al final son metodologias diferentes de programacion, para PHP y tu Procesador son Instrucciones, asi que no le importa si son en OOP, o Orientado a Funciones.

[dashtrash]

Por supuesto que la respuesta a es "depende del diseño"...Todo depende del diseño de la aplicación.Y los modelos de programación (procedural, orientado a objetos,agile,etc,etc), te llevan a unos diseños, o a otros.Y la OOP lleva en un 95% de los casos, a diseños ineficientes.Y algunos de los eficientes, rompen las normas básicas de encapsulación...
Esta es una larga discusión, y sólo se resuelve mirando el código...
De hecho, este problema no es exclusivo de la OOP, pero se agrava con la OOP.

[GatorV]

Se agrava en que aspecto? La OOP no tiene nada que ver con este problema, como tu lo dices es un metodo de programacion, todo depende de como lo ocupe el programador (al final el problema se encuentra entre el monitor y la silla).

Si ves soluciones como Propel, veras que es mas que eficiente la forma en la que almacenan los objetos en el servidor, e implementan cacheo por si solas, si usas una libreria asi, tu aplicacion se acelera mucho mas, e ironicamente es un sistema OOP.

[dashtrash]

SQL permite JOINS, Select anidados, etc,etc.
Estas construcciones implican que alguien, en algún punto, conoce cómo están almacenados 2 o más objetos, dentro de la base de datos, para poder construir 1 sola query que relacione ambas cosas.
Lo cual es una violación de la OOP.
Opciones:
1) No haces joins.
2) Creas métodos "especificos" para crear estas queries.(lo cual sigue siendo una violación de la OOP).

La OOP construye un sistema de relación entre objetos, y SQL tiene el suyo propio.El mapeo entre un sistema de relación y otro se suele solucionar montando una clase por tabla (más o menos), lo cual es muy de OOP, pero completamente ineficiente para muchas operaciones.
Esto también te puede ocurrir usando simplemente funciones,sin OOP, por supuesto.Pero OOP *te insta* a que te ocurra.Es su filosofía.

Las cachés no resuelven el problema.Cachear 100 queries, y montar una pagina, sigue siendo más lento que cachear 1 query, y montar una página.
Además, algunos SGDB tienen sus propias cachés.Y,cuantas menos queries diferentes se envíen,más probabilidad tienes de que exista esa query en la caché del SGDB.Por supuesto, además, no todo es cacheable, y no todo tiene la misma política de caché....Lo cual se resuelve también, por supuesto..

[enriqueplace]

Bueno, estoy tomando aire y contando hasta 100...

¿Me puedes explicar al detalle qué es concretamente "violación a la OOP", que no lo entiendo?

Parece que estuvieras diciendo "la violación de la licencia GPL", cuando son cosas muy distintas. Que la capa de persistencia tenga que lidiar contra una base de datos o con otra cosa no necesariamente es una "violación a algo", pero sí, estoy de acuerdo que lo ideal es tener un mundo enteramente orientado a objetos y todos hablar el mismo idioma.

Pero eso de "violar", como si fueran leyes, no lo entendí y menos esa "receta" de "no hacer joins" para no "violar" no sé que cosa.

1001... 1002... 1003...

[hectorjazz]

nuevamente estamos en la edad de piedra, no puedo creer que profesionales de la informatica culpen al paradigma de la ineficiencia de la aplicacion. La verdad mas alla de todo existen bytes y mas bytes, 0000001110101111011011101101101, etc, etc ,etc.

entonces donde esta el problema??

felicito a enrrique por que se nota que es profesional, y en el mundo de php hay muy pocos.

Saludos.

[GatorV]

Creo he caido otra vez en estar alimentando a los trolls je.

Mi estimado dashtrash, se nota lo poco profesional que eres al pensar eso, asi que te dejo con tus ideas.

[dashtrash]

Bueno, continuo yo con la cuenta...
Hectorjazz
Según tú, como todo son unos y ceros, da lo mismo ejecutar diez unos y ceros, que mil millones de unos y ceros.
Efectivamente, un PDP-11 y un Pentium-IV, por ejemplo, ejecutan ambos secuencias del tipo 110100100100100010, asi que, como no hay problema siempre que sean unos y ceros, espero que uses un PDP-11, ya que es exactamente lo mismo que un Pentium IV, ya que ejecuta unos y ceros..........

[...]

Como bien dices, estamos en la edad de piedra de la informática, si la forma de evaluar las cosas es esa.


enriqueplace:
Si algo no lo entiendes, no debes enfadarte, hombre...ni contar hasta 100..ni hasta mil...Se pregunta y ya está..Da igual, está bien tu post...Empiezas:

estoy tomando aire y contando hasta 100.

continuas:

pero sí, estoy de acuerdo que lo ideal es tener un mundo enteramente orientado a objetos y todos hablar el mismo idioma.

A qué tanto enfado??
Si estás de acuerdo!! (Aunque tu solución no me parezca buena...quien necesita tanta orientación a objetos?)

Que la OOP no tiene leyes?...Bueno, entonces, cualquier cosa es OOP.Faltaría más.Todo código es OOP.

Que no sabes qué es violar la OOP? : (Búsqueda en google:)Resultados 1 - 10 de aproximadamente 60.800 de "violate" "OOP"
No hay nada como informarse.

Que no consigues ver por qué un JOIN viola (en la mayor parte de los casos) la OOP?
Si tienes 2 tablas que almacenan objetos de clases diferentes, y se hace un JOIN entre ellas, significa que *alguien* conoce a la vez la estructura interna de 2 clases.Aún más, presupone que los objetos de esa clase comparten el mismo sistema de almacenamiento.O comparten sistema de base de datos.O conexion de base de datos.

Me puedes decir que esto lo solucionas con una capa de abstracción de almacenamiento.Y aunque es medianamente posible (no del todo, o no fácilmente del todo...no todos los medios de almacenamiento son relacionales, por ejemplo...), esto no te da abstracción de relaciones, es decir, cómo relacionar el objeto A y el B, por qué campos, usando qué claves, tienes que especificárselo.Y, sea cual sea quien lo especifique, está presuponiendo la estructura de datos usada por el otro.
Esto se llama encapsulamiento, y, aunque creas que la OOP "no tiene leyes", hay *algunos* que creen que sí, y esta es una.
Ni A ni B pueden conocer detalles de cómo están implementada la otra, mucho menos de su estructura en base de datos.Así que ni A puede crear un JOIN con B, ni viceversa.

Solución: crear una capa de abstracción de relaciones, a la vez que de almacenamiento,cosa que hice en mi tiempo.
Resultado: sigue siendo demasiado más fácil el hacer un JOIN.


Y tú, que sabes esto, aunque quien sabe por qué motivos cuentas hasta nosecuantos, piensas que la solución son bases de datos orientadas a objetos.Yo no estoy de acuerdo, allá cada uno, y eso es discutible.
Ahora bien, decir que las deficiencias se arreglan con cachés...

[DarioDario]

Iniciado por dashtrash

He programado durante 8 años C++, durante 2 java, y durante 6,PHP.

No entiendo porque algunas personas piensan que esto es referenciable... no importa el tiempo o ¿No pudiste programar duran 8 años con conceptos mal formados?

[hectorjazz]

Estimado dashtrash:
mis disculpas, reconozco que mi post fue algo apresurado y alomejor un poco hiriente.

trata de tomarlo con mas calma, en muchas cosas tienes razon, pero dejame darte mi opiniom en otras palabras, cambiemos un poco el trato.

yo pienso que la OOP soluciona aspectos de diseño de software, la manera de ver los elementos de programacion, encapsula las mismas rutinas de antes en objetos, esos objetos representan entidades del mundo real.

Como quiera que la OOP presenta una nueva forma de ver la programacion de diseñar y construir software, no quiere decir que no se puedan lograr las mismas cosas con un lenguaje no OOP. lo que me lleva a concluir que al final del cuanto, cuando todo se reduce a ceros y unos, si lo programaste con objetos o con rutinas, no debiera notarse el cambio, ya que la traduccion se reduce a las instrucciones que conoce el procesador y estas son siempre las mismas(para un ordenador).

espero que me entiendas. y con respecto a lo de enrique, no creo que estuviera enfadado o algo asi, solo es su humor, trata de tomar las cosas escenciales que el enseña ya que las explica muy bien, y sirven a cualquiera.

Saludos.

[enriqueplace]

Somos varios... ahora, como salimos de esta?

[enriqueplace]

enriqueplace:
Si algo no lo entiendes, no debes enfadarte, hombre...ni contar hasta 100..ni hasta mil...Se pregunta y ya está..Da igual, está bien tu post...Empiezas:

Bueno, tengo un sentido del humor muy particular.

A qué tanto enfado??
Si estás de acuerdo!! (Aunque tu solución no me parezca buena...quien necesita tanta orientación a objetos?)

No enfadado, pero me salen canas verdes cuando se es tan "absolutista" sin dar margen al error.

Que la OOP no tiene leyes?...Bueno, entonces, cualquier cosa es OOP.Faltaría más.Todo código es OOP. Que no sabes qué es violar la OOP? : (Búsqueda en google:)Resultados 1 - 10 de aproximadamente 60.800 de "violate" "OOP"
No hay nada como informarse.

De "violar" a "leyes" hay un placer de diferencia. Además, en Internet se encuentra tanta basura desperdigada (cualquiera escribe malos libros sobre POO en PHP, hasta yo estoy haciendo uno).

Que no consigues ver por qué un JOIN viola (en la mayor parte de los casos) la OOP? Si tienes 2 tablas que almacenan objetos de clases diferentes, y se hace un JOIN entre ellas, significa que *alguien* conoce a la vez la estructura interna de 2 clases.Aún más, presupone que los objetos de esa clase comparten el mismo sistema de almacenamiento.O comparten sistema de base de datos.O conexion de base de datos.

Y dale con "violar". Tu confusión es clarísima. Estás mezclando temas que no tienen por qué estar relacionados directamente. Los Joins son un problema del mundo relacional, no directamente de la POO. Decir tan suelto de cuerpo y en público que "un Join viola la POO" me daría un poco de verguenza.

Interactuar con herramientas o entornos distintos es de todos los días, es como decir que lo mismo sucede con XML, con HTML, etc.

Me puedes decir que esto lo solucionas con una capa de abstracción de almacenamiento.Y aunque es medianamente posible (no del todo, o no fácilmente del todo...no todos los medios de almacenamiento son relacionales, por ejemplo...), esto no

¿eh?

te da abstracción de relaciones, es decir, cómo relacionar el objeto A y el B, por qué campos, usando qué claves, tienes que especificárselo.Y, sea cual sea quien lo especifique, está presuponiendo la estructura de datos usada por el otro.
Esto se llama encapsulamiento, y, aunque creas que la OOP "no tiene leyes", hay *algunos* que creen que sí, y esta es una.

¿Me repites el enunciado que no me quedó claro? (no es broma)

Ni A ni B pueden conocer detalles de cómo están implementada la otra, mucho menos de su estructura en base de datos.Así que ni A puede crear un JOIN con B, ni viceversa. Solución: crear una capa de abstracción de relaciones, a la vez que de almacenamiento,cosa que hice en mi tiempo. Resultado: sigue siendo demasiado más fácil el hacer un JOIN.

Pero esa es una decisión que deberás tomar siempre, cual opción es más productiva según tu contexto (decir cuando accedes directamente a la base de datos).

Y tú, que sabes esto, aunque quien sabe por qué motivos cuentas hasta nosecuantos, piensas que la solución son bases de datos orientadas a objetos.Yo no estoy de acuerdo, allá cada uno, y eso es discutible.

¿eh? No hablé exclusivamente de las bases, es lógica pura. Pero ya que hablas de las bases, estas usan el "modelo relacional" y tu lenguaje el "modelo de objetos", siempre será mejor para la programación "tirar" literalmente un objeto a la base y que este se persista. Pero el punto vuelve a ser tu contexto, si esto te sirve, o es preferible usar la base de datos relacional porque está más especializada para consultar datos. Todas las herramientas de persistencia que solucionan esta conversión de mundos deja una puerta trasera para saltear esto e ir directo a la base.

Ahora bien, decir que las deficiencias se arreglan con cachés...

Muy despectivo lo suyo.

Creo que se debería crear una regla para que los novatos en el foro no puedan escribir hasta luego de haber leído por lo menos 100 comentarios, así, igual que con los archivos que no se pueden subir ni bien registrado al sitio. Así, no entramos tan abruptamente pateando mesas y sillas, y evitamos discusiones tontas.

No lo digo exclusivamente por ti, pero sí, estás en la bolsa.

[GatorV]

Mi estimado Enrique

Admiro tus ganas de estar peleando con la pared jeje

A mi me queda algo claro, no todo mundo tiene la habilidad de ver mas alla de lo que tiene enfrente, y es triste, pero ese tipo de personas es las que ves programando en las granjas de software, como loquitos.

Los que pueden ver mas alla, e investigan y ven a mas, son los que pueden llegar a estar en la silla del jefe.

[enriqueplace]

Mi estimado Enrique

Mi estimado Gatorv

Admiro tus ganas de estar peleando con la pared jeje

Es que estoy acostumbrado a pelear contra los molinos de viento... ya es parte de mi entrenamiento diario, como quién sale a correr todas las mañanas

A mi me queda algo claro, no todo mundo tiene la habilidad de ver mas alla de lo que tiene enfrente, y es triste, pero ese tipo de personas es las que ves programando en las granjas de software, como loquitos.

Puede ser, vos decís picoteando código, como las gallinas? (¿y después vienen y ponen un huevo en los foros? )

Los que pueden ver mas alla, e investigan y ven a mas, son los que pueden llegar a estar en la silla del jefe.

No sé, yo todavía no soy jefe... ah, no lo decías por mi, no?