Есть общий справочник (Dictionary) названий, юзер (Users) может на основе общего справочника формировать свой:
1) использовать существующие строки по внешнему ключу
2) добавлять собственные названия (Name), которых нет в общем справочнике

На основании этих действий формируется свой личный справочник юзера (UserDictionary).


Как должен выглядеть Userdictionary?

Что не нравится в текущей версии - наличие null-полей. Люблю, когда таких в БД минимальное количество, а тут - либо в записи DictionaryId, либо Name

Руслан Дамирович,

Вариант, спасибо.
А в таблице Dictionary сделать уникальность на названия?

Руслан Дамирович,

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



(На Dictionary уникальный ключ на поле Name)

ViPRosРуслан Дамировичblest,

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

Тут согласен, даже если не подниматься на уровни выше, я и в целом за то, чтобы первичные ключи во всех таблицах были идентичные по типу - в данном случае это поле Id. На UserId и DictionaryId естественно уникальный ключ.
Я не знаю насколько важно юзер-источник записи в Dictionary, но в целом можно дополнить таблицу Dictionary внешним ключом UserId

blestViPRosпропущено...

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

Тут согласен, даже если не подниматься на уровни выше, я и в целом за то, чтобы первичные ключи во всех таблицах были идентичные по типу - в данном случае это поле Id. На UserId и DictionaryId естественно уникальный ключ.
Я не знаю насколько важно юзер-источник записи в Dictionary, но в целом можно дополнить таблицу Dictionary внешним ключом UserId

Хотя это тоже не нужно (поле UserId в Dictionary) - я в своих таблицах также всегда добавляю полусистемное поле Created datetime и Deleted datetime. Т.о. можно простым запросом найти первого добавившего интересующего запись из таблицы UserDictionary.

vmagЗлой БобрА не проще при такой схеме в Dictionary добавить UserId и не делать таблицу UserDictionary от слова совсем?..

+
Ключевое тут при такой схеме (я о второй схеме)...
Таблица в которой кроме ID ничего нет - это избыточная таблица (тупой балласт)...

Вы о каком балласте UserDictionary?

Бредятинаblest,
Вы находитесь в разделе "Проектирование баз данных". А все, что Вы пишете, связано с так называемыми "реляционными базами данных". В базах данных нет "ключей", в смысле "реляционных баз данных", и нет никаких проблем, которые Вы здесь обсуждаете.
Еще раз предлагаю администраторам переименовать раздел в "Проектирование реляционных баз данных", чтобы не дискредитировать проектирование баз данных:)

А много здесь тем по NoSQL БД ?

Проще заголовок переименовать "Справочники пользователей, на основе общего справочника в MS SQL Server 2014"