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

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

Но в БД изначально есть список полей представлений и список параметров ХП, которые по сути приходится дублировать, что частенько приводит к противоречивости данных. Триггеры на системные таблицы, как я не понимаю, - не только не комильфо, но еще и не восстанавливаются после B/R.

Существуют ли другие подходы к данной задаче?
FB 2.5.6

Мимопроходящийне нужно превращать "автоматизацию пивного ларька" в универсальный OLAP-сервер.Изменить заголовок столбца в гриде или сменить сортировку по умолчанию гораздо удобнее сделать один раз в БД, чем править клиентское приложение и обновлять его везде.

PEAKTOPшо мешает вставить в него следующие строки:Об этом я уже думал и, скорее всего, такой костыль будет полезен. В общем случае, можно, конечно, собрать перечень полей в обратной последовательности, приняв за базовый набор RDB$, тогда и несуществующих полей не будет, и новые появиться могут, хоть и с не всегда заполненными параметрами отображения. Но в этом варианте сложность в том, что нужно еще и пользовательские параметры очередности отображения подхватить - читай переиндексировать выходной набор на основе пользовательских параметров.

Мимопроходящийв результате у тебя будет "размазанный" по туевой хуче точек интерфейс.Нисколько. Вся конфигурация табличных датасетов в одном месте, в двух таблицах.

fraksЯ меняю это в приложении, потом сую exe в базу.IMHO, это из пушки да по воробьям получается :-)
P.S. Об обновлении версий тут речи не было :-)

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

чччДПри изменении метаданных представлений сбрасывай этот флаг. Также сбрасывай его при изменении физических метаданных в базе ( см. https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-psql-ddltriggers.html - т.е. "триггеров на системные таблицы" больше не нужно).Идея хороша, но миграция на 3.0 еще только в планах, и не совсем понятно, сколь близких :-)