автоматизированные сценарии DDL: какой функционал прогнозировать? - PullRequest
1 голос
/ 26 мая 2009

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

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

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

1 Ответ

2 голосов
/ 26 мая 2009

Это хороший вопрос, который нужно задать себе - общность - это (в общем случае ;-) хорошая вещь, но когда вы наблюдаете чрезмерное обобщение, вы можете столкнуться с комбинаторным взрывом. Можете ли вы позаботиться о том, чтобы требуемые биты DDL генерировались «вовремя», когда пользователь пытается их использовать (конечно, сохраняя некоторый «кэш» битов, которые уже оказались полезными)?

Если это просто невыполнимо, то, учитывая возможность экспоненциального роста «потенциально полезных представлений» в количестве таблиц и столбцов, я бы неохотно выбрал стратегию «делать только то, что известно как полезно / желательно» (и стараться сделать так, чтобы пользователи очень легко давали мне знать, когда они нуждаются во мне, чтобы добавить что-то еще ...).

...