Разумно ли назначать базу данных MySQL каждому пользователю на моем сайте?

Question

Я создаю пользовательский сайт. Для каждого пользователя мне понадобится несколько таблиц MySQL для хранения различных типов информации (то есть userInfo, quotesSubmitted и rateSubmitted). Это лучшая идея:

a) Создайте одну базу данных для сайта (то есть «mySite»), а затем сотни или тысячи таблиц внутри нее (то есть «userInfo_bob», «quotessubmitted_bob», «userInfo_shelly» и «quotesSubmitted_shelly»)

или

б) Создайте сотни или тысячи баз данных (то есть «Боб», «Шелли» и т. Д.) И только пару таблиц на базу данных (то есть внутри «Боба»: userInfo, quotesSubmitted, rateSubmitted и т. Д. .)

Должен ли я использовать одну базу данных и много таблиц в этой базе данных, или много баз данных и несколько таблиц на базу данных?

---

Edit:

Проблема в том, что мне нужно отслеживать, кто что оценил. Это означает, что если пользователь оценил 300 цитат, мне нужно точно знать, какие цитаты он оценил.

Может быть, я должен это сделать?

Одна таблица для цитат. Одна таблица для списка пользователей. Одна таблица для документирования ВСЕХ выполненных оценок (то есть, три столбца: Пользователь, Цитата, Рейтинг). Это кажется разумным. Есть ли с этим проблемы?

Answer 1

Использовать одну базу данных.

Используйте одну таблицу для хранения пользователей и одну таблицу для хранения кавычек.

Между этими двумя таблицами есть таблица, содержащая информацию для сопоставления пользователей с кавычками, в этой таблице будет храниться оценка, которую пользователь дал цитате.

Этот простой дизайн позволит вам хранить практически неограниченное количество цитат, неограниченное количество пользователей, и вы сможете сопоставить каждую цитату с нулевым или большим количеством пользователей и наоборот.

Таблица в середине будет содержать внешних ключей для пользователя и таблицы кавычек.

Возможно, вам будет полезно ознакомиться с некоторыми основами проектирования баз данных, здесь много связанных вопросов по stackoverflow.

Начните с этих ...

Что такое нормализация?

Что важно иметь в виду при проектировании базы данных

Сколько полей «слишком много»?

Больше таблиц или больше столбцов?

Answer 2

Должен ли я использовать одну базу данных и много таблицы в этой базе данных, или много базы данных и несколько таблиц на базу данных?

Также вы не должны использовать одну базу данных, с таблицей для пользователей, таблицей для котировок, таблицей для ставок и т. Д.

Затем у вас есть столбец (например,) в таблице котировок, в котором указано, для какого пользователя указана цитата.

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,
    ...
 );

Затем вы используете SQL JOIN s в ваших операторах SELECT, чтобы связать таблицы вместе.

РЕДАКТИРОВАТЬ - вышеизложенное предполагало отношение «многие к одному» между пользователями и тарифами - когда существуют отношения «многие ко многим», вам нужна таблица для каждого вида данных, а затем еще одна таблица со строками для каждого Пользователь <-> Оценить пару.

Answer 3

Две проблемы со многими базами данных (на самом деле их гораздо больше, но начнем с них.)

1. Нельзя использовать параметры для имен баз данных.

2. Что вы будете делать, если внесете свои первые изменения в таблицу? (Подсказка: работа X (# базы данных)).

А "множество таблиц" предполагает, что вы думаете о таблицах на пользователя. Это еще одна не менее проблематичная идея.

Answer 4

Ни. Вы создаете одну базу данных с одной таблицей для каждого типа данных, а затем используете внешние ключи, чтобы связать данные для каждого пользователя вместе. Если бы у вас было всего несколько фиксированных пользователей, это было бы не так плохо, но то, что вы предлагаете, просто не масштабируемо.

Answer 5

Для сравнения, время, когда вам действительно нужны отдельные базы данных, может быть, когда у вас есть несколько клиентов веб-хостинга, которые хотят делать свои вещи с базой данных - тогда вы можете настроить безопасность, чтобы они могли обращаться только к своим собственным данным.

Но если вы пишете код для взаимодействия с базой данных, а не с ними, тогда вам нужны нормализованные таблицы, как описано в нескольких других ответах здесь.

Answer 6

Одна таблица с правильно созданными индексами для каждого необходимого набора сущностей (одна таблица для отправленных котировок, одна таблица для представленных ставок).

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);

Помните: чем больше индексов вы создаете, тем медленнее обновление. Итак, взгляните поближе на то, что вы используете в запросах, и создайте для этого индексы. Хороший учебник по оптимизации баз данных будет иметь неоценимую помощь в понимании того, какие индексы вам нужно создать (я не могу обобщить его в этом ответе).

Я также предполагаю, что вы не знаете о JOINs и FOREIGN KEYs, поэтому обязательно прочитайте и о них. Очень полезно!

Answer 7

Используйте одну базу данных и одну таблицу. Вам потребуется таблица «Пользователь», и эта таблица будет связана (Первичный - Внешний ключ) с этой таблицей.

Answer 8

В чем разница между многими таблицами в одной базе данных или многими базами данных с одинаковыми таблицами? Это для лучшей безопасности или для разных типов резервных копий?

Я не уверен насчет mySQL, но в MSSQL это так:

• Если вам необходимо выполнить резервное копирование баз данных по-разному, вам следует рассмотреть возможность хранения таблиц в разных файлах данных. По умолчанию все они находятся в основном файле. Вы можете указать другое хранилище.

• Все транзакции хранятся в базе данных tempdb. Это не очень хорошо, потому что, если журнал транзакций заполняется, все базы данных перестают работать. Тогда вы можете получить отдельные SQL-серверы для каждого пользователя. Это чепуха, если вы говорите о тысячах клиентов.

Answer 9

у нас похожая система, в которой много пользователей и их соответствующих данных. Мы придерживались подхода единой базы данных и общих таблиц. Таким образом, вы получите одну таблицу, содержащую информацию о пользователях, и таблицу, содержащую все их данные. Наряду с данными у нас есть ссылка на идентификатор пользователя, который помогает нам отделять информацию.

Answer 10

Ваш дизайн имеет недостатки. Вы должны ограничить кортежи, используя внешние ключи, для правильного пользователя, а не добавлять новые сущности для каждой учетной записи.