Добрый день!
Довольно давно уже для хранения параметров запрашиваемых с клиента наборов данных (возможные фильтры, группировки, связи мастер-деталь, столбцы, их заголовки и т.п.) используем связку из двух таблиц, из которых первая хранит список наборов данных (по сути - список имен представлений), а вторая - список имен полей в каждом наборе с данными об очередности отображения, видимости, формате и т.п. В итоге на клиенте динамически формируются SQL-запросы и параметры Grid на основе этих таблиц. Есть, правда, еще третья таблица, в которой пользовательские параметры хранятся (очередность, видимость), но это уже лирика. Вариант оказался удобным, но лишь до тех пор, пока разработчик не забывает обновить таблицу со списком полей после корректировки метаданных представления (описаний новых полей нет, зато могут оказаться поля, отсутствующие в реальном представлении).
К тому же, настал момент, когда для показа на клиенте данных, полученных из представления стало недостаточно. Точнее, понадобилось реализовать разные свертки данных (читай - группировки) и фильтрацию на основе данных, отсутствующих в основном наборе, что порой не совсем удобно делать в представлении, но легко реализуется в ХП. Добавить ХП в указанную схему по сути не сложно, и список параметров коротким запросом можно получить.
Но в БД изначально есть список полей представлений и список параметров ХП, которые по сути приходится дублировать, что частенько приводит к противоречивости данных. Триггеры на системные таблицы, как я не понимаю, - не только не комильфо, но еще и не восстанавливаются после B/R.
Существуют ли другие подходы к данной задаче?
FB 2.5.6
Довольно давно уже для хранения параметров запрашиваемых с клиента наборов данных (возможные фильтры, группировки, связи мастер-деталь, столбцы, их заголовки и т.п.) используем связку из двух таблиц, из которых первая хранит список наборов данных (по сути - список имен представлений), а вторая - список имен полей в каждом наборе с данными об очередности отображения, видимости, формате и т.п. В итоге на клиенте динамически формируются SQL-запросы и параметры Grid на основе этих таблиц. Есть, правда, еще третья таблица, в которой пользовательские параметры хранятся (очередность, видимость), но это уже лирика. Вариант оказался удобным, но лишь до тех пор, пока разработчик не забывает обновить таблицу со списком полей после корректировки метаданных представления (описаний новых полей нет, зато могут оказаться поля, отсутствующие в реальном представлении).
К тому же, настал момент, когда для показа на клиенте данных, полученных из представления стало недостаточно. Точнее, понадобилось реализовать разные свертки данных (читай - группировки) и фильтрацию на основе данных, отсутствующих в основном наборе, что порой не совсем удобно делать в представлении, но легко реализуется в ХП. Добавить ХП в указанную схему по сути не сложно, и список параметров коротким запросом можно получить.
Но в БД изначально есть список полей представлений и список параметров ХП, которые по сути приходится дублировать, что частенько приводит к противоречивости данных. Триггеры на системные таблицы, как я не понимаю, - не только не комильфо, но еще и не восстанавливаются после B/R.
Существуют ли другие подходы к данной задаче?
FB 2.5.6