Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Настройка видимости столбцов запроса на клиенте [D2005, XP]

Страницы: 1 2 >
девушка © (2009-01-16 14:07:00)
Добрый день!

При выведении пользователю данных в табличном виде удобно иметь (или очень хочется) следующие возможности:
1. хранить русскоязычные названия полей в БД, чтобы не именовать все в приложении в вручную.
2. создавать эти самые колонки таблицы(TDBGrid) динамически, т.е. знать список и свойства полей формируемого запроса.
3. давать возможность пользователю скрывать/показывать столбцы и сохранить эти настройки в БД.
4. давать возможность пользователю накладывать на запрос определенные (программистом :) ) условия - типа поиска по подстроке и т.д.

Возможностей реализовать это много.

п. 4 можно реализовать а) введением в запрос параметра б) динамическим формированием запроса (б1 - на клиенте, б2 - на сервере)
п.1,2,3 требуют, ИМХО, как минимум, создания в БД таблиы, которая хранит информацию о полях запроса и таблицы с пользовательскими настройками полей.

На данный момент есть следующий вариант решения:
В БД есть таблица с описанием полей запросов (_SQL_FIELDS). Таблица, хранящая пользовательские настройки (_USER_SQL_FIELDS) видимости и колонок таблицы.
Программа формирует SQL запрос, который забирает из БД все поля запроса, а потом, в зависимости от их видимости в _USER_SQL_FIELDS, создаются соответствующие колонки в DBGrid.
Условия на запрос налагаются так:на сервере есть ХП, которая принимает ряд параметров и (в зависимости от назначения запроса) выбирает (case) нужный запрос и подставляет в него параметры.

Описаный метод имеет очевидный недостаток - клиенту передается много не используемых данных.

----
Сразу бы хотелось сказать про выбранный метод формирирования условий запроса.
Динамический SQL я пока отвергаю из-за сложности тестирования, невозможности передавать параметры (?) и необходимости изменять систему прав.
Формирование запроса на клиенте при наличии таблицы списка условий на запрос и частей from и where - вполне работоспособный вариант и туда тоже можно подставлять параметры - но его пока отложила, поскольку понравилось делать выборку с помощью ХП (можно передать параметры, а внутри ХП разрулить правильные они или нет и т.д.).

Впринципе, хотелось бы для выборок данных использовать вызовы ХП.

Как лучше решать такие проблемы?

БД: MS SQL 2005.

MsGuns (2009-01-16 15:39:00) [1]
>1. хранить русскоязычные названия полей в БД, чтобы не именовать все в приложении в вручную.

Если сервер позволяет хранить описатели колонок, то можно табличные названия хранить там же, например отделяя их запятой от полного названия. При открытии датасета считывать из метаданных заголовки и присваивать их соотв. свойтсвам филдов.
Хотя в общем случае затея гнилая, т.к. неизвестно что делать с запросами из нескольких таблиц, а также с вычисляемыми полями. В целом затея гнилая ИМХО.
Отображаемые в сетках табличные данные - суть чисто клиентская фича, он и должен ею заниматься.

>2. создавать эти самые колонки таблицы(TDBGrid) динамически, т.е. знать список и свойства полей формируемого запроса.

Колонки и так создаются динамически при открытии НД. Также как и список и свойства полей. Правда с типом полей в некоторых случаях могут быть траблы. Например, АДО децимальные поля может интерпретировать как BCD, причем с потерей значности

>3. давать возможность пользователю скрывать/показывать столбцы и сохранить эти настройки в >БД.

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

Я использую иную технологию: отображаются не все поля датасета, а некоторые "основные", но при этом есть Stay-on-top форма (показываемая или прятаемая по желанию пользователя), отображающая полную информацию о текущей строке. На ней же управление отображением или прятанием колонок (например, если нужно посортировать по некторому полю, в данный момент в сетке не представленному). Сохранение же в файл не деляется.

>4. давать возможность пользователю накладывать на запрос определенные (программистом :) ) >условия - типа поиска по подстроке и т.д.

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

В целом советую посмотреть как подобные вещи реализуются в качественных профессиональных приложениях.

Медвежонок Пятачок (2009-01-16 14:49:00) [2]
Он уже написан. Давно

девушка видимо хочет свой персональный.
с перламутровыми пуговицами.

Игорь Шевченко (2009-01-16 14:46:00) [3]
Медвежонок Пятачок © (16.01.09 14:45) [21]

> пишется "универсальный решатель задач и всего остального"

Он уже написан. Давно

Игорь Шевченко (2009-01-16 14:45:00) [4]
Бессмысленны все пункты, кроме 4-го (это я по своему печальному опыту говорю, тоже, в свое время развлекался подобием словаря данных) - польза от таких усложнений не стоит потраченной работы.
Что касается запрета на показ/отображения столбцов, то это делается легко и просто (равно как и сохранение порядка и размера столбцов) в том же EhLib-е. Правда до хранения этого безобразия в базе никто пока не додумался, а все хранится там, где запускается (на компьютере пользователя, в реестре или в ini-файле)

Медвежонок Пятачок (2009-01-16 14:45:00) [5]
пишется "универсальный решатель задач и всего остального"

Медвежонок Пятачок (2009-01-16 14:44:00) [6]
create procedure test
@p_....
@p_....
@p_columns varchar(max) out
as
select * from test
set @p_columns = 'col1=кол1' + chr(13)+chr(10) + 'col2=кол2'+......

и в афтер опен пройтись по филдам

Sergey13 (2009-01-16 14:42:00) [7]
> [18] девушка (16.01.09 14:35)
> Что нужно видеть пользователю пока окончательно не определено.

Это как это? А что прога будет делать определено? А как же вы проектируете БД, что не знаете что нужно пользователю?

девушка (2009-01-16 14:35:00) [8]

> А что за программа? Я к тому, что ИМХО, то что выводится
> пользователю он ДОЛЖЕН видеть, даже если ему кажется, что
> это ему как бы не нужно. А посему, ИМХО опять же, заниматься
> подобными рющечками - только БЕСПОЛЕЗНО загружать и усложнять
> программу. По крайней мере для большОй части программ.

Что нужно видеть пользователю пока окончательно не определено.
Т.е. он может в любой момент потребовать еще пару-тройку столбцов вывести и переназвать попросить.

На данный момент реализован функционал с затаскиванием всех полей выборки и пометкой их на видимость.

> Оно блондинко.

Оно в печали просто

Медвежонок Пятачок (2009-01-16 14:31:00) [9]
имеется ввиду фильтрация данных на клиенте?

where- это на клиенте?

девушка (2009-01-16 14:30:00) [10]

> Ехлибовский грид дает возможность юзеру уточнить where,
> которое приводит к сужению выборки установленной в дизайне.
> А не к расширению этой выборки.
> Так что права и sp здесь ни при чем

имеется ввиду фильтрация данных на клиенте?

Медвежонок Пятачок (2009-01-16 14:29:00) [11]
Оно блондинко.

Sergey13 (2009-01-16 14:29:00) [12]
> [0] девушка (16.01.09 14:07)

А что за программа? Я к тому, что ИМХО, то что выводится пользователю он ДОЛЖЕН видеть, даже если ему кажется, что это ему как бы не нужно. А посему, ИМХО опять же, заниматься подобными рющечками - только БЕСПОЛЕЗНО загружать и усложнять программу. По крайней мере для большОй части программ.

Медвежонок Пятачок (2009-01-16 14:28:00) [13]
на самом деле мной движет совсем иное

А. Понятно. Удачи.

Ega23 (2009-01-16 14:28:00) [14]

> может быть, но на данный момент для запросов из БД предпочитаю
> использовать ХП

При чём тут ХП или не ХП????

девушка (2009-01-16 14:28:00) [15]

> а при чем здесь права?

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

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

Медвежонок Пятачок (2009-01-16 14:27:00) [16]
Ехлибовский грид дает возможность юзеру уточнить where, которое приводит к сужению выборки установленной в дизайне. А не к расширению этой выборки.
Так что права и sp здесь ни при чем

девушка (2009-01-16 14:26:00) [17]

> Ну а чего тогда говоришь что движет тобой :
>
> 1. хранить русскоязычные названия полей в БД, чтобы не именовать
> все в приложении в вручную.

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

Медвежонок Пятачок (2009-01-16 14:25:00) [18]
а при чем здесь права?

девушка (2009-01-16 14:24:00) [19]

> п. 4 уже реализован а ЕхЛибе, причем легко и изящно в отличие
> от вышеприведенных соображений

может быть, но на данный момент для запросов из БД предпочитаю использовать ХП - т.к. проще модифицировать и с распределением прав все прозрачно

Медвежонок Пятачок (2009-01-16 14:21:00) [20]
Ну а чего тогда говоришь что движет тобой :

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »