Optimización PHP & MySQL

[cnavast]

Hola,

Estoy haciendo una página y me ha surgido una duda a la hora de escoger el camino que debo seguir. Os pongo en situación: una página con usuarios e ideas. Cada usuario puede votar (si quiere) una idea, pero solo puede hacerlo una vez.
Ahora viene la pregunta: para hacer que el usuario sólo pueda votar una vez cada idea, ¿qué harías?

a) Crear una nueva tabla que vincule la id del user con la id de la idea. Es decir, cada vez que un user vote una idea se añadirá en esta tabla una nueva entrada, y si luego el user intenta volver a votarla el sistema tendrá que buscar en esta tabla a ver si ya ha votado o todavía no.

b) Crear un nuevo campo en la tabla de usuarios que sea en plan ideasVotadas que por cada usuario tenga las identidades de las ideas a las que se ha votado separadas por comas o algo así, y luego ya en php descargarlo todo como cadena y buscar si ya ha votado a esa idea.

c) ¿? (otra opción, explicarla)

¡Gracias!

[repara2]

Unicamente es válida la opción A, consulta documentación acerca de diseño de bases de datos / aplicaciones. Saludos

[cnavast]

¿Pero no sería más eficiente la opción B? Imagínate que tenemos las ideas 1,2,...,10, y el usuario 5 ha votado la 3,6 y 8. Con el método A implicaría tener 3 entradas más en la base de datos. Con el método B, en la entrada perteneciente al usuario 5 de la tabla usuarios tendríamos un campo (ideasVotadas) con este contenido (por ejemplo): "|3|6|8|".
Si ahora el usuario 5 intenta votar a la idea 6, el servidor descarga el campo ideasVotadas del usuario activo y simplemente mediante PHP busca si la cadena |6| está dentro de la cadena |3|6|8|, y si es así no le deja votar. Sin embargo, si intentara votar a la idea 7, se haría un update a la base de datos que quedaría |3|6|8|7|.
En definitiva (creo) se ahorraría por un lado en espacio de la base de datos y por otro en eficiencia (supongo que al servidor le costará menos tener que buscar un string dentro de otro que ponerse a buscar en una base de datos que puede tener miles de entradas). Pero vamos, que igual no... no tengo mucha idea sobre cómo funciona a nivel 'uso de memoria y procesador' ni PHP ni MySQL ni nada.

¿Cómo lo ves?

[zalito12]

No, es más eficiente la opción A.
Usarás la misma página para cada idea así que sólo tendrás que ponerlo una vez, y es una pequeña consulta, aunque tuvieses pocas ideas la opción B sería menos eficiente, ahora imagina con 100 ideas.

[exangel]

Hola,
Sin ninguna duda, la opción B es la única recomendada.

Saludos

[Bugger]

hola,

yo estoy con repara2 y zalito12, me decanto por la opción A, por sus mismas razones, especialmente por el diseño de la Base de Datos.

saludos

[zalito12]

No sé como es tu sistema de votaciones pero imagina que te decides por crear un sistema en el que puedas puntuar de 1 a 10 o como en los foros, que puedas votar +1 o -1. Con la opción B tendrías que reestructurar todo.

Con la opción A en esa misma tabla puedes añadir un campo para poner la votación del usuario. Ten en cuenta que usar listas en un campo como identificadores no suele ser la mejor opción en la mayoría de los casos.

Siempre hay que hacer, aunque sea pequeño, un esquema de como lo vamos a estructurar. Obviamente tendrás un tabla con todos los usuarios y cada uno tendrá un identificador, tendrás otra tabla con todas las ideas y cada una su identificador.
Pues ahora puedes crear una tabla con id_usuario, id_idea, fecha, votacion

Es una idea, tu tendrás que hacerlo como mejor se adapte a tu situación, en votación podrías guardar la puntuación.

[cnavast]

Aún no lo tengo nada claro xD
Es que lo que yo no termino de ver es lo de eficiencia en el lado del servidor... Imaginad que hay, yo qué sé, 10.000 ideas y 1.000 usuarios, y cada usuario ha votado una media de 3 ideas. Esto haría en la base de datos de la opción A tengamos 3.000 entradas. Si ahora un usuario intentara votar una idea, el sistema tendría que revisar esas 3.000 entradas comprobando para cada una que no tiene mismo userID, ideaID... y si lo tiene, entonces devolvería error porque esa idea ya habría sido votada por ese usuario. Y si en vez de 3000 entradas empieza a crecer y tenemos 100.000, o más... pues creo que aquello empieza a irse de las manos, cada vez que alguien quisiera votar el servidor tendría que verificar demasiadas entradas.
Y sobre lo del valor del voto, la idea B podría arreglarse y que en vez de guardar solo las ideas guardara en plan |ideaID_valorVoto|, eso es lo de menos. Pero me parece más eficiente que el servidor solo tenga que buscar dentro de una string que será relativamente corta a ver si ya se ha votado a esa idea antes que tener que buscar por toooda una base de datos que puede tener miles de entradas... ¿no?

[Bugger]

miralo al revés :D

imagina que te piden una estadística/resultado donde te pregunten cuantos usuarios han votado esa idea... deberías buscar entre X usuarios en sus campos Strings quien ha votado esa idea... de la otra manera, la consulta será mucho más simple y eficaz aunque haya más registros. lo mismo con menos registros y por el diseño de base de datos que es ese el correcto.

no?

[santris]

Iniciado por repara2

Unicamente es válida la opción A, consulta documentación acerca de diseño de bases de datos / aplicaciones. Saludos

Totalmente de acuerdo!!

[cnavast]

Ok Bugger estoy de acuerdo contigo, pero es que en la base de datos de ideas, para cada idea hay un campo que guarda la cantidad de votos, así que para hacer recuento de votos no habría que hacer lo que tú dices, simplemente acceder a ese campo... Vale que luego no podrías decir quién ha votado a qué idea, pero ese supuesto no se va a dar nunca para el proyecto en el que trabajo.
¿Así qué tal? :P

A repara2 y santris, no entiendo a qué os referís con que la única opción válida es la A, como si la B no fuera a funcionar o algo así.

[Bugger]

Iniciado por cnavast

Ok Bugger estoy de acuerdo contigo, pero es que en la base de datos de ideas, para cada idea hay un campo que guarda la cantidad de votos, así que para hacer recuento de votos no habría que hacer lo que tú dices, simplemente acceder a ese campo... Vale que luego no podrías decir quién ha votado a qué idea, pero ese supuesto no se va a dar nunca para el proyecto en el que trabajo.
¿Así qué tal? :P

A repara2 y santris, no entiendo a qué os referís con que la única opción válida es la A, como si la B no fuera a funcionar o algo así.

al final el que decides eres tú, pero siempre será mejor la opción A. Vale que el ejemplo que te puse era un ejemplo rápido, pero te da muchas más posibilidades la opción A, nunca se sabe lo que puede crecer un proyecto y es mejor hacer las cosas estables de un buen principio!

saludos

[cnavast]

Ok Bugger, en ese sentido sé que tienes razón, pero ahora tal como están las cosas hablando de eficiencia del servidor, ¿qué opción es mejor? con eficiencia me refiero a.. eso, que no se sobrecargue el servidor, que pueda hacer las consultas rápido, no mucho uso de CPU ni de memoria RAM... Es que de esas cosas no tengo ni idea, de hecho yo lo hubiera hecho con la opción A de cabeza, pero como es un proyecto que me han encargado y por lo que me cuentan va a tener bastante uso, me he empezado a preocupar por eso también.
En cualquier caso mil gracias!

[Bugger]

La A!!!!!!!

[zalito12]

Iniciado por cnavast

Aún no lo tengo nada claro xD
Es que lo que yo no termino de ver es lo de eficiencia en el lado del servidor... Imaginad que hay, yo qué sé, 10.000 ideas y 1.000 usuarios, y cada usuario ha votado una media de 3 ideas. Esto haría en la base de datos de la opción A tengamos 3.000 entradas. Si ahora un usuario intentara votar una idea, el sistema tendría que revisar esas 3.000 entradas comprobando para cada una que no tiene mismo userID, ideaID...

Deberías mirar cuanto tarda en hacer una consulta de este tipo
SELECT * FROM votos WHERE id_user = '1' AND idea = '1'
Con 3.000 entradas, no creo que mucho, no creo no, es que mucho no es. Mira los foros, ¿cuantas entradas crees que tienen? Y para mostrar un post con algún mensaje, algo muy habitual, tienen que hacer más de una consulta y no es que estés epserando mucho, tarda más en cargar la página que en hacer la consulta.

Ahora imagina que tienes 100 usuarios y 100 ideas y que cada usuario ha votada cada idea, cada usuario tendría que tener en el campo que tú comentas en la opción B, 100 ids. Eso ya no es eficiente! una lista con 100 ids? Y mira que estamos hablando de 100 usuarios y 100 ideas no de 1.000 como comentabas tú.

[exangel]

Hola, pido perdón, me equivoqué al identificar la opción buena, es la A y no la B tal como escribí más arriba.

Saludos

[memoadian]

Lee acerca de Normalizacion de bases de datos para que lo tengas mucho, pero mucho más claro.

[unreal4u]

otro voto para opción A, si estás trabajando con MySQL, hasta los 32 ó 64 millones de registros no deberías tener problemas, esto contando obviamente con los índices adecuados, pero tu estructura de tabla es tan simple que no necesitas gran cosa, sólo una compuesta por userId y votacionId.

La opción B, claro, tendrás menos registros, pero el procesamiento por parte de PHP será muchísimo más lento que lo que hace la base de datos, por lo tanto, será mucho menos costoso para el usuario y para tu aplicación hacer la A. Además, trata de separar una cadena con 1.000 elementos: aparte de ocupar (mucha) más memoria en el proceso, se va a demorar más que una simple llamada a la base de datos que más encima está indexado.

Sorry, no veo ninguna justificación para decantarse por la opción B. Ándate por la opción A ;)

Saludos.

[nomakon]

La opcion B es la mejor

[oscartt67]

Si tienes pocas ideas (no tu, la tabla), puedes usar la b.
En caso contrario, la a sin ninguna duda. Ademas, puedes utilizar una restriccion de indice en la tabla votos, de usuario+idea=unique, delegando a la db la unicidad del voto y campturando el error. asi te ahorras la comprovacion.

[cnavast]

Ok, pues a por la opción A. Los últimos mensajes me han convencido.
Ahora ya solo por curiosidad, ¿por qué es tan importante que la base de datos sea relacional (y no tenga más de un valor por campo)?

[oscartt67]

Porque garantizas integridad referencial y where id=12 es mucho mas rapido que where id in (2,3,4,....n).