|
|
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
Доброго дня! Есть допустим одна сущность, например "заявки" Код: sql 1. 2. 3. 4. И много разных сущностей к которым заявки могут быть прикреплены, допустим это: "Автомобили", "Здания", "Оборудование". Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Стоит ли организовывать связь между заявками и разными сущностями не через отдельные таблицы autoZayavkaRel, buildingZayavkaRel, tehZayavkaRel в которых всё правильно с внешними ключами, а таким образом: Код: sql 1. 2. 3. 4. 5. 6. Какие минусы у такого способа организации связи между сущностями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 13:50 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
А какой смысл в этой промежуточной таблице? И да - поле zayavkaID не может быть SERIAL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 14:39 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
Akina, смысл примерно такой же как у любой другой связующей таблицы. SERIAL - описка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 14:46 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
Да никакого смысла. Возьми первую схему. Этап 1. Добавь в неё поле objType (мотивируя тем, что можно без обращения к таблицам частных сущностей определить, к какой заднице прикручена заявка). Этап 2. Полученную таблицу раздели на две в строгом соотношении 1:1. В итоге получишь вторую схему. Так вот - если первый этап хоть чем-то обоснован, то второй - полный тупизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 16:13 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
Akina, ты уж извини, не знаю чем это обосновано, но я не понял что ты рассказал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 19:06 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
В описании кстати серьёзная ошибка, гораздо критичней чем неверно указанный SERIAL :) Код: sql 1. 2. 3. 4. 5. 6. 7. А то связи с объектом никакой нет у заявок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 19:11 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
А стоит или нет я имею в виду вопросы с производительностью. Если в одной таблице для связи со всеми типами объектов по ключу (objType, objectID) UNIQUE . Удобство например в том, что можно написать один запрос для разных типов объектов и распределять уже что и как отображать на уровне приложения. Из минусов - это отсутствие гарантированной связности. Что если удалится допустим строка из automobil , то повиснет бесхозная связь ("automobil", [autoID]) . Но такие записи подчистить периодически не составляет никакого труда. Или думаю такой способ хранения связей между сущностями использовать для каких-то маловажных в приложении данных. Наример там логи действий пользователя, или всякие стат. данные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 19:20 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
kormotДоброго дня! Есть допустим одна сущность, например "заявки" Код: sql 1. 2. 3. 4. И много разных сущностей к которым заявки могут быть прикреплены, допустим это: "Автомобили", "Здания", "Оборудование". Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Стоит ли организовывать связь между заявками и разными сущностями не через отдельные таблицы autoZayavkaRel, buildingZayavkaRel, tehZayavkaRel в которых всё правильно с внешними ключами, а таким образом: Код: sql 1. 2. 3. 4. 5. 6. Какие минусы у такого способа организации связи между сущностями? не стоит, Если отношение между заявкой и другими объектами как 1:N. Стоит, если M:N. но делать это одной таблицей вместо трех особого смысла нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2016, 20:12 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
kormot, ******autoZayavkaRel, buildingZayavkaRel, tehZayavkaRel если у вас приложение "регистрация заявок", то смысла нет городить огород с тремя справочными сущностями... приведите хоть примерно характер использования приложения. допустим "Прием заявок на ремонт "Автомобили", "Здания", "Оборудование". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2016, 08:31 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
Alex Ustinov, я эти три объекта и заявки придумал просто исключительно для иллюстрации мысли. Если привести пример более наглядный, ну комментарии к чему угодно. Т.е. допустим есть на сайте много разных сущностей: События, Персоны, Географ. места, Картинки, Музыка и вот если комментарии ко всему этому хранить в одной таблице. Она одна для всех типов сущностей. Тогда например при добавлении новой сущности, не надо добавлять ещё таблицу связи. Добавлять много где запросы именно для этой новой сущности не надо. Все обработки и работа с комментариями единообразно. И при появлении новыз разделов/объектов и чего угодно не требуют изменения базы. Вариант с комментариями тоже выдуманный, а примеры придумываю для иллюстрации, предлагаю на примерах не заостряться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2016, 13:27 |
|
||
|
Стоит ли делать связь между разными таблицами таким образом?
|
|||
|---|---|---|---|
|
#18+
смысл в том, что для записи Таблицы сущности как вы описали, вы достанете соответствующий комментарий, (в табл. коментарий доп поле ТипСущности, ИдСущности), а вот обратный механизм уже через PREPARE STATEMENT. Это надо иметь ввиду. (т.е. если надо будет посмотреть к чему были комментарии, допустим, определенного человека) И при добавлении-удалении сущности objType ENUM ("auto", "building", "tehnika") надо будет менять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2016, 13:46 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=106&tid=1831983]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 244ms |
| total: | 408ms |

| 0 / 0 |
