ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
16 сообщений из 16, страница 1 из 1
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740572
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Добрый день Товарищи!

Подскажите пожалуйста, в таком вопросе:
Есть допустим такой набор взаимосвязанных сущностей как местоположение: Планета , Континент , Страна ....
И к примеру я хочу каждую из этих сущностей иметь возможность "оценивать", т.е. ставить плюсик.

Как мне весь набор оценок в базе лучше хранить?
Отдельными таблицами Планета_оценки , Континент_оценки , Страна_оценки ... Или имеет смысл в одной широкой таблице хранить всё:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
TABLE Сущности_оценки (
      id     SERIAL PRIMARY KEY,
 planetID TINYINT UNSIGNED,
 continentID SMALLINT UNSIGNED,
 countryID INT UNSIGNED,
 ....
   userID BIGINT UNSIGNED NOT NULL,
   ocenka TINYINT NOT NULL,
   FK (planetID) ....
   FK (continentID) ....
   FK (countryID) ....
   FK (userID) ....
)


В этой таблице для полей сущностей подразумевается что возможен NULL и в случае указания оценки для какой-то сущности, подразумевается что значит значения её вышестоящих сущностей тоже будут известны, т.е. не NULL.

Варианты что условно город сменит страну и в этой таблице надо будет все связи для оценок уровня этого города и ниже сменить countryID - неважны. Подразумевается что иерархия сущностей задана жостко и без изменений подчинённости.
Сущности принципиально различны, т.е. реализовать сущности и их иерархию "односвязным списком" невозможно. Каждая сущность в своей таблице и у неё свои задачи в системе :)
...
Рейтинг: 0 / 0
29.11.2018, 21:32
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740587
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kormotли имеет смысл в одной широкой таблице хранить всё:

Имеет смысл хранить всё в одной узкой таблице "оценка" с полями "ид оцениваемой сущности"
и "оценка". А всё прочее барахло - в другой одной таблице "сущность, поддающаяся оценке".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.11.2018, 22:03
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740588
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
Дмитрий , я не совсем понял вашего предложения. У меня сущности в БД хранятся в разных таблицах. Как например в таблице "оценки" я различу плюсик для планеты с ID=1 и страны с ID=1?
...
Рейтинг: 0 / 0
29.11.2018, 22:06
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740599
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Имеет или не имеет смысл это вам решать (зависит от того как вы использовать будете)

В одной таблице вполне можно, но писать check уже для четырех полей геморно
Код: sql
1.
2.
3.
4.
   (planetid is not null and  continentid is null and countryid is null and userid is null)
or (planetid is null and  continentid is not null and countryid is null and userid is null)
or (planetid is null and  continentid is null and countryid is not null and userid is null)
or (planetid is null and  continentid is null and countryid is null and userid is not null)



Вздумаете расширятся на галактику - повеситесь
...
Рейтинг: 0 / 0
29.11.2018, 22:41
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740610
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
kormot Дмитрий , я не совсем понял вашего предложения. У меня сущности в БД хранятся в разных таблицах. Как например в таблице "оценки" я различу плюсик для планеты с ID=1 и страны с ID=1?
По дискриминатору
...
Рейтинг: 0 / 0
29.11.2018, 23:08
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740615
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kormotУ меня сущности в БД хранятся в разных таблицах.

А зачем Вы разнесли одну сущность на четыре таблицы? ССЗБ-мазохист?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
29.11.2018, 23:18
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740638
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
SERG1257В одной таблице вполне можно, но писать check уже для четырех полей геморно
Такой проверки не предполагается, только AND варианты. Т.е. например найти только оценки для такой-то планеты.

skyANAПо дискриминатору
А дискриминатор, это что такое?

Dimitry SibiryakovА зачем Вы разнесли одну сущность на четыре таблицы? ССЗБ-мазохист?..
Дмитрий, разные тут сущности. Если вы о том что эти конкретно (местоположения) это одна сущность не нуждающаяся в оформлении разными таблицами, то это я просто привёл пример на них. Сущности принципиально разные, но между собой связанные. И оценки можно ставить к каждой сущности.
...
Рейтинг: 0 / 0
30.11.2018, 05:33
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740639
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
skyANAПо дискриминатору
Почитал что такое дискриминатор, т.е. это у каждой записью с оценкой ещё есть поле "ТипСущности" к которой эта оценка и соотв-но чей id указан.
Я об этом варианте думал (просто не знал что это дискриминатор), но подумал что это некорректно. Опять же из антипаттернов указание на то, что "не надо делать в БД связь ключа с таблицей определяемой значением какого-то из полей". Это в данном случае не играет важной роли?
...
Рейтинг: 0 / 0
30.11.2018, 06:31
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740699
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
kormot,

Мы делаем что-то подобное. Но...Из таблицы надо убрать id-шники сущностей, оставить один. И добавить признак, отвечающий за сущность. Тогда добавление ещё сущности гораздо проще. Но есть минусы. Целостность, нормализация и что там ещё...
Либо сущности хранить в одной таблице.
Есть ещё вариант. Сделать маленькую основную таблицу с тремя полями (как фундамент): id, priznak, id2. Её связать со всеми другими. Например, при признаке=1 связь с таблицей описания планеты, 2 - континент..., 8 - с таблицей оценки (для планеты), 9 - с таблицей оценки (для континента). Но тут надо где-то хранить ссылку на описание сущности. Можно с таблице оценок. И проблемы с FK не будет.
...
Рейтинг: 0 / 0
30.11.2018, 10:29
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740739
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
KreatorXXIМы делаем что-то подобное. Но...Из таблицы надо убрать id-шники сущностей, оставить один. И добавить признак, отвечающий за сущность. Тогда добавление ещё сущности гораздо проще. Но есть минусы. Целостность, нормализация и что там ещё...
Либо сущности хранить в одной таблице.
Есть ещё вариант. Сделать маленькую основную таблицу с тремя полями (как фундамент): id, priznak, id2. Её связать со всеми другими. Например, при признаке=1 связь с таблицей описания планеты, 2 - континент..., 8 - с таблицей оценки (для планеты), 9 - с таблицей оценки (для континента). Но тут надо где-то хранить ссылку на описание сущности. Можно с таблице оценок. И проблемы с FK не будет.
Ну вот первый ваш вариант, это как раз я так понимаю от SkyANA предложение с дискриминатором.
А второй вариант, это вроде бы тот же самый что и первый, или я не понял? :)
...
Рейтинг: 0 / 0
30.11.2018, 11:11
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740869
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
kormot,

Второй - это третий? Если считать вторым предложение хранить сущности в одной таблице. В первом варианте проблемы с целостностью на уровне сервера. Т.е. FK отсутствуют как класс. А в третьем можно построить правильную схему на уровне сервера. Но тут реализация сложно-непрозрачная. А чем сложнее система, тем хуже.
Что мешает сущности загнать в одну таблицу? Поля слишком разные? Память оперативную/неоперативную экономите? Может банально дерево сущностей не можете построить?
...
Рейтинг: 0 / 0
30.11.2018, 14:02
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740880
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
kormot,

Второй - это третий? Если считать вторым предложение хранить сущности в одной таблице. В первом варианте проблемы с целостностью на уровне сервера. Т.е. FK отсутствуют как класс. А в третьем можно построить правильную схему на уровне сервера. Но тут реализация сложно-непрозрачная. А чем сложнее система, тем хуже.
Что мешает сущности загнать в одну таблицу? Поля слишком разные? Память оперативную/неоперативную экономите? Может банально дерево сущностей не можете построить?
...
Рейтинг: 0 / 0
30.11.2018, 14:09
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740884
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
kormot,

Второй - это третий? Если считать вторым предложение хранить сущности в одной таблице. В первом варианте проблемы с целостностью на уровне сервера. Т.е. FK отсутствуют как класс. А в третьем можно построить правильную схему на уровне сервера. Но тут реализация сложно-непрозрачная. А чем сложнее система, тем хуже.
Что мешает сущности загнать в одну таблицу? Поля слишком разные? Память оперативную/неоперативную экономите? Может банально дерево сущностей не можете построить?
...
Рейтинг: 0 / 0
30.11.2018, 14:10
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740885
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
kormot,

Второй - это третий? Если считать вторым предложение хранить сущности в одной таблице. В первом варианте проблемы с целостностью на уровне сервера. Т.е. FK отсутствуют как класс. А в третьем можно построить правильную схему на уровне сервера. Но тут реализация сложно-непрозрачная. А чем сложнее система, тем хуже.
Что мешает сущности загнать в одну таблицу? Поля слишком разные? Память оперативную/неоперативную экономите? Может банально дерево сущностей не можете построить?
...
Рейтинг: 0 / 0
30.11.2018, 14:12
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740911
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kormot
Участник
KreatorXXIВторой - это третий?
Да, получается про третий имел в виду.
KreatorXXIВ первом варианте проблемы с целостностью на уровне сервера. Т.е. FK отсутствуют как класс.
Т.е. я правильно понимаю, что имеется в виду хранение сущностей в таком виде:
Код: sql
1.
2.
3.
4.
5.
6.
TABLE (
   id     SERIAL PK,
   entityType CHAR(32) NOT NULL,
   entityID  BIGINT,
   value INT
)

Это вариант как я понял с дискриминатором, которым является тут entityType
А третий вариант как выглядит? Как я его понял, это такой же вариант как №1, только в качестве дискриминатора выступает priznak ?
Если нет, то покажите пожалуйста таблицами что имеется в виду? Как связь с таблицей реализуется в зав-ти от priznak ? Я вижу только на основе динамического формирования запроса на уровне приложения. Но это тоже как-то коряво.
...
Рейтинг: 0 / 0
30.11.2018, 14:25
| Ответить | Цитировать | Написать  
Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
    #39740994
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
[quot kormot]
Т.е. я правильно понимаю, что имеется в виду хранение сущностей в таком виде:
Код: sql
1.
2.
3.
4.
5.
6.
TABLE (
   id     SERIAL PK,
   entityType CHAR(32) NOT NULL,
   entityID  BIGINT,
   value INT
)

Это вариант как я понял с дискриминатором, которым является тут entityType
Вот так я понимаю таблицу оценки. А таблиц сущностей при этом несколько. Только EntityType можно типа byte. Повторюсь, целостность на уровне клиента.
Второй вариант пропустим пока. Для меня самый предпочтительный.
Третий вариант может выглядеть так:
MainTable. Поля - id, pid, priz.
PlanetTable. Поля - id, pid (FK на id MainTable), name, ...
ContinentTable. Поля - id, pid (FK на id MainTable), name, ...
и т.д.
Таблицы других сущностей добавляются аналогично.
EvaluationTable (таблица оценок). Поля - id, pid (FK на id MainTable), value, ...
Как заполняются? Допустим, на примере планет.
Создаётся запись в MainTable. id=1, pid=null, priz=1.
К ней по связи один к одному создаётся запись в PlanetTable. id=1, pid=1 (ссылка на MainTable), name='Земля'.
Вторая планета.
Создаётся запись в MainTable. id=2, pid=null, priz=1.
К ней по связи один к одному создаётся запись в PlanetTable. id=2, pid=2 (ссылка на MainTable), name='Марс'.
Создаём оценки к планетам.
Создаётся запись в MainTable. id=3, pid=1 (ссылка на запись планеты Земля в этой же таблице), priz=5.
К ней по связи один к одному создаётся запись в EvaluateTable. id=1, pid=3 (ссылка на MainTable), value='?'.
Создаётся запись в MainTable. id=4, pid=2 (ссылка на запись планеты Марс в этой же таблице), priz=5.
К ней по связи один к одному создаётся запись в EvaluateTable. id=2, pid=4 (ссылка на MainTable), value='?'.
В MainTable значения поля priz могут быть такими: 1 - планеты, 2 - континенты, 3 - страны, 4 - города, 5 -оценки.
FK строятся без проблем. Причём нужно построить и FK в таблице MainTable по полю pid. Т.е. некое дерево. Допустим, при удалении планеты Земля по каскаду можно удалить и оценку планеты Земля. Опять же континенты по полю pid можно связать с планетами, страны с континентами, города со странами...
...
Рейтинг: 0 / 0
30.11.2018, 15:28
| Ответить | Цитировать | Написать  
16 сообщений из 16, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли данные одного типа для разных сущностей хранить в одной таблице?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?desktop=1&fid=32&tid=1539981]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 47ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 50ms
get tp. blocked users:
 2ms
others: 231ms
total:  378ms
созд. / загр.: 378ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]