Cita: Pero dudaba en hacerlo así, por lo que había visto en grandes aplicaciones, como foro phpbb3, foro smf, o incluso wordpress, ellos lo hacían solo con una tabla.
Perdón si resulto peyorativo, pero ese tipo de aplicaciones está más hecho por programadores que por diseñadores de datos. Pero por sobre todo están hechos de una forma simplista y no eficiente, lo que a la larga se paga con recursos de hardware y tiempo de Mp.
Cita: No sé... pensaré a por cual me decido. Tenerlo en varias tablas puede ser "excesivo" para buscar datos, tendré que ir juntando joins entre varias tablas, y no se si eso me penalizará a la hora de buscar.
Si los joins te "penalizaran" a la hora de buscar datos con JOINS, los JOINs no se usarían. Te imaginas que si es una de las formas más usadas, es precisamente porque es muy poderosa a la hora de obtener datos y realizar consultas complejas.
Para citar un ejemplo propio, tengo un stored procedure que sin el uso de JOINS lleva (en la fase de prototipo lo probamos) 1 hora y 52 minutos de promedio para obtener la tabla de resultados buscado. Cuando completamos la integración de los JOINs (más de 30 en diferentes etapas), el proceso pasó a durar aproximadamente 1 minuto 20 segundos...
Un JOIN bien usado es la diferencia entre obtener 4.0000 registros de una tabla que cumplen una condición, o sólo 37, que son los únicos que coinciden entre dos tablas unidas con JOIN.
Considera también que cuando no usas JOIN, todas las condiciones deben expresarse en el WHERE, y el WHERE no es optimizable estadístiamente por el parser, en cambio en el FROM sí el parser puede hacer cambios. Esto se debe a un problema de lógica interna del DBMS.
Cita: La ventaja que veo de tener toda la info del usuario en una tabla es que no gasto recursos con joins y selects a diferentes tablas del usuario...
Lo poco que usar una sola tabla te hará ahorrar al principio lo pagarás en transporte de datos, líneas de programación adicionales, condiciones adicionales innecesarias, parámetros adicionales, consultas adicionales para la parametriazación, mayor cantidad de memoria usada en una consulta, y varios problemas más, entre los cuales encontrarás que tarde o temprano te hallarás con cuellos de botella imposibles de resolver sin normalización. Y cuando suceda (no sigo
si sucede sino
cuando suceda) deberás volver al tablero y rediseñar de nuevo...
Consejo final: Normaliza y diseña mejores consultas. Ahorrarás tiempo si empiezas a pensar la base con vistas al uso en el futuro y no en la simplicidad de hoy.