Правильная схема стола - PullRequest
Новая
       22

Правильная схема стола

2 голосов
/ 10 октября 2010

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

Объем рассматриваемой области:

  • Пользователь загружает документы (становится владельцем / автором)

  • Пользователь может делиться документом с другими пользователями (установить права доступа)

  • Любой пользователь, имеющий доступ к документу, может оформить документ (эксклюзивная блокировка)

Моя исходная схема выглядит следующим образом:

alt text

Преимущества:

  • Автором может быть только один пользователь.(authorid)

  • Таблица прав содержит только "sharerights" (Чтение, Запись)

  • Пользователь может легко различать, какие файлы ему принадлежатmsgstr "(authorid) против общих файлов (таблица общих файлов).(это слабое преимущество, я знаю)

Подумав, я подумал, что это может быть лучшая схема:

alt text

Преимущества:

  • Все ассоциации документов расположены в одном месте (UserFiles)

  • Возможность в будущем разрешить нескольким авторам / владельцуотдельный документ

Таблица прав теперь будет иметь права «Чтение», «Запись» и «Владелец».Как только документ был загружен пользователем, для нового документа будет автоматически установлена ​​ассоциация, и пользователю будут предоставлены права «владельца».

Это привело меня к окончательной схеме:

alt text

Преимущества:

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

Единственная проблема с этой последней моделью состоит в том, что я планирую добавить «специального» пользователя для каждого отдела, чтобы пользователь мог поделиться документом со всем отделом.Поэтому я не уверен, хочу ли я связать ассоциацию акций с checkoutID (если это имеет смысл).Запрос к файлам пользователей будет выглядеть так: «выбрать все файлы, где userfiles.userid = me.userid || (userfiles.id == SpecialDepID && me.depid == SpecialDepID)» (основной псевдокод)

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

ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ

С помощью Майкла Мэдсена окончательное решение выглядит следующим образом:

alt text

Будет создан триггер для пользовательских файлов для удалениякоторый будет определять, следует ли удалять блокировку при удалении отношения.

1 Ответ

1 голос
/ 10 октября 2010

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

Вы 'У нас уже есть веские причины для выбора этого варианта вместо первого, поэтому я не собираюсь повторять это.

Третий дизайн, тем не менее, не очень хорош - непросто увидеть, заблокирован ли файл;Вы должны увидеть, существует ли sharedFileID, если fileID совпадает с тем, который вам нужен, то есть несколько записей на таблицу.Также нехорошо, что вы пропускаете первичный ключ в CheckedOutFiles, так что он также учитывается.

Однако мы, конечно, можем решить эти проблемы.Если бы вы использовали FileID в качестве первичного ключа в CheckedOutFiles, вы бы смогли избежать этих двух проблем - у вас есть значимый первичный ключ, и вы можете легко проверить, заблокирован ли данный файл.

КонечноДаже если вы это сделаете, у вас все равно будет проблема «специального» пользователя.Простой способ, который вы можете использовать для обработки этого, заключается в сохранении фактического пользователя как части вашей таблицы проверки - sharedFileID ссылается на пользователя отдела, в то время как у вас все еще есть ссылка на фактического пользователя, чтобы убедиться, что вы имеете дело с нужным пользователем.

С этими изменениями третий дизайн кажется лучшим - вы резервируете место только для информации о блокировке для файлов, которые фактически заблокированы.

TL; DR: третий дизайн, но с fileID в качествеPK в CheckedOutFiles и определенный идентификатор пользователя как часть CheckedOutFiles для обработки «мета» -использующих.

...