Хранение предпочтений / отношений один-к-одному в базе данных

Question

Каков наилучший способ сохранить настройки для определенных объектов в моей базе данных?

1. Метод первый: использование таблицы single
   Таблица: Company {CompanyID, CompanyName, AutoEmail, AutoEmailAddress, AutoPrint, AutoPrintPrinter}

2. Второй метод: использование двух таблиц
   Стол компании {CompanyID, COmpanyName}
   Таблица2 CompanySettings {CompanyID, utoEmail, AutoEmailAddress, AutoPrint, AutoPrintPrinter}

Answer 1

Я бы рассмотрел, если вам нужна одна или две таблицы на основе следующих критериев:

Сначала вы закрываете лимит хранения записей, затем две таблицы определенно.

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

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

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

Answer 2

Я бы пошёл дальше ...

Таблица 1 - Компания

CompanyID (int)
CompanyName (string)

Пример

CompanyID 1
CompanyName "Swift Point"

Таблица 2 - Типы контактов

ContactTypeID (int)
ContactType (string)

Пример

ContactTypeID 1
ContactType "AutoEmail"

Таблица 3 Контакты компании

CompanyID (int)
ContactTypeID (int)
Addressing (string)

Пример

CompanyID 1
ContactTypeID 1
Addressing "name@address.blah"

Это решение обеспечивает расширяемость, поскольку вам не нужно добавлять столбцы, чтобы справляться с новыми типами контактов в будущем.

SELECT
   [company].CompanyID,
   [company].CompanyName,
   [contacttype].ContactTypeID,
   [contacttype].ContactType,
   [companycontact].Addressing
FROM
   [company]
INNER JOIN
   [companycontact] ON [companycontact].CompanyID = [company].CompanyID
INNER JOIN
   [contacttype] ON [contacttype].ContactTypeID = [companycontact].ContactTypeID

Это даст вам несколько строк для каждой компании. Строка для «AutoEmail», строка для «AutoPrint» и, возможно, в будущем строка для «ManualEmail», «AutoFax» или даже «AutoTeleport».

Ответ HLEM.

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

Если вы не хотите использовать модель EAV, вам следует рассмотреть реляционные таблицы, а не хранить данные в плоских таблицах. Это потому, что эти данные почти наверняка расширятся.

Ни EAV-модель, ни реляционная модель существенно не замедляют запросы. Объединения на самом деле очень быстрые по сравнению с (например) своего рода. Возврат записи для компании со всеми связанными с ней типами контактов или даже с конкретным типом контакта будет очень быстрым. Я работаю над финансовой базой данных MS SQL с миллионами строк и аналогичными моделями данных, и у меня нет проблем с возвратом значительных объемов данных за доли секунды.

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

Answer 3

Обычно, если у вас нет дублирования данных, тогда подходит одна таблица.

В вашем случае вы не так, первый способ в порядке.

Answer 4

Я использую одну таблицу, если, по моим оценкам, данные из «второй» таблицы будут использоваться более чем в 50% моих запросов. Используйте две таблицы, если мне нужно несколько копий данных (то есть несколько телефонных номеров, адресов электронной почты и т. Д.)

Answer 5

Это зависит от того, понадобится ли вам когда-либо больше информации о компании. Если вы заметили, что добавляете такие поля, как companyphonenumber1 companyphonenumber2 и т. Д. И т. Д., То способ 2 лучше, так как вы разделяете свои сущности и просто ссылаетесь на идентификатор компании. Если вы не планируете вносить эти изменения и чувствуете, что эта таблица никогда не изменится, метод 1 подойдет.