¿No es razonable asignar una base de datos MySQL a cada usuario de mi sitio?

Question

Estoy creando un sitio web basado en el usuario. Para cada usuario, necesitaré algunas tablas de MySQL para almacenar diferentes tipos de información (es decir, userInfo, quotesSubmitted y ratesSubmitted). ¿Es una mejor idea:

a) Crear una base de datos para el sitio (es decir, "mySite") y luego cientos o miles de tablas dentro de esto (es decir, "userInfo_bob", "quotessubmitted_bob", "userInfo_shelly" ", y "quotesSubmitted_shelly")

o

b) Crear cientos o miles de bases de datos (es decir, "Bob", "Shelly", etc.) y sólo un par de mesas por base de datos (es decir, Dentro de "Bob": userInfo, quotesSubmitted, ratesSubmitted, etc.)

Debo usar una base de datos y muchas tablas en ese dat abase, o muchas bases de datos y pocas tablas por base de datos?

---

Editar:

El problema es que necesito para realizar un seguimiento de quién ha evaluado qué. Eso significa que si un usuario ha calificado 300 presupuestos, debo ser capaz de saber exactamente qué cotizaciones ha calificado el usuario.

Tal vez debería hacer esto?

Una tabla para las comillas. Una tabla para listar usuarios. Una tabla para documentar TODAS las calificaciones que se han realizado (es decir, Tres columnas: usuario, presupuesto, clasificación). Eso parece razonable. ¿Hay algún problema con eso?

Answer 1

Utilice una base de datos.

Use una tabla para retener a los usuarios y una tabla para contener las comillas.

Entre esas dos tablas tiene una tabla que contiene información para hacer coincidir a los usuarios con las comillas, esta tabla mantendrá la calificación que un usuario ha dado una cotización.

Este diseño simple le permitirá almacenar un número de citas prácticamente ilimitado, usuarios ilimitados, y podrá hacer coincidir cada cita con cero o más usuarios y viceversa.

La tabla en el centro contendrá claves externas para el usuario y tablas de cotización.

Puede que le resulte útil revisar algunos conceptos básicos de diseño de bases de datos, aquí hay muchas preguntas relacionadas en stackoverflow.

empezar con estos ...

What is normalisation?

What is important to keep in mind when designing a database

How many fields is 'too many'?

More tables or more columns?

Answer 2

Ni. Usted crea una única base de datos con una sola tabla para cada tipo de datos, luego utiliza claves externas para vincular los datos de cada usuario. Si tuviera solo unos pocos usuarios fijos, esto no sería tan malo, pero lo que está sugiriendo simplemente no es escalable.

Answer 3

dos problemas con muchas bases de datos (en realidad muchos más, pero comienzan con éstas.)

1. No puede utilizar parámetros para los nombres de bases de datos.

2. ¿Qué harás cuando hagas tu primer cambio en una mesa? (Sugerencia: trabajo X (# bases de datos)).

Y "muchas tablas", sugiere que usted está pensando acerca de las tablas por usuario. Esa es otra idea igualmente problemática.

Answer 4

¿Debo usar una base de datos, y muchos tablas en la base de datos, o muchos bases de datos y algunas mesas por base de datos?

Ni, se debe utilizar una base de datos, con una mesa para los usuarios, una tabla de cotizaciones, una mesa para las tasas, etc.

A continuación, tiene una columna en (por ejemplo) la tabla de cotizaciones que dice para qué usuario es la cita.

CREATE TABLE user (
    user INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    ... 
); 

CREATE TABLE quote (
    quote INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    user INT(10) UNSIGNED NOT NULL, 
    ... 
); 

CREATE TABLE rate (
    rate INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    user INT(10) UNSIGNED NOT NULL, 
    ... 
); 

A continuación se usa SQL JOIN s en sus declaraciones SELECT para vincular las tablas juntos.

EDITAR - Lo anterior asumía una relación de muchos a uno entre usuarios y tarifas: cuando hay relaciones de 'muchos a muchos', necesita una tabla para cada tipo de datos y luego otra tabla con filas para cada usuario < -> par de tarifas.

Answer 5

Su diseño es defectuoso. Debe restringir las tuplas utilizando claves externas para el usuario correcto, en lugar de agregar nuevas entidades para cada cuenta.

Answer 6

tenemos un sistema similar, que tiene muchos usuarios y sus datos relevantes. Hemos seguido una única base de datos y un enfoque de tablas comunes. De esta forma, tendrías una única tabla con información del usuario y una tabla con todos sus datos. Junto con los datos, tenemos una referencia al userid que nos ayuda a segregar la información.

Answer 7

¿Cuál es la diferencia entre muchas tablas en una base de datos o muchas bases de datos con las mismas tablas? ¿Es para una mejor seguridad o para diferentes tipos de copias de seguridad?

No estoy seguro sobre MySQL en MSSQL, pero es así:

• Si necesita bases de datos de copia de seguridad en forma diferente que debe considerar mantener las tablas en diferentes archivos de datos. Por defecto, todos están en el archivo PRIMARIO. Puede especificar almacenamiento diferente.

• Todas las transacciones se mantienen en tempdb. Esto no es muy bueno porque si el registro de transacciones se llena, todas las bases de datos dejan de funcionar. Entonces puede terminar con servidores SQL separados para cada usuario. Lo cual es una tontería si hablas de miles de clientes.

Answer 8

Utilice una base de datos y una tabla. Necesitará una tabla "Usuario" y esta tabla se vinculará (Principal - Clave externa) a esta tabla.

Answer 9

Para comparar, un momento en el que realmente quiere bases de datos separadas sería cuando tiene varios clientes de alojamiento web que quieren hacer sus cosas con la base de datos; luego puede configurar la seguridad para que puedan acceder solo a sus propios datos.

Pero si está escribiendo el código para interactuar con la base de datos, no con ellos, entonces lo que quiere es tablas normalizadas como se describe en varias otras respuestas aquí.

Answer 10

Una tabla con índices creados correctamente por cada conjunto de entidades requeridas (una tabla para citas enviadas, una tabla para tasas enviadas).

CREATE TABLE quotesSubmtited (
    userid INTEGER, 
    submittime DATETIME, 
    quote INTEGER, 
    quotedata INTEGER, 
    PRIMARY KEY (userid, submittime), 
    FOREIGN KEY quote REFERENCES quotesList (quoteId), 
    FOREIGN KEY userid REFERENCES userList (userId) 
); 

CREATE INDEX idx1 ON quotesSubmitted (quote); 

Recuerde: más índices que cree, más lenta la actualización. Así que eche un vistazo más de cerca a lo que utiliza en las consultas y cree índices para eso. Un buen tutorial de optimización de bases de datos será de gran ayuda para comprender qué índices necesita crear (no puedo resumirlo en esta respuesta).

También supongo que no sabes acerca de JOINs y FOREIGN KEYs así que asegúrate de leer acerca de ellos también. ¡Bastante útil!