Loockup поля

← →
nbv © (2006-02-09 08:09) [0]

Очень интересно узнать у мастеров: кто как работает с лукап полями. В сетевой БД. Пишут все руками засовывают в комбобоксы, а потом руками изменяют инфу или пользуются стандартными TLoockUpCombBox или еще как. Спасибо.

← →
API (2006-02-09 09:02) [1]

У меня свои компоненты, унаследованные от TEdit и TComboBox - в зависимости от потребностей. Для хранения списков используется синхронизируемый кэш с произвольной выборкой.
Впрочем, компоненты доступа к даным - тоже свои, так что - не показательно.

← →
LexxX © (2006-02-09 09:15) [2]

nbv © (09.02.06 8:09)
Пишут все руками засовывают в комбобоксы, а потом руками изменяют инфу или пользуются стандартными TLoockUpCombBox или еще как.

А как еще можно, если не засовывать все руками в комбобоксы для вставки новой записи в одну из таблиц БД, и не пользоваться стандартными TLoockUpCombBox для изменения существующих записей?

з.ы. а что ты имел ввиду под сетевой БД?

← →
Sergey13 © (2006-02-09 09:20) [3]

2nbv © (09.02.06 08:09)
> кто как работает с лукап полями.
Очень осторожно. Основной критерий - оно должно ссылаться на справочник с небольшим количеством записей или на тот, который открыт всегда.

>Пишут все руками засовывают в комбобоксы
Зачем? Есть же специальные ДБориентированные компоненты.

← →
nbv © (2006-02-09 09:23) [4]

2 Lexx:
1. .
> и не пользоваться стандартными TLoockUpCombBox для изменения
> существующих записей?

API сказал как. Пользоваться своими.
2. В частности MSSQL.

Лично я сейчас делаю примерно так: есть комбобокс, который хранит строковые данные полей справочников (которые отображаются) и идентификаторы(невидимые). Это комбобоксы когда надо обновляются. Немного муторно. И не знаю насколько оправдано...

← →
msguns © (2006-02-09 09:25) [5]

Пользуюсь крайне редко, т.к. избегаю редактирования непосредственно в гриде.
У лукапа три серьезных недостатка, ИМХО:
1. "Ручками" заполнять его актуальным содержимым справочника
2. Нет возможности редактировать справочник "на лету"
3. Коряво выглядит список справочника: нет там поисков, его нельзя отфильтровать, пересортировать, перетасовать колонки как надо и т.д. Короче, полный отстой по справнению с гридом

Справочники делаю на основе базового фрэйма собственной разработки с гридом, строкой состояния, кучей фич и т.д. Есс-но, можно тут же и корректировать сам справочник.

← →
msguns © (2006-02-09 09:27) [6]

Ах, еще..
Лукап никак не решает проблему показа "деревянных" справочников (а мой фрэйм показывает ;))

← →
nbv © (2006-02-09 09:34) [7]

На 100% согласен с тобой msguns!
Я тоже собираюсь писать что-то свое. Пусть не сильно навороченное, но более-менее универсальное. Расскажи плиз поподробнее про фрэйм...

← →
API (2006-02-09 09:43) [8]

У лукапа три серьезных недостатка, ИМХО:
1. "Ручками" заполнять его актуальным содержимым справочника
2. Нет возможности редактировать справочник "на лету"
3. Коряво выглядит список справочника: нет там поисков, его нельзя отфильтровать, пересортировать, перетасовать колонки как надо и т.д. Короче, полный отстой по справнению с гридом

1. Наследуется новый компонент, который заполняется автоматически.
2, 3. http://remenyak.com/img/sample.jpg - выпадающий список, в котором реализован поиск простым "набираю, обычно, первые две буквы", кнопка для открытия подчиненного списка (уже с гридом, сортировкой, кучей фич и пр.), и кнопка открытия диалога редактирования выбранного подчиненного элемента. Все таки, список с возможностью выбора "прямо тут" для многих подчиненных таблиц, в которых 3-10 значений, весьма полезен. Это из моего личного опыта общения с заказчикамии, - "А зачем нам еще одно открывающееся окно? Нет, давайте выбирать из выпадающего списка прямо тут".

← →
API (2006-02-09 09:46) [9]

Расскажи плиз поподробнее про фрэйм...

2 msguns © - А Вас за язык никто не тянул... :)))

← →
nnn (2006-02-09 10:07) [10]

2 API
имхо хорошая система. Единственное, что мне не понятно: зачем кнопочка изменения текущей записи...
В принципе так я и делал, только все на базе стандартных компонентов. Еще когда-то делал такую штуку, что если вводишь зачение, которого нет в справочнике, предлагается его туда добавить и автоматически добавляется.

← →
API (2006-02-09 10:17) [11]

зачем кнопочка изменения текущей записи

Например, это может быть поле выбора сотрудника. А при нажатии 2-й кнопки - открывается диалог, соответствующий этому сотруднику - а там - грид с номерами телефонов - нажимаешь на "позвонить" - и общаешься.
Это можно и через 1-ю кнопку - но тогда открывается промежуточный справочник сотрудников, в котором и нажимается кнопка "открыть" - это лишнее время, лишний траффик в сети (закачиваются данные в грид) и лишний клик. Для бухгалтеров, например, это время некритично. Но есть категория заказчиков (колл-центры, телефонные справочные службы и пр.), для которых критична каждая секунда, поэтому - вторая кнопка.

← →
API (2006-02-09 10:33) [12]

Кстати, ее легко выкинуть - это ж не единый компонент, а "паровозик", "собираемый" по желанию. Основной компонент - поле с выпадающим списком. А все остальные компоненты к нему "цепляются" простым указанием свойства "LookupControl" (ссылка на этот компонент). При "присоединении, они "тянут" от него требуемые свойства - источник данных, наименование поля данных, наименование службы подчиненного справочника и т.д, и т.п. Я им даже "посадочное место" определил - указываешь позицию, и он сам выравнивается относительно lookup-компонента на нужной позиции (1, 2, 3...) - это чтобы не возиться с "прицеливанием" - для единообразия интерфейса полезно. Еще есть кнопка выбора папок из дерева в БД, и несколько "экзотических" кнопок - так что и их , в случае необходимости, можно тоже "прицепить". :)

← →
nbv © (2006-02-09 10:44) [13]

API молодец. :)
Про кнопку понял. Это не сколько редактирование, сколько просмотр получается. Разумно.
И еще вопросик: Сам выпадающий список от LoockUpCombo наследуешь? Или от простого комбо?

← →
API (2006-02-09 11:00) [14]

Просто TComboBox. Прописываются свойства DataSource и DataField. А уж откуда и как тянуть списки - это зависит от конкретной реализации. У меня для этого на большинство таблиц - свои службы кеширования, внутри которых - потомок от TCustomClientDataSet в n-ном колене, с синхронизацией, коньюнктором фильтров. У компонента прописывается наименование службы кеширования, и, при необходимости, он запрашивает у ядра системы эту службу; если нашел - закачивает список; не нашел - ругается громко.

Есть еще и упрощенная версия от TEdit - для больших таблиц, когда выпадающий список нецелесообразен. Почему от TEdit, а не просто от TGraphicControl? Просто, в хозяйстве иногда полезно выделить и скопировать все/часть значения. Поэтому - TEdit.

← →
API (2006-02-09 11:08) [15]

P.S. Причем - не TDBComboBox, а именно TComboBox. Сделать его DB-aware компонентом - совсем несложно. Зато при этом можно избавиться от некоторых особенностей стандартных DB-aware компонентов Delphi, а имеено - при отключенных свойствах DataSource и/или DataField они становятся недоступными (disabled). Вместе с тем, на практике встечается ситуация, когда надо подобрать значение , не прописывая его в БД - например, тот же диалог задания параметров отчетов: выбрал значение, нажал "Сформировать", и все, выбранное значение более не нужно. Стандартные DB-aware компоненты в данном случае не подходят. Поэтому - TComboBox.

← →
nnn (2006-02-09 11:29) [16]

Спасибо за подробный ответ. Начинает прояснятся что к чему. Идея мне нравится. Пока в тумане остается механизм обновления данных...

← →
API (2006-02-09 11:46) [17]

Пока в тумане остается механизм обновления данных...

Тут нужно грамма три грибов. Без них - никак. :)

А если серьезно - через таблицу синхронизации. Основная задача - максимально сократить количество запросов чтения/записик БД, чтобы пользователи друг другу не мешали. Особенно критично, когда пользователей много. "Много" - в зависимости от пропускной способности сети, мощности сервера и используемой СУБД.

В качестве примера - табличка для MS SQL:

CREATE TABLE Сooperation ( Numeration Integer Identity NOT NULL, CreatorGUID Uniqueidentifier NOT NULL, ModifyDateTime DateTime NOT NULL, TableName nvarchar(255) NOT NULL, DataGUID Uniqueidentifier, FolderGUID Uniqueidentifier, IsCreated Bit NOT NULL, IsDeleted Bit NOT NULL, IsBuffered Bit NOT NULL, Buffer IMAGE, PRIMARY KEY (Numeration))

Заполнять ее или "вручную", по факту записи в БД (в той же транзакции), или триггером.

Но это все зависит от структуры БД, принципов, заложенных в основу самой структуры и многого-многого другого.

Так что, успехов!...

я пользуюсь и так, и так
все зависит от конкретной задачи
Например, лукап можно в гриде показать, при этом не обязательно иметь возможность его редактирования. Но при этом удобното, что с сервера не нужно тянуть заранее заготовленные текстовые поля, а только коды, которые можно расшифровать на клиенте из постоянно открытого справочника.
А простой комбо удобен, когда из подобных ему конструируется запрос с параметрами (т.е. датасета нет еще).

Использования лукапных полей стараюсь избегать везде, где только можно, т.к. датасет с ними обычно неслабо тормозит. Как выхожу из ситуации? Просто обогащаю селективные запросы датасета (на select и на refresh) связями с нужными мне справочниками. Причем, по возможности не при помощи join, а через where - join работает медленнее. То есть, получается что-то типа:

SELECT F1,...Fn FROM T1, T2 WHERE (T1.ID = T2.ID)

Приведенное, конечно, не есть универсальная панацея от всего - если по-каким-то причинам этого принципа придерживаться не удается, я не сильно заморачиваюсь по этому поводу. Разве что если серьезно упадет производительность приложения, вот тогда приходится почесать репу.

← →
API (2006-02-09 14:47) [21]

Использования лукапных полей стараюсь избегать везде, где только можно, т.к. датасет с ними обычно неслабо тормозит

Речь не совсем об лукапных полях. Скорее тема - о компонентах, используемых для установления отношения между таблицы.
То есть, другими словами - компоненты, обеспечивающие удобную и функциональную миграцию первичных ключей из таблиц-предков - во вторичные ключи таблиц-потомков.

А насчет "тормозящих лукапных полей"... Используйте InternalCalc. Там, правда, придется применить некоторые ухищрения при синхронизации, но это уже мелочи, по сравнению с выигрышем в скорости.

А в заголовке все же о полях... :)

Loockup поля Найти похожие ветки