Возможность денормализации базы данных

Question

Я ищу стратегию, позволяющую остановить повторяющуюся проблему разветвления таблиц. Например, в качестве вымышленного варианта использования, скажем, у меня есть таблица с пользователями, которая содержит их имя, логин, пароль и другие метаданные. В этом конкретном сценарии, скажем, пользователь ограничен входом в систему для определенного подмножества IP-адресов. Таким образом, мы имеем отношение 1: M. Каждый раз, когда возникает вариант использования, такой как следующий, ваш обычный рабочий процесс включает в себя тот, у которого есть таблица 'users' и таблица, такая как 'user_ips', в этом случае у вас будет что-то вроде pk (ip_id), fk ( user_id) и IP на стороне user_ips.

В подобных ситуациях вы, как обычно, развлекаетесь, как описано выше? Есть ли здесь возможность эффективно денормализовать? Может быть, хранить IP-адреса в столбце BLOB каким-либо образом с разделителями CSV? Какие стратегии вы, ребята, используете сегодня?

Answer 1

Возможность денормализовать? Я думаю, что вы, возможно, неправильно поняли традиционную мудрость - денормализация - это метод оптимизации Не то, что вы ищите.

Answer 2

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

Имейте это в виду. Если вам необходимо реализовать безопасный доступ на основе ролей к частям информации, безопасность на основе таблиц НАМНОГО проще реализовать, чем на основе столбцов, особенно на уровне базы данных или уровня данных.

Answer 3

Я бы настоятельно рекомендовал против , помещая несколько IP-адресов в поле. Не берите в голову 3NF, это ломает 1NF.

Tvanfsson прав в том, что если вы индексируете FKEY, вы получите довольно сопоставимую производительность, если в таблице 'users_ips' не будет миллионов записей.

Что еще лучше, так это то, что, если эти таблицы будут нормализованы, вы сможете в будущем сообщать об этой информации, чтобы, когда пользователи не понимали, почему они не могли войти в систему из определенных локальных сетей, создавали приложение (или SQL) для устранения неполадок и поиск пользователей по IP будет проще A LOT .

Answer 4

Как и в случае любого вопроса о денормализации, вам необходимо учитывать связанные с ним расходы. В частности, если вы перечислите IP-адреса в основной таблице, как вы сможете ответить на вопрос «каких пользователей можно связать с IP-адресом w.x.y.z?». С полностью нормализованной формой это легко и симметрично с «какими IP-адресами можно связать пользователя pqr?». С денормализованными формами вопросы имеют очень разные ответы. Кроме того, в денормализованной версии, в целом, обеспечить применение правильных правил целостности намного сложнее.

Answer 5

Один из вариантов будет хранить ваши IP-адреса в виде строки XML. Я думаю, что это будет лучше, чем список, разделенный запятыми, и позволит вам гибко добавлять другие элементы в строку, если они вам понадобятся (порт приходит в голову) без изменений в базе данных.

Хотя я думаю, что нормализованная мода лучше в большинстве случаев.

Answer 6

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

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

Очевидно, что это не единственные примеры требований, которые диктуют нормализованное решение.

В то же время я считаю, что таких требований, как «Показать все IP-адреса пользователя» или «Показать всех пользователей, связанных с данным IP-адресом», может быть недостаточно для обоснования нормализованного решения.

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

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

Никогда не говори «никогда»: 3NF не всегда лучший ответ.

Answer 7

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

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

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