Merlin писал(а):paratruper писал(а):
Нет. чтобы пользователь видел с чем работает. Ему же надо видеть какие клиенты у него есть.
Опять - зачем? Всех сразу? Нет. Тогда почему 20 именно этих? Фигня-с полчаеццо. Архитектурное излишество.
Нет зачем же всех вот захочет он увидеть Васю Пупкина пролистает грид на Васю пупкина, либо поиск сделает, захочет увидеть Серёжу Карацупу, на него отмотает. Это грид показывающий имя фамилию и отчество клиента, остальные данные (реквизиты)пишуться в обычные едиты ведь удобнее видеть список. Опять же в один определённый момент времени у нас в датасете не вся таблица а её кусочек с необходимыми данными.
Merlin писал(а):
Сразу два простейших решения.
1. Джойн с основной таблицей всё равно есть. Тянуть из неё все поля, а показывать только нужные для навигации. А когда понадобятся, при активизации какой-то функции, показать в другом контроле.
Вариант хороший, но зачем их показывать в другом контроле если просто можно указать в гриде1, правда есть одно но. Если эти данные в этот момент не находяться в датасете который подключен к гриду1 возникает ситуация когда придёться их тянуть с сервера.
Merlin писал(а):
2. Мастер-деталь. То есть, тянуть по ID одну запись целиком из основной таблицы, ту, на которой спозиционирован грид с должниками. Медленней первого, но бывает сподручней в разработке.
Тоже вариант.
Я хочу пояснить, может я неправильно рассказал суть проблемы. Вытащить id из "должников" труда особого нет, как нет и труда вытащить все необходимые реквизиты из большой таблицы по этому id. НО после этих манипуляций у меня будет ОДНА запись. И что я могу с ней делать?
Правильно визуализировать для пользователя, а как?
Вот тут то и загвоздка можно как предлагаете вы, сделать отдельный контрол который покажет всю вытянутую информацию. А можно как хочет пользователь
вывести эту информацию в уже существующий контрол т.е грид1. Так вот если ему покажеться ОДНА искомая запись в гриде где то этого был список этих записей юзер будет огорчен
Желательно показать ещё рядомстоящие с найденой записи, при том что все равно выборка будет отсортирована, я думаю это возможно,но проктологически трудоемко. Т.е. сделать аналог locate но технически по другому. Ведь когда locatу работает он ведь указатель ставит на одну запись, а в гриде мы видим все равно не только найденную но и рядомстоящие.
Хотя я вот уже подумываю над убедительными доводами, что не нужно это ему
и не реализовывать такой зависимости.
Merlin писал(а):
Да не быстрый он, не быстрый. Если по полю сортировки не получится ORDER-план (а скорей всего так и будет), то для построения фрагментарной выборки серверу придётся дважды отсортировать ВСЮ выборку. Tmp-файл под гиг построить два раза.
К счастью order получился
хотя скорость тоже не блещет но все равно быстрее locate
выборка порядка 4 секунд на 400000 записях индекс по 4 полям одно из которых уникальное в order все эти поля и забиты.
Сейчас сделал selectivity all 