automated DDL scripts: how much functionality to predict?

Question

I have a script that generates DDL scripts to define materialized views for a normalized database. Some tables have columns like "owner" that point to a particular database user, which I can then create views for that will show only the rows of a table that the current database user created. Such views in some cases would be beneficial both from a security and convenience standpoint--for example, showing only one's own multiple-choice quiz results.

The thing is, aside from a handful of tables, there are many tables where I could imagine someone asking for such a view, but can't think of a concrete use case. However, I think that sometimes such general functionality can be useful, because I can't always foresee all use cases.

My question is, how many of these personalized views should I bother automatically generating? For several hundred tables, this adds a good chunk of time to the building, testing, and benchmarking processes, automated though they are. Would you err on the side of extra functionality that may never be used, or on the side of having available only those views that have been asked for/that you know will be useful?

Answer 1

This is a good question to ask yourself -- generality is (generally;-) a good thing, but as you observe overgeneralizing can throw you into a combinatorial explosion. Can you possibly arrange for the required bits of DDL to be generated "just in time" when a user tries to make use of it (of course keeping some "cache" of the bits that have already proved useful)?

If that's just unfeasible, then, considering the possibility for "potentially useful views" to grow exponentially in the number of tables and columns, I'd reluctantly pick the "make only what's known to be useful/desired" strategy (and strive to make it very very easy for users to let me know when they need me to add something more...).