|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Нужно решение для работы с запросами содержащими поля: [Код записи]/[Код родителя] Когда-то для этих целей на скорую руку слепил такой класс: Код: vbnet 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. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775. 776. 777. 778. 779. 780. 781. 782. 783. 784. 785. 786. 787. 788. 789. 790. 791. 792. 793. 794. 795. 796. 797. 798. 799. 800. 801. 802. 803. 804. 805. 806. 807. 808. 809. 810. 811. 812. 813. 814. 815. 816.
Тогда задача была построить макет приложения поэтому скорость и пр. были не очень важны. надо было посмотреть как оно вообще - стоит ли под задачу таким образом переделывать данные. Тогда отказались в пользу другого решения. Идеологически построен неправильно: при инициализации для текущей вершины создаются два запроса содержащие все допустимые родительские и подчиненные записи. При перемещении по записям при необходимости перехода на др. уровень берётся запись соответствующего запроса, делается текущей и переформируются запросы родительских/подчиненных. Соответственно это все работает ужас как медленно. Сейчас на основе данных такого запроса у меня должна динамически создаваться/обновляться в зависимости от выбора пользователя форма. Каждое действие пользователя на форме вызывает необходимость обхода всего дерева доступных записей поэтому тормоза становятся очень заметны. Наверное правильнее было один раз при инициализации построить в памяти дерево связей и при перемещениях сверяться с ним, - но с нуля не хочется, а быстрый поиск по сети ничего похожего не дал. Сразу - Treeview не про то - мне нужно работать со всей записью таблицы там много данных от которых зависит вид и поведение элемента на форме, разве что, как вариант - создавать его в памяти только для получения нужного ключа записи и по нему возвращать возвращать из Recordset данные.. В общем-то интересует сабж - может у кого-то есть или попадалось что вменяемое на этот счет ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 12:37 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
"только для получения нужного ключа записи и по нему возвращать возвращать из Recordset данные.." У меня сейчас так.Строится дерево изделия в treewiev, отображается на форме. Есть интерфейс поиска деталей по номеру -наименованию и тд Пользователь выбирает ноду на дереве и на форме нужную функцию( открыть чертеж и тд) с дерева берется только код узла и по нему в таблицах находятся нужные данные и с ними выполняются нужные дей ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 15:49 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus, пожалуйста,уточните какие данные Вы храните и в что бы хотели получить в "выхлопе"(например список деталей или узлов входящих в выбранное изделие,кстати а почему не выбрать в Treeview,а в подчиненной форме вывести нужные подробности по выбранному) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 17:29 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Спасибо за отклики - похоже действительно следует немного расширить описание. Концепция такая - есть таблица записей, скажем, - [tblDetails]:{RecId;параметры...}. Для записей данной таблицы должны быть заполнены по настраиваемому шаблону [tblTemplate]:{TmpId;ParId;параметры...} данные [tblData]:{RecId;TmpId;Value} Данные структуры по записи м.б. заполнены полностью или частично. Это структура данных здесь непоняток нет - все работает нормально. После завершения заполнения tblData на основании ее данных обсчитываются результаты. алгоритм обсчета зависит от содержания tblTemplate - здесь тоже есть понимание как решать - обсчитывать структуру при вводе данных, тогда итоговые показатели можно будет собирать SQL запросами без сложных проверок для каждой записи. Но вот есть сложность с вводом структуры. Структура как я говорил может меняться поэтому форма ввода создается динамически - считаю хэш значимых данных таблицы tblTemplate и сравниваю с хэшем сохраненным в форме ввода если они не совпадают - пересоздаю форму. Вот теперь зачем здесь понадобился обход дерева. Контролы для элемента структуры выводятся в зависимости от уровня элемента структуры, наличия и параметров у элемента родительских записей, наличия подчиненных записей, наличия соседей справа/слева, параметров элемента структуры Форма ввода создается один раз перед началом ввода и, в принципе, даже с этим классом за приемлемое время ~ 1,5 сек Но вот при выполнении групповых действий на форме с контролами - например проставить во все выведенные на форме поля для данной записи по определенному правилу значение, т.е. обойти дерево с первой отобранной записи структуры до последней, проверяя выводится она или нет, если выводится - проверить типы записи рассчитать по правилу занести данные и перейти к следующей (вниз/вправо) Здесь с момента нажатия до завершения обхода на достаточно небольшой структуре (4 уровня около 40 записей) теряется ~1,2 сек - это уже неприемлемо. при массовом вводе это должно работать в три щелчка "щёлк"-"щёлк"-"щёлк" >> взглянул-выбрал-сохранил(перешёл к следующей), а пока получается: "щёлк"-"щёлк"-...пауза...-"щёлк" с ритма сбивает однако ))) поэтому ищу альтернативное решение для обхода запроса - побыстрее данного. Оптимизировать класс тоже можно попробовать но давненько я его писал и там по-моему радикально не получится он изначально идеологически неправильно был спроектирован Сам Treeview как контрол на форме не нужен - более чем вероятно механизм обхода будет необходим и безотносительно формы например для проверки корректности заполнения структуры для данной записи. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 22:11 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Не надо описывать КАК Вы решаете некую задачу:поясните саму ЗАДАЧУ-имеется то-то, нужно получить то-то без рассказов о том какие таблицы созданы,что подразумевается под "обсчитывать структуру при вводе данных" и т.д. и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 23:47 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
sdku, это и есть задача. На входе: есть данные имеющие внутреннюю связь по ключевому полю, организованные следующим образом: КодЗаписи;КодРодительскойЗаписи;ТекстоваяМетка;Параметр1;Параметр2;..;ПараметрN Широкая постановка задачи: Необходимо обеспечить возможность работы с данными как с деревом записей, включая: навигацию по дереву (спуск, подъём по ветке, обход от текущей записи с заходом и т.п.) доступ для текущей записи к родительским записям/соседним/потомкам определение уровня текущей записи в дереве определение пути к текущей записи от верхней родительской Узкая постановка задачи: весьма примерный алгоритм создания контролов формы на основе данных: алгоритм Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Как видно, для решения узкой задачи необходимо для каждой записи иметь возможность получить данные о наличии у нее подчиненных, родителя, правого соседа, левого соседа, правого соседа родителя. На выходе: должно получиться что-то вроде этого: схема Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
это пример просто для наглядности, - несколько типовых, часто встречающихся типов записей, - реальные конфигурации м.б. самые причудливые при групповом переключении контролов надо, например, (см. схему выше) все видимые Кнопки1 сделать нажатыми, а все видимые Поля1 заполнить данными на основе правила зависящего от параметров соответствующей записи или - заполнить по другому настроенному шаблону. Решение поставленной задачи: моё текущее решение - построено на классе приведённом в заглавном посте оно рабочее, но не удовлетворяет меня, в основном по скоростным и эстетическим показателям ищу альтернативное P.S. Вопрос пересмотра структуры данных или дизайна формы ввода не стоит. Нужен инструмент для решения конкретной задачи - работы с деревом записей позволяющий получить необходимые для построения формы параметры (см.выше) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:56 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
"•определение уровня текущей записи в дереве •определение пути к текущей записи от верхней родительской" Эту информацию я храню в отдельных полях таблицы Наличие поля с путем к вершине позволяет мгновенно получить все подчиненные записи. А поле с уровнем записи еще и отсортировать набор..... Понимаю что "P.S. Вопрос пересмотра структуры данных или дизайна формы ввода не стоит. ", но все же... "Как видно, для решения узкой задачи необходимо для каждой записи иметь возможность получить данные о наличии у нее подчиненных, родителя, правого соседа, левого соседа, правого соседа родителя." Так сложилось, что я тоже не пользуюсь для этого методами treewiev - все определяю по коду узла( он у меня содержит уникальный код записи в таблице) - все определяю через recordset ы.... и для всего этого достаточно одного только кода узла. Ваши задачи - "правого соседа, левого соседа, правого соседа родителя." например, шире моих, и поэтому не могу сказать точно, получится ли выигрыш по времени.... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 13:00 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus, Thanks for giving thet informatiom ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 13:04 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Serg197311, Изменения структуры - нет, а вот дополнительные поля - приемлемо. была мысль хранить в каком-то виде путь для каждой вершины в структуре, но пока не вызрела: хранить полный путь вверх[/вниз]? или ближайшего соседа справа/слева/сверху/снизу?, другой вариант?.. думал и про создание TreeView как объекта внутри класса-обертки и передать ему всю работу, но пока не пробовал. Соседей в Treeview должно получиться там помнится для Node есть св-ва Next/Previous и Siblings, а т.к. Parent и Child также возвращают Node - можно проверять. по аналогии с ним я и пытался лепить своё пока ваш вариант с хранением пути выглядит перспективнее прочих наверное буду пробовать идти в эту сторону. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 14:56 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus хранить полный путь вверх ИМХО - так. ))) У Вас уже все индусы посписывали) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 15:05 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Serg197311, индусы это хорошо.. - Индийский слон лучший друг Рус[ского] слона! (или viсe versa) как-то так))) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 15:54 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus, может Вам уйти от этого дерева к спискам? я сделал 4 уровня для себя, Вам может побольше - текущий список центральным можно ставить, а слева и справа родитель, потомок.. все быстро, достаточно удобно, ещё куча новых возможностей появляется - шаблоны, типы данных, блокировки, примечания :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 17:32 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
alecko, про списки - не уловил. можете чуть подробнее - как это выглядит в железе? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 17:49 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus, если правильно понял проблему: есть списки - аналоги ветвей дерева, обновляются быстро, наполнение в зависимости от контекста, и кнопок надо меньше. у меня эта история настроена на настройки, справочники и пр. таблица форма на центральный уровень не перемещал, но если с динамическим форматированием знакомы - это несложно- переходим скажем на 4-й уровень (а уровней больше) при щелчке на 3-м списке он переходит на второй список (соотвественно на 1-й список переходит 3-й уровень)-1-й уровень у меня это поле со списком), а вместо 3-го ставится уже 5-й уровень и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 18:56 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
iKaRus, смотрел иерархический рекордсет? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 19:28 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
alecko, теперь понял - вы про связанные списки. В моем случае это не сработает - такой вариант интерфейса меня не устроит. Про переходы между уровнями если правильно улоовил - что-то похожее я делал для рекордсетов в классе выше. для текущей записи строил три рекордсета: рекордсет записей уровня родителей текущей (Parents), рекордсет потомков текущей (Childs) и рекордсет соседей текущей (Siblings) При переходе например вниз => бывший Childs становится для новой записи Siblings, бывший Siblings становится Parents, бывший Parents уходит в небытие, а новый Childs - строится по новой текущей. Оно? В общем логично - зачем пересобирать то что уже обсчитано и лежит в соседнем рст/листбохе если можно взять объект целиком, но к сожалению решение с листбоксом в моем случае проблему не решит ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 21:04 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Панург смотрел иерархический рекордсет? а можно ссылку? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 21:07 |
|
Перемещения по дереву в запросе с иереархическими данными
|
|||
---|---|---|---|
#18+
Панург, поискал на форуме про иерархический запрос, - почитал про SHAPE - интересно раньше не сталкивался, решил отложить на будущее разобраться. По задаче выбор сделан в пользу 3-х дополнительных полей: Код правого соседа, Код левого соседа, Код первого потомка (, Код родителя уже есть) возможно плюс поле уровень записи. Это даст мне возможность не сильно ломая существующую структуру приложения получить все необходимые данные перемещаясь на клоне рекордсета к записям взятым из соотв полей нужной записи. Обсчитывать служебные поля дерева можно при создании хотя бы и тем же классом - один раз обойти заполнить и больше не дергать - должно помочь. Сама структура относительно небольшая, а обходить ее надо многократно для каждой записи таблицы данных (весьма объемной) так что выигрыш по времени д.б. заметный. Всем спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 21:48 |
|
|
start [/forum/topic.php?fid=45&fpage=24&tid=1610383]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
45ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
127ms |
get tp. blocked users: |
2ms |
others: | 62ms |
total: | 276ms |
0 / 0 |