Сокращение повторяющейся информации в дизайне базы данных - PullRequest
3 голосов
/ 30 ноября 2010

Я разрабатываю приложение, которое, когда пользователи создают новую учетную запись, их учетная запись заполняется несколькими сотнями строк данных (предопределенные параметры, настройки и т. Д.). Большинство пользователей редко, если вообще изменят информацию, содержащуюся в этих таблицах. Существуют ли хорошие шаблоны проектирования для уменьшения количества дублирующихся данных в таблицах базы данных?

Некоторые идеи, которые у меня были до сих пор:

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

  • Создать новый база данных для каждых 100 пользователей или около того, с отдельной базой данных для аккаунтов это указывает на базу данных пользователей. Это, ну, не оптимально.

  • Идея 3?

Ответы [ 5 ]

1 голос
/ 30 ноября 2010

Создание новой базы данных для 100 пользователей звучит как сумасшедшая и неэффективная идея.

Сколько данных мы говорим и почему вы хотите их уменьшить?Даже если у вас миллионы пользователей, несколько миллионов строк - это не очень большая таблица - если только данные для каждого пользователя не имеют размер в несколько мегабайт.Правильно подобранного индексирования должно быть достаточно для оптимизации пользовательской таблицы.Однако это может упростить изменение настроек по умолчанию для всех пользователей, если вы сохраняете настройки пользователя только тогда, когда они меняют настройки по умолчанию.

0 голосов
/ 30 ноября 2010

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

На уровне пользователя создайте только «исключения», т.е. только значения, которые были изменены пользователем, и всегда обращайтесь к профилю как к соединению между соответствующим базовым профилем и пользовательскими исключениями (которые, будем надеяться, будут пустыми). т.е. не существует в БД).

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

0 голосов
/ 30 ноября 2010

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

0 голосов
/ 30 ноября 2010

посмотрите статистику использования полей и объедините их, которые обычно изменяются, чтобы, если для этого пользователя не было записи для тех редко изменяемых полей, они возвращались к значениям по умолчанию

я думаю, что был способ с объединением или что-то, чтобы сделать значения по умолчанию как этот

0 голосов
/ 30 ноября 2010

НЕТ , не создавайте новую базу данных для любого количества пользователей.

Придерживайтесь варианта 1.

Или даже настроить группы пользователей с выбранными опциями / примененными правилами.

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

Вам нужно реализовать от Users до UserGroups до UserRoles и UserRules

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

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