Предложить улучшения для дизайна базы данных

Question

Дизайн: -

1) На раскадровке есть несколько слайдов, каждый слайд может содержать одну или несколько подписей или изображений.

2) Каждая раскадровка может иметь одного или нескольких авторов и ноль или более рецензентов.

3) Каждый из объектов изображения, слайда и подписи (возможно, больше объектов появится позже, например, аудио и т. Д.) Может иметь комментарии к ним. Эти комментарии могут быть предоставлены авторами или рецензентами. Для хранения комментариев я создал таблицу комментариев.

4) Необходимо запомнить порядок слайдов и порядок изображений на слайде, для чего я использую поля слайдов и номеров изображений.

5) Поскольку комментарий можно дать для любого объекта, мне нужно было иметь глобальный идентификатор для каждого объекта, так как их ссылка будет сохранена в таблице комментариев. Для поддержания глобального идентификатора все поля, заканчивающиеся именем GID являются уникальными идентификаторами, сгенерированными с использованием Default: NEWID ().

6) Пользователи хранятся в пользовательской таблице.

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

Пожалуйста, предложите улучшения для этого дизайна БД.

Answer 1

я вижу, что не во всех ваших таблицах есть PK, на самом деле я вижу только, что в пользовательской таблице есть один, а раскадровка использует имя и владельца в качестве PK?

Я предпочитаю использовать идентификатор длявсе мои таблицы, кроме промежуточных таблиц, используемых для отношения NxN, как вы делали для авторов и рецензентов.Ты сделал то же самое, но назвал это GID.Я бы использовал их в качестве ПК (и также автоматически).

Не беспокойтесь, если объект имеет тот же GID, что и другой объект в другой таблице, потому что в вашей таблице комментариев у вас есть ObjType, который определяет таблицу, связанную с объектом.Так что все будет в порядке, если GID пользователя такой же, как GID StoryBoard.

Я не привык к диаграммам sql-сервера, но кажется, что отношения не очень хорошо определены: я вижу этого пользователяи раскадровка связаны в 1xN, но похоже, что раскадровка и слайды связаны в отношении 1x1, когда оно также должно быть 1xN

Раскадровка имеет владельца и разных авторов, это означает, что если ясоздать раскадровку, раскадровка будет иметь мой идентификатор в OwnersUserId, а мой идентификатор также будет храниться в таблице авторов?если да, то кажется ненужнымИли .. ну .. это зависит от концепции вашей модели.Я вижу два варианта:

• a StoryBoard имеет ОДНОГО автора и ОДНОГО ИЛИ МНОГО соавторов

  (не меняйте свою модель, только переименуйте таблицу авторов в соавторов или что-то более точное)

• a StoryBoard имеет ОДНОГО ИЛИ БОЛЕЕ авторов, и один из них является владельцем

  (удалите отношение 1xN между пользователями и раскадровкой и добавьте столбец type втаблица авторов)

Последнее замечание:

Пользователь должен иметь возможность просматривать и загружать только созданные им раскадровки.

это не изменит модель данных .. =) но если только авторы смогут просматривать раскадровки, то кто их будет просматривать?

Мои наблюдения просто поверхностны, я считаю, что модель хорошо приспособлена кпроблема

удачи