|
Что лучше: 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?fid=40&msg=39634010&tid=1561143]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
138ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 312ms |
total: | 534ms |
0 / 0 |