Duda usar una o dos tablas

[neodani]

Buenas,

Tengo una duda, estoy creando mi tabla usuarios registrados para mi web, y no se si juntar todos los datos en una misma tabla o crear dos tablas... no se qué manera será mas óptima o si da igual que la información esté en 1 o 2 tablas.

¿Qué me aconsejáis?

Os adjunto la descripción de los campos



Muchas gracias de antemano!

[Vun]

Pero no explicas cual es el motivo de hacer 2 tablas ¿que datos quieres separar y por qué?

[neodani]

Iniciado por Vun

Pero no explicas cual es el motivo de hacer 2 tablas ¿que datos quieres separar y por qué?

Esa es mi duda, si debo separar los datos en dos tablas o no... un ejemplo sería una tabla con la info necesaria del usuario lo básico y otra podría ser con las preferencias del usuario.

Pero también he visto tablas de usuario de wordpress, phpbb3 y smf que no los separan... que toda la info del usuario la tienen en una sola tabla, me preguntaba si era más eficiente así...

Esa es mi duda, separar o no separar :D

[Vun]

Bueno, entonces ya habras visto que tablas como esas con 50 o 60 campos no son ningun problema para MYSQL, lo unico que si he leido por ahi es si tienes algun campo tipo BLOB o TEXT que guarden muchos KBs de información con muchos registros (hablo de diezmiles de registros) entonces si conseguiriamos tablas mas eficientes si sacamos esos campos pesados en una tabla tipo usuarios_infoextra o algo asi jeje

[neodani]

Iniciado por Vun

Bueno, entonces ya habras visto que tablas como esas con 50 o 60 campos no son ningun problema para MYSQL, lo unico que si he leido por ahi es si tienes algun campo tipo BLOB o TEXT que guarden muchos KBs de información con muchos registros (hablo de diezmiles de registros) entonces si conseguiriamos tablas mas eficientes si sacamos esos campos pesados en una tabla tipo usuarios_infoextra o algo asi jeje

Así que tu recomendación es usar 1 tabla en lugar de 2 debido a que son pocos campos. Muchas gracias Vun.

¿Alguien mas se anima a dar su opinión? :)

Muchas gracias!

[rickyper]

Pocos campos le llaman a eso??? Uy. Cuando veo esto recuerdo cuando mi Profe de Bd, me dio una tabla parecida para que la normalice.

[neodani]

Iniciado por rickyper

Pocos campos le llaman a eso??? Uy. Cuando veo esto recuerdo cuando mi Profe de Bd, me dio una tabla parecida para que la normalice.

¿Quiere decir que tu opinión es mejor usar 2 tablas?

Me gustaría saber todas vuestras opiniones :)

Gracias

[sk8ertux]

hola neodani espero que estes bien y pues aqui te va mi comentario amigo.

soy de la opinion neodani que todo lo que se hace, se debe hacer bien y de manera ordenada, con este comentario no te quiero ofender simplemente es la base que utilizo para realiar todos mis sistemas, bueno, como menciona ricky, yo tambien recuerdo cuando me dejaban tablas para normalizar, basicamente una tabla en lo personal me gusta verlo como un gabinete, donde guardas muchas cosas de un solo tipo, espero darme a entender.

bueno observando tu tabla yo la veo y la puedo clasificar en las siguientes secciones:

paises
creas una tabla donde ingresas los paises existentes

informacion personal
nombre completo
mail
sexo
fecha de nacmiento

informacion de usuario
user
pass
puntos me
registered
type
status
ip
lastlogin
avatar

confiuraciones del usuario
user rank
hide online
hide mail
hide edad
baneado
recibir ofertas

tambien te digo que en cuestion de base de datos, si tu entiendes como tienes todas las relaciones, te funcionara igual, pero tomando en cuenta el orden y basicamente la normalizacion, deberias de trabajar tu tabla asi, no veas tanto la cantidad de campos, si no observa mas la redundancia que puedes generar entre tus datos.

un foco grande de redundancia de datos, puede ser el campo pais, si todos escriben el nombre del pais donde habitan te encontraras con muchos datos repetidos y aun asi diferentes como por ejemplo españa,ESPAÑA,España, espero darme a entender con esto. bueno esto te infla mas el tamaño de tu base de datos, al contrario de ingresar una key que equivale a 1 o 200, esto te ocupa menos espacio en la base de datos.

espero haber podido despejar tu duda, y es bueno que preguntes, de esa manera asi obtienen muchas sugerencia y te formas tu propio criterio para manejar las bases de datos.

espero haber sido de ayuda...
estamos a las ordenes
[email protected]

[neodani]

Iniciado por sk8ertux

hola neodani espero que estes bien y pues aqui te va mi comentario amigo.

soy de la opinion neodani que todo lo que se hace, se debe hacer bien y de manera ordenada, con este comentario no te quiero ofender simplemente es la base que utilizo para realiar todos mis sistemas, bueno, como menciona ricky, yo tambien recuerdo cuando me dejaban tablas para normalizar, basicamente una tabla en lo personal me gusta verlo como un gabinete, donde guardas muchas cosas de un solo tipo, espero darme a entender.

bueno observando tu tabla yo la veo y la puedo clasificar en las siguientes secciones:

paises
creas una tabla donde ingresas los paises existentes

informacion personal
nombre completo
mail
sexo
fecha de nacmiento

informacion de usuario
user
pass
puntos me
registered
type
status
ip
lastlogin
avatar

confiuraciones del usuario
user rank
hide online
hide mail
hide edad
baneado
recibir ofertas

tambien te digo que en cuestion de base de datos, si tu entiendes como tienes todas las relaciones, te funcionara igual, pero tomando en cuenta el orden y basicamente la normalizacion, deberias de trabajar tu tabla asi, no veas tanto la cantidad de campos, si no observa mas la redundancia que puedes generar entre tus datos.

un foco grande de redundancia de datos, puede ser el campo pais, si todos escriben el nombre del pais donde habitan te encontraras con muchos datos repetidos y aun asi diferentes como por ejemplo españa,ESPAÑA,España, espero darme a entender con esto. bueno esto te infla mas el tamaño de tu base de datos, al contrario de ingresar una key que equivale a 1 o 200, esto te ocupa menos espacio en la base de datos.

espero haber podido despejar tu duda, y es bueno que preguntes, de esa manera asi obtienen muchas sugerencia y te formas tu propio criterio para manejar las bases de datos.

espero haber sido de ayuda...
estamos a las ordenes
[email protected]

Gracias sk8ertux, esa era la otra forma de hacer la tabla, dividiendo en varias tablas "normalizando", seguro que mi profe de BD también escogería esta opción.

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.

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.

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...

Muchas gracias

[gnzsoloyo]

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.

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.

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.

[rickyper]

Iniciado por gnzsoloyo

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.

Tienes razon... A la mayoria de programadores le igual si es una tabla con 50 campos, que pasa si quieres hacer un update¿? de 50 campos?, o insertar uno nuevo? ups. Me imagino que cuando vas por el décimo dato ya te aburriste. Lo que pasa es que siendo programadores tenemos que saber al menos un poco de diseño,estructuracion de base de datos y lo mas importante normalización. No basta con que el programa o sistema funcione correctamente.

Imaginate Tienes una tabla usuarios, otra clientes. Para esto tu en ambas tablas nesecitas en nombre del país.

Usuarios
idusuario
nombre
direccion
pais

Clientes
idcliente
nombre
direccion
pais

Esto haciendo tus consultas y tu programación te va perfecto. Pero...
Si te das cuenta hay dato que se repite muchas veces en ambas tablas.¿?¿?¿?
Pais y si haces una tabla pais?¿?¿? y lo relacionas con usuarios y clientes... A ver de la forma anterior haciendo una select un ejemplo de resultado:

idusuario nombre direccion pais
1 nombre1 direccion1 peru
2 nombre2 direccion2 argentina
3 nombre3 direccion3 peru
4 nombre4 direccion4 argentina
5 nombre5 direccion5 peru
6 nombre6 direccion6 peru

Y pasa algo parecido con la tabla cliente.o ¿no?.
Ahora la forma que yo te planteo es la siguiente:

idpais nombre
1 argentina
2 peru

Y la tabla usuarios sería:


idusuario nombre direccion idpais
1 nombre1 direccion1 2
2 nombre2 direccion2 1
3 nombre3 direccion3 2
4 nombre4 direccion4 1
5 nombre5 direccion5 2
6 nombre6 direccion6 2

¿Que tal te pareció?

[gnzsoloyo]

Hay un detalle que se debe recordar, muy importante, y que es una de las causas de normalización: LA consistencia de datos.
Cuando permites que un mismo tipo de datos se ingrese repetidamente en diferentes registros, como muestra rickyper, es muy habitual que haya ingresos incorrectos del mismo valor con pequeñas diferencias, que son importantes a la hora de las consultas. El mayor problema en estos casos es el factor humano.
Las personas no escriben igual, e incluso ciertas cosas las expresan de formas diferentes o simplemente lo hacen mal, y eso causa problemas constantemente. Si le permites escribir el nombre de un país, pueden hacerlo así:

PERU
Prú
Per
Peru
Perú
PERÚ
pERU
Argntina
Arg.
Rep. Arg.
Argentina
EEUU
EE.UU.
USA
U.S.A.
U.S.
ROU
R.O.U
Uuruguay
Uruguay
Ur.

¿21 países?
No. Sólo cuatro, pero escritos de formas tales que si quiero una selección de clientes y/o usuarios pertenecientes a un sólo país, por ejemplo, Uruguay, en lugar de salirme cinco (5) me saldría uno sólo, simplemente porque los datos no son consistentes.

¿Se ve, en este ejemplo, cómo afecta la consistencia de la información?

Todo esto desaparece con el ejemplo que da rickyper, y luego reconstruyes la tabla usando simplemente esto:

Código MySQL:

SELECT *
FROM usuario INNER JOIN pais USING(pais_id);
 

Tip: Siempre es importante que los nombres de los ID en su tabla origen sean los mismos que los campos usados como FK en las otras tablas; para ello es imprescindible que un ID jamás se llame ID simplemente, sino que lleve un nombre que mnemotécnicamente lo haga comprensible, tal como usuario_id, cliente_id, producto_id, pais_id, provincia_id, motor_id, etc.

[neodani]

Muchas gracias por vuestros consejos, de verdad que son excelentes y aportan muchísimo.

La tabla externa países la tenia clara desde el principio, por las razones que habéis mencionado.
¿Me aconsejáis también dividir el resto de datos en las 3 tablas tal y como opinaba sk8ertux?

información personal
información de usuario
configuraciones del usuario

De ser así, tendría que tener un identificativo para cada tabla para luego poder relacionarlas entre sí, no?

Gracias de antemano!

[rickyper]

Esta interesante lo que postea sk8ertux a esto le agregamos la tabla pais, aunque tambien como una opcion seria una tabla idioma. tu pones en tu tabla esp. tomando lo que dice

Iniciado por gnzsoloyo

Cuando permites que un mismo tipo de datos se ingrese repetidamente en diferentes registros, como muestra rickyper, es muy habitual que haya ingresos incorrectos del mismo valor con pequeñas diferencias, que son importantes a la hora de las consultas. El mayor problema en estos casos es el factor humano.

otro usuario podria poner español. Que tengas suerte en tu proyecto.

[rickyper]

Claro un identificador y este tiene que ir en ambas tablas ejemplo idpais en la tabla pais como clave primaria e idpais en la tabla usuario como clave foranea.

[neodani]

Iniciado por rickyper

Claro un identificador y este tiene que ir en ambas tablas ejemplo idpais en la tabla pais como clave primaria e idpais en la tabla usuario como clave foranea.

Capto por donde vas ;)

Muchas gracias