Aquitectura de base de datos

[kadas99]

Buenos dias, les comento lo que me acontece.
Tengo que armar una base de datos para una red social, en la cual hay de todo! (Como en cualquier red social) entonces mi duda es, como hacer para armar una base de datos ordenada, limpia y rapida.

Ojo no estoy pidiendo que me armen la base de datos, nada de eso, me gusta aprender, preferiria algun buen manual o tutorial "ENTENDIBLE" y bien explicado que hable sobre como hacer una buena arquitectura de base de datos.

Por lo pronto les comento en donde estoy parado

Todo esto que describo a continuacion, se va a repetir en varias categorias de usuarios, es decir, "Usuarios" "Agentes" "Profesionales"....

id
nombre
apellido
edad
email
telefono
direccion
pais
ciudad
localidad

Esto es lo que va a estar en comun entre todos los "Usuarios" "Agentes" "Profesionales".... pero despeus hay cosas especificas de cada categoria entonces, no se si hacer una sola tabla "datos" en donde poner todo lo mencionado arriba ("id","nombre"...) y luego diferenciar por algun campo y desde ese buscar la info de cada categoria, o, ingresar nuevamente por cada categoria todos los datos. No se cual sera mas eficaz a la hora de armarla o a la hora de hacer busquedas.

Vale comentar que un cliente no puede ser dos categorias distintas, solo una. No puede ser "Agente" y "Profesionales" al mismo tiempo.

Desde ya muchas gracias

[Marvin]

Iniciado por Como informacion preliminar

Desde ya te recomiendo que no utilices mysql para hacer una red social... investiga un poco de las bases de datos con arquitectura basada en Grafos, que estan pintadas para esto (de hecho facebook utiliza un alto porcentaje de arquitectura en esto)

Esto te lo digo porque la cantidad de consultas a la base de datos que tendras que sacar para ir aumentando el sistema, se va a ver necesitada solo por la calidad de la maquina en que este el equipo... en otras palabras... a mayor sistema, mayor maquina, lo que implica la instalacion y migracion de todo nuevamente. Y la idea de un sistema de esta embergadura, es tener algo que diga, a mayor sistema, agrego otro pc.

Ahora... si de verdad ya haz avanzado mucho y no tienes mucho tiempo para aprender esto, lo que debes tener en cuenta es que si haces una consulta a 3 tablas y luego haces una consulta a 1 sola tabla, es altamente probable que esta ultima sea mas efectiva.

Por lo tanto yo les pondria un campo llamado categoria y otro (extra) llamado subcategoria. De esta manera podras tener un agente por categoria y tambien podras identificarlos como super agente, agente 86 o lo que se te ocurra con la subcategoria.

A todo esto, en la tabla categoria puedes anexar la informacion que quieras... y despues solo buscas por el id. (Ve informacion de NATURAL JOIN si usas mysql, es muy efectiva para este tipo de cosas)

Suerte!

[kadas99]

te agradezco la respuesta, te comento mi situacion. Con el tema de la base de datos no arme nada por ahora, nada, asi que ese no es problema, lo que si es problema es el tiempo, no creo aprenderme todo el tema grafos para mañana! que es cuando debo presentar la base de datos para ya ir desarrollando sobre eso! (Estoy un poco jugado no?)

Otra cosita, entiendo lo que dices de las 3 consultas (una para buscar el id dentro de la categoria general, otra para buscar si es agente, profesional, abodago, y otra para cualquier otro dato no incluido en las dos primeras), pero, me queres decir que es mejor mantener todos los datos dentro de una sola tabla? aunque eso signifique repetir nombre de los campos?

Me refiero a que esto:

Tabla Usuarios: Tabla Agentes: Tabla Profesionales:
ID ID ID
NOMBRE NOMBRE NOMBRE
APELLIDO APELIDO APELLIDO
TELEFONO TELEFONO TELEFONO
EMAIL EMAIL EMAIL
..... ...... .....

es mejor que esto:

CATEGORIA_GLOBA:
ID
ID_INDENTIFICADOR*
NOMBRE
APELLIDO
TELEFONO
EMAIL
....

???????


Donde ID_IDENTIFICADOR es el que me va a informar si es USUARIO, AGENTE, PROFESIONAL.... bla bla???


desde ya agradezco tu interes al haber contestado anteriromente el mensaje.

me gustaria aprender un poco mas pero tengo poco tiempo jajaj! Alguna lectura rapida y que vaya directamente al grano?


Un abrazo

[Marvin]

Entonces rapidito... xD

Lo que te digo es que te conviene hacer esto:
Tabla persona (per_id, per_nombre, per_apellido, per_telefono, ...... , cat_id)
Tabla categoria (cat_id, cat_nombre)

En donde tendras en las categorias:
1, usuario
2, agente
3, profesional

Por lo tanto vas a identificar a todos los agentes con esta consulta:

Código MySQL:

SELECT * FROM persona WHERE cat_id = 2
 

O si tienes solo el nombre de la categoria asi:

Código MySQL:

SELECT * FROM persona NATURAL JOIN categoria WHERE cat_nombre = 'agente'
 

Suerte!

[kadas99]

Genial! Ahora te puedo hacer otra consultita??

Por ejemplo, el dia que que haya muchos usuarios (clientes, agentes, profesionales), esta consulta (SELECT * FROM persona WHERE cat_id = 2) seguria siendo veloz? es decir, en la tabla persona van a estar agrupadas todas las categorias (clientes,agentes, profesionales) y me parece que no es lo mismo buscar todos los datos de una tabla con 1328331232142 registros que una tabla con 1000.

Otra cosa, necesito utilizar las famosas Foreing Keys?

Un abrazo y muchas gracias por toda tu ayuda.

[kadas99]

Otra cosa que estoy leyendo sobre base de datos mysql con motor MyISAM e InnoDB es que InnoDB bloquea solo el registro que vamos a modificar y no toda la tabla completa, en cambio MyISAM bloquea la tabla completa pudiendo llegar a crear colas de peticiones, esto es cierto?

de ser asi me tiro mas a motor InnoDB? Siendo que el InnoDB es mas para el tipo de querys relacionadas con INSERT, SELECT, UPDAtES. Y MyISAM predominan los SELECTS haciendo este trabajo mas rapido!?

Poniendo estas cositas en la balanza por ahora me estoy quedandon con InnoDB! pero yo no soy el experto asi que mas vale consultar a alguen que si sabe del tema!

Asi que espero sus respuestas! Desde ya muchas gracias!

Abrazo

[kadas99]

Como deberia ser una consulta a una base de datos en donde hay claves foraneas?

Es decir:
Tabla hola (id, nombre [clave foranea])
Tabla adios (id, nombre, apellido)

??

Alguna idea, no encuentro mucho sobre esto!

[gnzsoloyo]

de ser asi me tiro mas a motor InnoDB? Siendo que el InnoDB es mas para el tipo de querys relacionadas con INSERT, SELECT, UPDAtES. Y MyISAM predominan los SELECTS haciendo este trabajo mas rapido!?

Si vas a usar claves foráneas, InnoDB si so sí. MyISAM no tiene FK.

Como deberia ser una consulta a una base de datos en donde hay claves foraneas?

Primero, recuerda que una FK es un campo (o conjunto de campos) que relaciona una tabla con otra a través de la clave primaria de la otra tabla. Eso significa que no puedes plantear una FK que apunte a un campo común, sino sólo a una PK.

Tabla hola (hola_id, nombre, adios_id)
Tabla adios (adios_id, nombre, apellido)

Código MySQL:

SELECT * FROM hola H INNER JOIN adios A ON H.adios_id = A.adios_id;