Звучит так, будто вы пытаетесь поместить слишком много кода в базу данных. Если вас интересуют строки определенного отношения, которые удовлетворяют определенному предикату, просто выполните оператор select
с соответствующим предложением where
в клиентском коде. Иметь представления, которые принимают предикаты в качестве параметров, - это заново изобретать колесо, которое sql уже хорошо решает.
С другой стороны, я вижу аргумент для хранения самих запросов в базе данных, чтобы они могли быть объединены в более крупные отчеты. Эти два еще лучше обрабатываются кодом приложения. Я мог бы подойти к такой проблеме, используя библиотеку, которая хороша для динамической генерации sql (например, sqlalchemy), и затем сохраняя представления запросов (объекты выражений sqlalchemy 'pickleable') в виде BLOB-объектов в базе данных.
Другими словами, базы данных являются представителями фактов . Вы храните в них знания. приложения должны действовать по запросам пользователей . Когда вы обнаруживаете, что определяете преобразования для данных, на самом деле это скорее вопрос ожидания и реализации запросов реальных пользователей, а не просто точного сохранения знаний.
Представления лучше всего использовать, когда схема неизбежно изменяется, поэтому вы можете оставить старые приложения, которым не нужно знать о новой схеме, в рабочем состоянии.