|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Здравствуйте, Один умный человек говорил как-то, что чем создавать кучу FK на всё-всё-всё, лучше сделать кучу триггеров, проверяющих целостность ссылки. Я постеснялся спросить у него тогда, а чем это лучше. И с тех пор мучаюсь этим вопросом. Никак не могу понять, где потери, чем встроенный механизм проверок FK будет хуже, чем организация триггеров, которые будут делать, вроде бы, то же самое, но руками. Или умный человек был неправ? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2018, 21:41 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
V.Borzov, "умный" человек был неправ. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2018, 21:54 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
V.Borzov, умный человек неправ. Триггер действует на уровне пользовательской транзакции. Поэтому он не способен обеспечить контроль целостности между конкурирующими транзакциями (он тупо не видит чужих изменений). А FK и PK проверяется по индексу, который содержит все ключи всех версий записей, т.е. он вне транзакций. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2018, 22:16 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
kdvV.Borzov, умный человек неправ. Триггер действует на уровне пользовательской транзакции. Поэтому он не способен обеспечить контроль целостности между конкурирующими транзакциями (он тупо не видит чужих изменений). А FK и PK проверяется по индексу, который содержит все ключи всех версий записей, т.е. он вне транзакций. Вооот. А теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов. Новый В работе Оплачен Отгружено Закрыт И таблицу этих самых счетов. Из пары мильёнчиков документов хотя бы. FK от которой по статусу кивает на эту мастер-таблицу. Которая никогда и никем редактироваться не будет. И запросы с условием на статус в where. Которые подхватят этот самый индекс. Особенно ищущие закрытые, лет эдак через 10 функлицирования предприятия. И прикинем сизифовы усилия сервера на регулярном ресторе этой базы при создании этого самого индекса. Жил один еврей, так он сказал, что всё относительно. Как говорят highly likely - it depends. Сдаёццо мне, что слова умного человека вырваны из контекста. Хотя в общем случае, безусловно, FK рулит. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 00:40 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
А нефиг FK на 5 строк делать. P.S. Топик не читал. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 00:45 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамА нефиг FK на 5 строк делать. P.S. Топик не читал. Если эти пять строк могут активно меняться - вполне так себе фиг. Правда лично я такой задачи придумать не могу :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 00:52 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Вы, кстати, "универсальные" справочники практиковали? Это когда несколько однотипных справочников объединяются по вертикали - ID, Ref_ID, Value, ... ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 01:41 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаА теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов. Новый В работе Оплачен Отгружено Закрыт NEW, IN_WORK, PAID, SHIPPED, CLOSED - ASCII символы этих слов слева направо легко умещаются в BIGINT от старшего байта к младшему, прекрасно сортируются и интерпретируются без всяких мастер-таблиц. Остается лишь прописать соответствующие числовые константы в ограничении CHECK соответствующего поля и создать по этому полю индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 09:17 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали? Это когда несколько однотипных справочников объединяются по вертикали - ID, Ref_ID, Value, ... ? Когда-то давно делали что-то похожее в мелком проекте. Чисто из интереса. Итог - закопали поглубже, ибо неудобно от слова совсем. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 09:44 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
DarkMaster> неудобно от слова совсем. А что именно было неудобно? Разработка, сопровождение, иное? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 09:58 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамА что именно было неудобно? Разработка, сопровождение, иное?Неудобно потому, что такой справочник лучше делать древовидным, когда первый уровень древа определяет тип справочника, а второй - элементы справочника. При использовании значений из такого справочника в поле таблицы придётся делать обвязку на триггере добавления/изменения. "Овчинка выделки не стоит". ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:04 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_dev.... При использовании значений из такого справочника в поле таблицы придётся делать обвязку на триггере добавления/изменения. "Овчинка выделки не стоит". о какой обвязке речь? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:21 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, о такой, которая будет проверять - входит ли значение поля в соответствующий диапазон ключей, относящийся к конкретному типу справочника, т.е. проверять идентификатор узла соответствующего ключа. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:26 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамDarkMaster> неудобно от слова совсем. А что именно было неудобно? Разработка, сопровождение, иное? Ну то, что запросы становятся развесистыми - уже минус. Ну и постоянные кастование. Если честно - помню только общие нехорошие впечатления, но если очень интересно - могу покопаться в архивах - исходники где-то должны быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:27 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devГаджимурадов РустамА что именно было неудобно? Разработка, сопровождение, иное?Неудобно потому, что такой справочник лучше делать древовидным, когда первый уровень древа определяет тип справочника, а второй - элементы справочника. Есть такое дерево. Тоже задумывалось "для всего". Но в итоге там только справочник товаров, все остальное туда так и не засунул т.к. перестал понимать зачем. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:31 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
У нас есть такой "универсальный" справочник. Вместо дерева используется идентификатор типа справочника. Проблема (у нас) в том, что в зависимости от этого типа нужна разная логика в поведении. Поэтому у нас она на клиенте. Допустим для одного справочника нужно каскадное удаление, для другого не нужно. Есть ещё проблемки. Например, просто пишем запрос по связанным справочникам и в запросе, допустим, 6-8 джойнов по одной таблице. Нечитаемо. И у меня есть подозрения в скорости таких запросов, хотя Влад сказал, что это вряд ли. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 10:32 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIНапример, просто пишем запрос по связанным справочникам и в запросе, допустим, 6-8 джойнов по одной таблице. Нечитаемо. Через алиасы получается довольно читаемо. Однако все равно не отвечает на вопрос - почему не в отдельных таблицах. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 11:05 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, Да Но это были совсем простые справочники, фактически не имеющие никакой "расчетной" нагрузки, ну вроде вот такого ... здесь код, кто и когда создал запись, кто и когда последний раз её изменил шифр наименование краткое наименование ....здесь еще несколько полей такого-же плана примечание И таки по факту для разработчиков это был "деревянный двухуровневый" справочник, для пользователей это были полноценные отдельные справочники. Из достоинств - очевидное при появлении нового "справочника" мизер телодвижений, добавить строку в первый уровень и в меню дабы он был доступен как отдельный справочник. Из недостатков - тоже очевидное,то что можно назвать "не додумал" (не полное знание предметной области, расширение круга решаемых задач), и оказывается справочник надо либо выносить в отдельную таблицу либо добавлять поля в существующую именно для этого справочника, либо .... И собственно недостаток превысил достоинство что касается именно "обвязки на триггере" - нам она была не нужна, ну просто из-за придерживания "идеологии" - в "сырой документ" вводите всё что хотите и как хотите а в обработку пойдет только тот документ в котором нет "ошибок", и проверка "на соответствие диапазону ключей" это та самое меньшее из контроля ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 11:19 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
DarkMaster> Ну то, что запросы становятся развесистыми - уже минус. Если мы говорим об одном и том же, то по сути добавляется только одно (или два) условия в where (к одному/двум полям одной таблицы). Не так уж и развесисто. С учетом нормальных алиасов как подсказали выше - и читаемость особо не страдает. > Ну и постоянные кастование. Это ты про Value1, Value2 и пр. универсальные поля? > Если честно - помню только общие нехорошие впечатления, Меня интересуют впечатления, неизвестные грабли и пр, исходники как раз малоинтересны, там сложностей нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 11:41 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m> Но это были совсем простые справочники, фактически m7m> не имеющие никакой "расчетной" нагрузки Ну я и говорю о простых справочниках, о которых выше речь зашла, сложные-то понятно каждый в своей отдельной таблице. Как справочник может иметь расчетную нагрузку не очень понял. > Из недостатков - тоже очевидное,то что можно назвать "не додумал" > (не полное знание предметной области, расширение круга решаемых задач) > > И собственно недостаток превысил достоинство Ясно, спасибо. Иных недостатков, подводных камней не замечали? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 11:46 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамКак справочник может иметь расчетную нагрузку не очень понял. Наверное я неправильно написал, имелось ввиду что-то в вроде вот такого "коэффициент перерасчета из одной единицы измерения в другую", ну и тому подобное Гаджимурадов РустамИных недостатков, подводных камней не замечали? Нет, не вспоминается ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 11:59 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам С учетом нормальных алиасов как подсказали выше - и читаемость особо не страдает. Это когда их мало. Даже с альясами при "широкой" выборке запрос превращается в лес из JOIN`ов. Не удобно, потому что при возврате через месяц к этому запросу - нужно делать на лишнюю операцию больше, чтобы "раскрутить" запрос в голове и понять, куда какой справочник лепится. Гаджимурадов Рустам> Ну и постоянные кастование. Это ты про Value1, Value2 и пр. универсальные поля? Про них. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 12:01 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
DarkMasterЭто когда их мало. Даже с альясами при "широкой" выборке запрос превращается в лес из JOIN`ов. Не удобно, потому что при возврате через месяц к этому запросу - нужно делать на лишнюю операцию больше, чтобы "раскрутить" запрос в голове и понять, куда какой справочник лепится. Я немного не понял, ведь в любом случае независимо от того справочники в одной таблице или в разных "лес из JOIN`ов" останется, или я не прав? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 12:15 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамНу я и говорю о простых справочниках, о которых выше речь зашла, сложные-то понятно каждый в своей отдельной таблице. Как справочник может иметь расчетную нагрузку не очень понял. Вот как-то так... Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 13:21 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Я вот приводил пример леса джойнов: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Ну нечитаемо совсем. Если только комментарии к каждой строке... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 13:38 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, Да, но легче читать запрос когда подвязываются таблицы-справочники, а не 1 справочник много раз. Ну это лично для меня. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 13:39 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали? Это когда несколько однотипных справочников объединяются по вертикали - ID, Ref_ID, Value, ... ? Нет. Чем проще и каноничнее структура, тем проще жизнь. Имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:06 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаА теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов. Новый В работе Оплачен Отгружено Закрыт NEW, IN_WORK, PAID, SHIPPED, CLOSED - ASCII символы этих слов слева направо легко умещаются в BIGINT от старшего байта к младшему, прекрасно сортируются и интерпретируются без всяких мастер-таблиц. Остается лишь прописать соответствующие числовые константы в ограничении CHECK соответствующего поля и создать по этому полю индекс. Речь не о том, что во что впихуемо. За "создать по этому полю индекс" - двойка. Ты ничего не понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:09 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:13 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Пробовал. Удобно использовать для простых перечислений, которые состоят только из наименования и ещё пары "базовых" признаков, типа пометки удаления, признака группы и родителя/иерархии. Собственно, и всё. Остальное признано нецелесообразным. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:14 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаЗа "создать по этому полю индекс" - двойка. Ты ничего не понял.Обоснуешь? Объяснишь? Да раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:20 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:35 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамDarkMaster> Ну то, что запросы становятся развесистыми - уже минус. Если мы говорим об одном и том же, то по сути добавляется только одно (или два) условия в where (к одному/двум полям одной таблицы). Не так уж и развесисто. С учетом нормальных алиасов как подсказали выше - и читаемость особо не страдает. > Ну и постоянные кастование. Это ты про Value1, Value2 и пр. универсальные поля? > Если честно - помню только общие нехорошие впечатления, Меня интересуют впечатления, неизвестные грабли и пр, исходники как раз малоинтересны, там сложностей нет. Для справчоников, создаваемых пользователями. Т.е. создается критерий "размер ноги", к нему набор допустимых значений потом "размер головы", "длина лыж", "длина палок" лукапы делать не сильно удобно. приходится генерить на ходу. все значения текстовые. справочники, которые не могут редактироваться пользователями - "пол" - забиваются в домены ( M F U), расшифровки - в справочник описания доменов (F - Женский) были попытки создания древовидной (точнее иерархической) структуры документов, сущностей и пр, но не взлетело. канонические структуры оказались быстрее в разработке, работе и сопровождении. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 14:37 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_devСтарый плюшевый мишкаДа раком сервак встанет, если попытается на заметных объёмах его в запросах использовать. Причём не во всех запросах, а в зависимости от количества дубликатов искомого значения. Можно год не наступить на мину, а потом кааак бабахнет! И ресторить сутками будет, строя этот индекс. Весь сыр-бор с отказом от FK именно для того, чтобы от него избавиться.Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? Ой фсё... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:04 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаrdb_devпропущено... Чот я не пойму... В FK у тебя суррогатный ключ, например тот же BIGINT, по которому, в случае FK, будет построен индекс, но ко всему прочему, еще будет осуществляться проверка на наличие соответствующего ключа в мастер-таблице. Так почему в случае моих константных значений BIGINT сервер встанет раком, а в случае FK-PK - не встанет? Ой фсё... Подробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:05 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаПодробнее - я отвечаю за то, что я пишу, а не за то, что ты читаешь :)😆 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 15:39 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_dev, Ты поищи, поищи, где о FK такое написано. Речь шла об индексе, и никакой разницы, FK он или не FK. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 16:22 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
DarkMaster> Да, но легче читать запрос когда подвязываются таблицы-справочники, DarkMaster> а не 1 справочник много раз. Ну это лично для меня. С алиасом разницы практически никакой нет. Но это вкусовщина, в любом случае. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 21:38 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
В общем, всем спасибо за мнения и впечатления. pastor> были попытки создания древовидной (точнее иерархической) pastor> структуры документов, сущностей и пр, но не взлетело В смысле некая EAV-light или тот же справочник, но ещё и древовидный (в чём его древовидность-то заключается) ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 21:40 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
WildSery, бывает, я, порой, не догоняю о чем речь и потому переспрашиваю. И? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 23:22 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIЯ вот приводил пример леса джойнов: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Ну нечитаемо совсем. Если только комментарии к каждой строке... Конечно нечитаемо, ты один справочник сам с собой связываешь а если вот такое Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
так совсем другой вид ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 07:20 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
rdb_dev, Моё дело метёлкой махать, а не подталкивать отстающих. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 09:33 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, Я привёл как-раз свой пример, где "универсальность" справочников доведена до маразма. У нас именно так они и перевязаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 10:30 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Откуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов Чтобы не случилось, что например Z[1].Area = Z[8].District или Z[123].Department = Z[47].Claim ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 11:54 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXI, Такое ощущение, что вы там аналог Windows Registry замутили. Наверное тогда как и в Windows надо было делить на две сущности, делать две таблицы. 1) дерево структуры, ноды 2) Key-Value значения, привязанные к конкретной ноде Тогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 11:56 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
AriochОткуда требование ещё и глобального одного-на-всю-БД источника ID для всех объектов Ну не "одного-на-всю-БД источника ID" а только для тех кто в общем справочнике Я не вижу в этом ничего плохого, а вот что увидел ты в этом плохого я не знаю и мне это малость интересно ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 12:48 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
AriochТогда ты сначала выбираешь ноду по первой таблице, а потом начинаешь е ней аттрибуты подтягивать?Это уже динамическая ORM. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 12:52 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Arioch, У нас сложней. Одна запись справочника может иметь до четырёх форейн-записей других справочников. Пока до четырёх. И деревянная структура тоже держится. Я когда увидел, что коллеги наваяли (я был новый), обалдел. Нет, связывать надо, никуда не деться. Но читабельность... Беру список признаков и разбираюсь часами. ИМХО, дурдом. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:51 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
m7m, ненужная зависимость разных сущностей между собой - больше надо помнить и учитывать, а гибкость меньше m7mтолько для тех кто в общем справочнике в добавок еще ненужное усложнение системы для одних объектов мы берем нoвые ID одним методом из одного хранилища, а для других - другим методом из других хранилищ. Это нужно всегда помнить и нигде не перепутать, вмеcто унификации кода. А если потом какой-то изначально отдельный объект захочется внести в справочник? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:53 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIОдна запись справочника может иметь до четырёх форейн-записей других справочников. зачем? KreatorXXIПока до четырёх. ага, молотком и матерью всунуть шахматку на уровень структур RDBMS, потом грызть грааль "как сделать универсальный запрос, чтобы по любому из одинаковых столбцов...." ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:56 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
KreatorXXIЯ вот приводил пример леса джойнов: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Ну нечитаемо совсем. Это потому что констант в Firebird нету Ну а если насоздавать лишних сущностей? Код: sql 1. 2. 3. 4. 5. 6. 7.
В пределе вывести всю работу с мега-справочником на раздельные вьюхи и потом превратить их в таблицы а мега-справочник грохнуть? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 14:02 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамВы, кстати, "универсальные" справочники практиковали? Это когда несколько однотипных справочников объединяются по вертикали - ID, Ref_ID, Value, ... ? Практиковали. Все логические справочники в один засунули, назвали его TUPLE. Только полей Value было много, и они были разнотипными: строка, целое, дата, момент времени и т.д. Не открывайте, пожалуйста. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514.
... не надо было открывать, я ведь предупреждал. Блобы тоже есть, но в виде отдельной таблички Attachment, у каждой записи виртуальной таблички может быть от нуля до скольки угодно блобов разного назначения. ... Ну так вот, "настоящие" FK там есть, но только к одной, настоящей табличке USERS. А между "логическими" (виртуальными?) табличками связи реализованы с помощью промежуточной табличке LINK: Тут уже безопасно Код: sql 1. 2. 3. 4. 5.
А уж у этой таблички - настоящие FK к элементам виртуальных сущностей. Как ни странно, до сих пор работает. Но нагрузки не очень великие: самое большее - около сотни одновременно работающих пользователей и базы невелики, а в базах основной объем - небольшие блобы (образы электронных документов). Ну и клиент старательно пишем так, чтобы там, где большие объемы - грузить поменьше. Когда-то сделали для одного заказчика, тупо "давай-давай побыстрее", а оно все живет и живет, хотя и заказчика того уже нет. Все обросло скриптами, отчетниками, плагинами и переделывать вряд ли кто-то будет. ... Триггеры используются, но не для контроля целостности, а для всякой фигни. Например, для генерации значения первичного ключа или проверки вводимого имени на соответствие шаблону и т.п. Или эвенты рассылать. ... FB 2.0. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 14:18 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Ariochненужная зависимость разных сущностей между собой - больше надо помнить и учитывать, а гибкость меньше О какой зависимости то речь, нет никакой зависимости, ну я по крайней мере не вижу её, как не вижу ни больше, ни меньше гибкости Ariochm7mтолько для тех кто в общем справочнике в добавок еще ненужное усложнение системы для одних объектов мы берем нoвые ID одним методом из одного хранилища, а для других - другим методом из других хранилищ. Это нужно всегда помнить и нигде не перепутать, вмеcто унификации кода. О чем речь, где тут усложнения, объекты, хранилища? о каких методах то речь, gen_id(...) что-ли что тут помнить и путать, триггер на вставку new.id=gen_id(...) не на ту таблицу навесить, генератор попутать AriochА если потом какой-то изначально отдельный объект захочется внести в справочник? тут я совсем не понимаю :( ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 16:57 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Читайте классику :) Анатолий Тенцер. База данных - хранилище объектов. Компьютер пресс, 2001 год. https://compress.ru/article.aspx?id=11515 Для тех кто не в курсе. Это не теоретические изыскания и эксперименты. Из того в те же годы была создана система автоматизации крупной оптовой фирмы по торговле медпрепаратами. Автоматизировано все, включая бухгалтерию. В стратье приведено на примере Interbase или Firebird но реальная система работала на MS SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 17:10 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
fraksЧитайте классику :) Анатолий Тенцер. База данных - хранилище объектов. Компьютер пресс, 2001 год. https://compress.ru/article.aspx?id=11515 Для тех кто не в курсе. Это не теоретические изыскания и эксперименты. Из того в те же годы была создана система автоматизации крупной оптовой фирмы по торговле медпрепаратами. Автоматизировано все, включая бухгалтерию. В стратье приведено на примере Interbase или Firebird но реальная система работала на MS SQL. Так ничего хорошего же, в статье все недостатки и разжеваны. Вместо прямого использования возможностей СУБД - костыльная эмуляция этих возможностей, с длительным нетрадиционным послесексом в процессе сопровождения. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 17:21 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
какой пятничный топик :) зы. все нубы проходят через эту стадию познания ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 17:48 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Котовасия, спасибо, это уже поинтереснее. Котовасия> ... не надо было открывать, я ведь предупреждал. Да уж, название таблицы вполне "говорящее". :) А почему 89 (а не 99) и почему полей разных типов количество? Собственный слой метаданных в БД не создавали, всё в клиенте? А между "логическими" (виртуальными?) табличками связи реализованы с помощью промежуточной табличке LINK: CREATE TABLE LINK ( TUPLE_ID T_TUPLE_ID NOT NULL /* T_TUPLE_ID = INTEGER */, ASSOCIATION_ID T_ASSOCIATION_ID NOT NULL /* T_ASSOCIATION_ID = INTEGER */, LINKED_TUPLE_ID T_TUPLE_ID NOT NULL /* T_TUPLE_ID = INTEGER */ А уж у этой таблички - настоящие FK к элементам виртуальных сущностей. Что здесь ASSOCIATION_ID и что LINKED_TUPLE_ID ? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 20:13 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам>Да уж, название таблицы вполне "говорящее". :) Ты не представляешь, как тяжело придумать название генерируемого бреда... Гаджимурадов Рустам> А почему 89 (а не 99) и почему полей разных типов количество? Со временем проснулась жаба и задушила... ... Метаданные в базе, да. Табличка Collection - описывает сущность ("виртуальную" табличку). Включает название, и некоторые доп. признаки: "может иметь аттачменты" (блобы), описание доп. признаков (в json-структуре - хранится в блобе) и еще по мелочи. Табличка Attr_Def - описывает атрибуты сущностей. Т.е., "поля". Включает ссылку на элемент collection, название физического поля таблички tuple, тип атрибута, логическое имя, хинт (именно хинт - то, что всплывает при наведении мышкой на заголовок поля таблички), значения по умолчанию, и проч. Табличка Association. Описывает связь между логическими сущностями. Аналог FK. Включает ссылки на элементы collection, поведение при удалении, логическое имя, ссылки на пару других ассоциаций (тринзитивные и кардинальные зависимости) и т.п. Гаджимурадов Рустам> Что здесь ASSOCIATION_ID и что LINKED_TUPLE_ID ? association_id - указывает, какую связь между сущностями реализует. tuple_id - id мастер-записи, linked_tuple_id - id FK-записи. ~~~~~~~~ Еще куча всякостей для оргаганизации групп прав юзеров, для организации псевдофайловой ("дерево", если коротко) структуры некоторых сущностей, обвязка для работы с отчетами, хранилище плагинов и еще разная ерундень. ... Поначалу даже сделали "наследуемые" (как в постгре) сущности, но так как за года использования ни разу не понадобилось, потихоньку выпилили, тем более что сия фича требовали нехилых усилий при доработке и из-за ненужности дико бесила. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 22:14 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Если кто-то хочет повторить сей подвиг: лучше не надо. Столько секаса ради призрачного преимущества менять метаданные "на лету". Да и не преимущество это вовсе. Один черт во многих случаях "на лету" не получается. Например, в шаблонах отчета (FR) - вот, не стало поля - и? Какая разница, логическое поле или физическое, ведь скрипт создания отчета сам собой не поменяется. А еще потом выясняется, что систему хотят развернуть под нагрузкой, в 20-ть превышающей запланированную, а ты бекаешь и мекаешь по поводу невозможности создания индексов на виртуальных полях. ... Все метаданные в базе есть. Ничто не мешает их дополнить своими в соответствии с пожеланиями левой пятки. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 22:28 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Котовасия> А почему 89 (а не 99) и почему полей разных типов количество? Со временем проснулась жаба и задушила... А что, реально бывало 89 однородных атрибутов? Да ещё в универсальный справочник? Я вообще больше 20 с ходу не припомню, да и те - в универсальный нельзя объединять. Котовасия> Что здесь ASSOCIATION_ID и что LINKED_TUPLE_ID ? association_id - указывает, какую связь между сущностями реализует. linked_tuple_id - id FK-записи.Всё равно не понял. В чём суть/назначение первого поля, и на чот ссылается второе поле? Можно примером. КотовасияМетаданные в базе, да. Табличка Collection - описывает сущность ("виртуальную" табличку). Включает название, и некоторые доп. признаки: "может иметь аттачменты" (блобы), описание доп. признаков (в json-структуре - хранится в блобе) и еще по мелочи. Табличка Attr_Def - описывает атрибуты сущностей. Т.е., "поля". Включает ссылку на элемент collection, название физического поля таблички tuple, тип атрибута, логическое имя, хинт (именно хинт - то, что всплывает при наведении мышкой на заголовок поля таблички), значения по умолчанию, и проч. Табличка Association. Описывает связь между логическими сущностями. Аналог FK. Включает ссылки на элементы collection, поведение при удалении, логическое имя, ссылки на пару других ассоциаций (тринзитивные и кардинальные зависимости) и т.п. ~~~~~~~~ Еще куча всякостей для оргаганизации групп прав юзеров, для организации псевдофайловой ("дерево", если коротко) структуры некоторых сущностей, обвязка для работы с отчетами, хранилище плагинов и еще разная ерундень. ... Поначалу даже сделали "наследуемые" (как в постгре) сущности, но так как за года использования ни разу не понадобилось, потихоньку выпилили, тем более что сия фича требовали нехилых усилий при доработке и из-за ненужности дико бесила. Если есть время и желание - опиши, пожалуйста, поподробнее, лучше отдельным топиком (можно тут, можно в разделах Delphi или РИС/Проектирование), очень интересно почитать. КотовасияСтолько секаса ради призрачного преимущества менять метаданные "на лету". Да и не преимущество это вовсе. Один черт во многих случаях "на лету" не получается.Так точно. Правда, делается это не только/столько ради "на лету", сколько ради каких-то фич, "автогенераций", наследуемых форм и т.д. С другой стороны, всё (или почти всё) это можно и на основе родных метаданных делать (наверное), но обычно решают лепить не костыль, а собственный лисапед. КотовасияВсе метаданные в базе есть. Ничто не мешает их дополнить своими в соответствии с пожеланиями левой пятки.Дык доп.метаданные как раз и станут "своим" слоем, рядышком или "сверху". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2018, 10:40 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамКотовасияМетаданные в базе, да. Если есть время и желание - опиши, пожалуйста, поподробнее, лучше отдельным топиком (можно тут, можно в разделах Delphi или РИС/Проектирование), очень интересно почитать.Или ссылку дай, если где-то уже описывал (хотя я ничего подобного не припомню за последние годы от тебя, разве что очень давно). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2018, 10:46 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Вооот. А теперь представим себе мастер-таблицу, скажем, статусов документов. Нуусс, скажем, счетов. Новый В работе Оплачен Отгружено Закрыт И таблицу этих самых счетов. Из пары мильёнчиков документов хотя бы. FK от которой по статусу кивает на эту мастер-таблицу. Которая никогда и никем редактироваться не будет. И запросы с условием на статус в where. Которые подхватят этот самый индекс. Особенно ищущие закрытые, лет эдак через 10 функлицирования предприятия. И прикинем сизифовы усилия сервера на регулярном ресторе этой базы при создании этого самого индекса. Жил один еврей, так он сказал, что всё относительно. Как говорят highly likely - it depends. Сдаёццо мне, что слова умного человека вырваны из контекста. Хотя в общем случае, безусловно, FK рулит. Да, понял, спасибо. Теперь мне очевидно, что я те слова его неправильно понял, действительно вырвал из контекста. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2018, 23:28 |
|
Что лучше: FK или триггеры проверки целостности?
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам>А что, реально бывало 89 однородных атрибутов? Да ещё в универсальный справочник? Гаджимурадов Рустам>Я вообще больше 20 с ходу не припомню, да и те - в универсальный нельзя объединять. У нас один активный товарищ все поля тестовыми сделал, ровно сто. И позвонил нам, когда сто первое попытался добавить. Справочник назывался То ли "План чего-то", то ли "Подготовительная записка". Он туда вбахал фамилии руководства, подрядчика, генподрядчика, заказчика, гензаказчика, ответственных за то-сё, названия этого самого того-сего, даты начала-окончания-завершения чего-то, с кем согласовано и кем утверждено, сколько стоит и сколько стоило раньше и почему теперь так дорого, адреса "вертолетных площадок"(???), номера телефонов, номера и даты договоров, с пяток полей "Примечание 1", "ПРимечание 2"... ... Гаджимурадов Рустам>ASSOCIATION, LINK...? И так, у нас есть таблички: COLLECTION - описания этих самых сущностей. ATTR_DEF - список описаний атрибутов сущностей. ASSOCIATION - описание связей между сущностями (как бы FK). TUPLE - тут все в куче, экземпляры сущностей (виртуальных табличек). LINK - экземпляры связей между сущностями. Пример. Сущности ("таблички"): Улица, Район города, Город. В табличке COLLECTION idНаименование1 Улица2 Район3 Город В табличке ATTR_DEF: id id коллекции Наименование Тип Имя физического поля1 1 Наименование Строка v_str_002 1 Длина улицы Вещественное v_real_003 2 Наименование Строка v_str_004 2 Площадь Вещественное v_real_005 3 Наименование Строка v_str_005 3 Число жителей Целое v_int_00 В табличке ASSOCIATION: id Наименование Id коллекции id связанной коллекции1 1 Улица-Район 1 22 2 Район-Город 2 3 Все, метаданные описаны. Далее - данные: В табличке Tuple: id collection_id v_str_00 v_real_00 v_int_001 3 Санкт-Петербург 52256902 2 Василеостровский209 5873 2 Адмиралтейский1635914 2 Московский 3506025 1 Биржевая линия 2606 1 Подольская улица 7727 1 Проспект Космонавтов 4900 Теперь реализуем связи, табличка LINK: tuple_id association_id linked_tuple_id Примечание512 Биржевая линия находится в Василеостровском районе613 Подольская улица находится в Адмиралтейском районе714 Проспект Космонавтов находится 221 Василеостровский район находится в Санкт-Петербурге321 Адмиратейский район находится в Санкт-Петербурге421 Московский район находится в Санкт-Петербурге Зачем нужна ASSOCIATION? Связей между одинаковыми сущностями может быть больше, чем одна. Например, связь "Человек-Адрес". Адрес может быть местом фактического жительства, местом рождения, местом регистрации. Соответственно, три независимых связи. ... Из схемы отброшены разные незначительные мелочи вроде поведения при удалении и т.п. Есть отдельные механизмы, облегчающие жизнь при создании гуя. Например, в схеме Улица-(связь 1)-Район-(связь 2)-Город можно указать, что связь 2 является определяющей для связи 1. Сие в гуи-интерфейсе при выборе улицы автоматом потребует сперва выбрать город, потом район (из списка именно в этом городе), а уж потом - улицу (из списка именно в этом районе этого города), а не копаться в гигантском списке улиц всей России. ... Вроде основное описал. А зачем тебе? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2018, 15:55 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1561143]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
135ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 256ms |
0 / 0 |