Как лучше построить базу данных

Question

У нас есть БД на SQL, где у нас есть таблица (1) для пользователей и таблица (2) для сохраненной информации пользователя. Каждая часть информации является одной строкой в ​​таблице (2). Поэтому мой вопрос заключается в следующем: если мы намерены увеличить количество пользователей до более чем 1.000.000, и каждый пользователь может иметь более 10 частей информации, из которых следующий является лучшим способом построения нашей БД:

a) Наличие 2 таблиц - 1 для пользователей и 1 для информации от всех пользователей, относящихся к пользователям с ID

b) Наличие отдельной таблицы для каждого пользователя.

Заранее спасибо.

Answer 1

Определенно, он должен иметь отдельную таблицу для пользователя намного лучше. Подумайте о перспективах БД. Вы хотите узнать время поиска в строке 1.000.000 для сортированного идентификатора. Во втором случае вам нужно искать таблицу 1.000.000, чтобы попасть в правый стол. Так лучше пойти на опцию A.

Answer 2

Я согласен, что вариант A является лучшим из представленных двух вариантов.

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

SQL на самом деле не масштабируется по горизонтали, поэтому, если вы в конечном итоге получаете меньше или больше информации, чем другие, то у вас будут столбцы NULL, и это требует иметь дело с различными способами.

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

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

Вариант B не плох, он просто не подходит для SQL. Я бы работал, если бы рассматриваемая БД была основана на документе вместо таблиц. В этом случае создание единого документа для каждого пользователя является хорошей идеей и, вероятно, предпочтительным.

Answer 3

Вариант C) таблицы для пользователей с уникальным UserID в качестве кластерного индекса (Первичный ключ) таблицы для типа сохраненной информации с уникальным InformationID как кластерный индекс (Primary Key) стола для UserInformation с уникальным UserInformationID как индекс кластерного (Первичный ключ), столбец для UserID (некластеризованный индекс, внешний ключ для таблицы пользователя) и столбец InformationID (некластеризованный индекс, внешний ключ к таблице информации). Имейте «Значение» или аналогичный столбец для хранения сохраняемых данных, относящихся к типу информации.

Пример: Таблица Пользователей

UserID UserName 
1  | UserName1 
2  | UserName2 

Информация Таблица

InfoID InfoName 
1  | FavoriteColor 
2  | FavoriteNumber 
3  | Birthday 

UserInformation Таблица

ID UserID InfoID Value 
1  | 1  | 1  | Blue 
2  | 1  | 2  | 7 
3  | 1  | 3  | '11/01/1999' 
4  | 2  | 3  | '05/16/1960' 

Этот метод позволяет сохранять любую комбинацию значений для любого пользователя без записи любой из предоставленной пользователем информации.Он сохраняет таблицу данных «чистой», потому что вам не нужно будет добавлять столбцы для каждой новой части информации, которую вы хотите отслеживать. Просто добавьте новую запись в таблицу Info, а затем запишите только значения, представленные в таблицу UserInformation.