Помогите правильно спроектировать изменения в схеме данных / Проектирование БД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите правильно спроектировать изменения в схеме данных

18 сообщений из 18, страница 1 из 1

Помогите правильно спроектировать изменения в схеме данных

#35327112

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

Всем привет!

Есть новостной сайт. Он содержит новости, пользовательские комментарии к ним и различные досье. В дальнейшем будут и другие объекты.

Необходимо разработать механизм голосований, чтобы можно было бы голосовать и за новости, и за комментарии, и за различные досье.

Как это можно правильно спроектировать? Первое, что идем на ум:

Код: plaintext

1.
2.
3.
4.
5.
6.

CREATE TABLE MARKS(
  MARK_ID INT PRIMARY KEY,
  MARK_TYPE TINYINT,
  NEWS_ID INT NULL,
  COMMENT_ID INT NULL,
  DOSSIER_ID INT NULL,
  MARK INT);

Здесь MARK_TYPE - это селектор, который определяет, за что голосовали, NEWS_ID, COMMENT_ID и DOSSIER_ID - это внешние ключи на таблицы новостей, комментариев или досье соответственно, MARK - собственно оценка (от 1 до 5, например).

Таким образом, есть MARK_TYPE равно один, например, то приложения знают, что нужно читать идентификатор внешнего ключа с NEWS_ID и делать соединение с NEWS, если что; если MARK_TYPE равно два, то приложения знают, что нужно читать идентификатор для внешнего ключа с COMMENT_ID и джойниться с COMMENTS, и т.д.

Соответственно, программный компонент "отображение среднего бала" будет иметь настройку, и в соответствие с ней рассчитывать оценку за текущий материал/комментарий/досье.

Правильная ли такая схема данных для моей ситуации? Или можно сделать как-то красивее?

Всем заранее спасибо!

...

Рейтинг:

0 / 0

21.05.2008, 18:34

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35328781

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

Смущает еще то, что если придется оценивать другие объекты БД, например авторов текстов, то нужно будет добавлять еще одну колонку и внешний ключ в таблицу MARKS. Правильно ли это?

...

Рейтинг:

0 / 0

22.05.2008, 15:05

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35329365

BrigadeFuhrer

Участник

Сообщения: 71

Рейтинг: 0 / 0

Елси MARK_TYPE уже есть тогда не нужно разделение на NEWS_ID,COMMENT_ID,DOSSIER_ID, пусть это будет общий ENTITY_ID, все равно будет условие по двум полям MARK_TYPE и ID при соединении с контентной таблицой

...

Рейтинг:

0 / 0

22.05.2008, 17:20

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35329373

BrigadeFuhrer

Участник

Сообщения: 71

Рейтинг: 0 / 0

да и на (MARK_TYPE, ENTITY_ID ) повесить юник индекс

...

Рейтинг:

0 / 0

22.05.2008, 17:22

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35329393

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

BrigadeFuhrerЕлси MARK_TYPE уже есть тогда не нужно разделение на NEWS_ID,COMMENT_ID,DOSSIER_ID, пусть это будет общий ENTITY_ID, все равно будет условие по двум полям MARK_TYPE и ID при соединении с контентной таблицой
Спасибо!
Это хорошо при условии, что все PK во внешних таблицах имеют один тип данных (в данном случае INT). А как быть, если, например, в каких-нибудь таблицах будет PK числом, в некоторых строкой а в некоторых, например, датой? Делать по полю на каждый тип первичного ключа?

...

Рейтинг:

0 / 0

22.05.2008, 17:27

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35329507

BrigadeFuhrer

Участник

Сообщения: 71

Рейтинг: 0 / 0

Vetal BrigadeFuhrerЕлси MARK_TYPE уже есть тогда не нужно разделение на NEWS_ID,COMMENT_ID,DOSSIER_ID, пусть это будет общий ENTITY_ID, все равно будет условие по двум полям MARK_TYPE и ID при соединении с контентной таблицой
Спасибо!
Это хорошо при условии, что все PK во внешних таблицах имеют один тип данных (в данном случае INT). А как быть, если, например, в каких-нибудь таблицах будет PK числом, в некоторых строкой а в некоторых, например, датой? Делать по полю на каждый тип первичного ключа?

а есть такие таблицы? если нет ,то плюнуть на это. сложно представить какой-любо другой тип пк для контент таблиц. не ну можно делать по теории - общая таблица голосов связывается через таблицу пересечения с контент таблицей, итого на каждую сцщность будет джойтится 3 таблицы - голоса, голоса_сущности, сущность.

...

Рейтинг:

0 / 0

22.05.2008, 17:51

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35330570

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

BrigadeFuhrerне ну можно делать по теории - общая таблица голосов связывается через таблицу пересечения с контент таблицей, итого на каждую сцщность будет джойтится 3 таблицы - голоса, голоса_сущности, сущность.То-есть, связь многие-ко-многим? А зачем она нужна? Ведь один голос может быть предназначен только за один материал/досье/комментарий... Тут само собой напрашивается связь один-ко-многим...

Или я чего не понял?

...

Рейтинг:

0 / 0

23.05.2008, 10:56

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35330600

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

VetalЗдесь MARK_TYPE - это
.... это лишнее поле, годное только усложнять запросы и провоцировать извраты ....

VetalТаким образом, есть MARK_TYPE равно один, например, то приложения знают, что нужно читать идентификатор внешнего ключа с NEWS_ID и делать соединение с NEWS,
.... типа, например, описанного. В то время как достаточно просто сджойнить по news_id.

...

Рейтинг:

0 / 0

23.05.2008, 11:08

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35330852

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

softwarer VetalЗдесь MARK_TYPE - это
.... это лишнее поле, годное только усложнять запросы и провоцировать извраты ....

VetalТаким образом, есть MARK_TYPE равно один, например, то приложения знают, что нужно читать идентификатор внешнего ключа с NEWS_ID и делать соединение с NEWS,
.... типа, например, описанного. В то время как достаточно просто сджойнить по news_id.
и тогда понять, к какому типу относится коммент, можно по тому, поле для какого внешнего ключа не null?
А какое тогда решение все же лучше?
1) только что предложенное, когда нет селектора MARK_TYPE, и просто джойнится нужная таблица с оценкой по соответствующему внешнему ключу, и в таблице MARK столько же внешний ключей, сколько и возможных объектов-таблиц, за которые можно проголосовать
2) ранее предложенное, когда есть только одно поле типа Object_Id и селектор MARK_TYPE для того, чтобы знать с какой таблицей джойниться
?

...

Рейтинг:

0 / 0

23.05.2008, 12:12

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35330882

egorych

Участник

Откуда: и зачем;

Сообщения: 4 817

Рейтинг: 0 / 0

3) несколько однотипных таблиц на каждый ресурс по отдельности

...

Рейтинг:

0 / 0

23.05.2008, 12:18

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35330899

474

Участник

Сообщения: 273

Рейтинг: 0 / 0

Vetal1) только что предложенное, когда нет селектора MARK_TYPE, и просто джойнится нужная таблица с оценкой по соответствующему внешнему ключу, и в таблице MARK столько же внешний ключей, сколько и возможных объектов-таблиц, за которые можно проголосовать

А зачем нужен соответствующий ключ?
Просто одно поле с внешним ключом на ID объекта. А ID всех объектов уникальны, за счет выделения непересекающихся множеств значения для однородных объектов.

...

Рейтинг:

0 / 0

23.05.2008, 12:22

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331050

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

egorych3) несколько однотипных таблиц на каждый ресурс по отдельностиИ что, так будет лучше?

...

Рейтинг:

0 / 0

23.05.2008, 13:00

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331058

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

474А зачем нужен соответствующий ключ?
Просто одно поле с внешним ключом на ID объекта. А ID всех объектов уникальны, за счет выделения непересекающихся множеств значения для однородных объектов.И что, так будет лучше? А если появится новая таблица, то что - у всех таблиц менять итервалы ключей?

...

Рейтинг:

0 / 0

23.05.2008, 13:02

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331111

474

Участник

Сообщения: 273

Рейтинг: 0 / 0

Vetal 474А зачем нужен соответствующий ключ?
Просто одно поле с внешним ключом на ID объекта. А ID всех объектов уникальны, за счет выделения непересекающихся множеств значения для однородных объектов.И что, так будет лучше? А если появится новая таблица, то что - у всех таблиц менять итервалы ключей?

Вы теоретизируете или вопрос имеет практическое значение?

Если это практика, то это все решается. Например самое простое решение - сделайте интервалы с запасом. Добавьте в начало ключа разряды на новые таблицы.

100 0000000000000001 – первая запись в первой таблице
200 0000000000000001 - первая запись во второй таблице
NNN 0000000000000001 - первая запись во NNN таблице

...

Рейтинг:

0 / 0

23.05.2008, 13:14

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331180

Золотая рыбка

Гость

М.б., что-нибудь такого плана...

Код: plaintext

1.
2.
3.

CREATE TABLE OBJECTTYPE(
  TYPE_ID INT PRIMARY KEY,
  NAME VARCHAR);

Код: plaintext

1.
2.
3.
4.
5.

CREATE TABLE MARKS(
  MARK_ID INT PRIMARY KEY,
  OBJ_ID INT,  
  MARK INT,
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE OBJECTSLIST(
  OBJ_ID INT PRIMARY KEY,
  TYPE_ID INT ,  
  FOREIGN KEY (TYPE_ID) REFERENCES OBJECTTYPE(TYPE_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE NEWS(
  NEW_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE COMMENTS(
  COMMENT_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE DOSSIERS(
  DOS_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Делаем справочник типов объектов (OBJECTTYPE). И единую таблицу для всех объектов (OBJECTSLIST). Таблицы с объектами конкретных типов на нее ссылаются.

...

Рейтинг:

0 / 0

23.05.2008, 13:31

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331225

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

Vetalи тогда понять, к какому типу относится коммент, можно по тому, поле для какого внешнего ключа не null?
Фокус в том, что "понимать" это чаще всего не требуется вообще. Чаще всего требуется просто вывести записи по имеющемуся мастеру. А так - да, именно по not null.

Vetal2) ранее предложенное, когда есть только одно поле типа Object_Id и селектор MARK_TYPE для того, чтобы знать с какой таблицей джойниться
Хм. Скажем так, я по цензурным соображениям не хочу говорить того, что думаю об этом варианте, но в целом я считаю его крайне неудачным. Если существующие БД обзаведутся возможностью вменяемо поддерживать foreign key в таких случаях - можно будет говорить о том, что решение в принципе жизнеспособно.

...

Рейтинг:

0 / 0

23.05.2008, 13:40

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331725

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

Золотая рыбкаМ.б., что-нибудь такого плана...

Код: plaintext

1.
2.
3.

CREATE TABLE OBJECTTYPE(
  TYPE_ID INT PRIMARY KEY,
  NAME VARCHAR);

Код: plaintext

1.
2.
3.
4.
5.

CREATE TABLE MARKS(
  MARK_ID INT PRIMARY KEY,
  OBJ_ID INT,  
  MARK INT,
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE OBJECTSLIST(
  OBJ_ID INT PRIMARY KEY,
  TYPE_ID INT ,  
  FOREIGN KEY (TYPE_ID) REFERENCES OBJECTTYPE(TYPE_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE NEWS(
  NEW_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE COMMENTS(
  COMMENT_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Код: plaintext

1.
2.
3.
4.

CREATE TABLE DOSSIERS(
  DOS_ID INT PRIMARY KEY,
  OBJ_ID INT
  FOREIGN KEY (OBJ_ID) REFERENCES OBJECTSLIST(OBJ_ID));

Делаем справочник типов объектов (OBJECTTYPE). И единую таблицу для всех объектов (OBJECTSLIST). Таблицы с объектами конкретных типов на нее ссылаются.А чем это решение принципиально отличается от того, что я вначале предложил? В чем преимущество именно этого подхода? Мне кажется, так только усложняется схема данных и работа с ними... Или я все же ошибаюсь?

...

Рейтинг:

0 / 0

23.05.2008, 15:40

| Ответить | Цитировать | Написать

Помогите правильно спроектировать изменения в схеме данных

#35331906

Золотая рыбка

Гость

Код: plaintext

А чем это решение принципиально отличается от того, что я вначале предложил?

Отличается тем, что мы вводим некий абстрактный объект (OBJECTSLIST). Независимо от того, сколько типов объектов у вас будет на самом деле (NEWS, COMMENTS, DOSSIERS и так далее) в таблице MARKS будет только одно поле, ссылающееся на OBJECTSLIST. В таблицы конкретных типов (NEWS, COMMENTS....) добавляется внешний ключ на OBJECTSLIST - так реализуем наследование.
Таким образом для добавления нового типа объекта достаточно создать новую таблицу (скажем, AUTHORS - также с FK на OBJECTSLIST) и добавить соответствующую запись в справочник типов. Новые колонки в таблицу MARKS не добавляются.
При этом сохранится контроль за ссылочной целостностью, что, к сожалению, невозможно, если использовать вариант

Код: plaintext

'одно поле типа Object_Id и селектор MARK_TYPE '

...

Рейтинг:

0 / 0

23.05.2008, 16:25

| Ответить | Цитировать | Написать

18 сообщений из 18, страница 1 из 1

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=32&msg=35330600&tid=1543857]:	0ms
get settings:	12ms
get forum list:	20ms
check forum access:	4ms
check topic access:	4ms
track hit:	194ms
get topic data:	12ms
get forum data:	3ms
get page messages:	74ms
get tp. blocked users:	2ms
others:	244ms

total:	569ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы