自动化 DDL 脚本：需要预测多少功能？
我有一个脚本可以生成 DDL 脚本来定义规范化数据库的物化视图。 有些表具有诸如“所有者”之类的列，它们指向特定的数据库用户，然后我可以为其创建视图，该视图将仅显示当前数据库用户创建的表的行。 在某些情况下，从安全性和便利性的角度来看，这种视图都是有益的——例如，仅显示自己的多项选择测验结果。
问题是，除了少数表格之外，还有很多表格，我可以想象有人要求这样的视图，但无法想到具体的用例。 但是，我认为有时这种通用功能可能很有用，因为我无法总是预见所有用例。
我的问题是，我应该自动生成多少个个性化视图？ 对于数百个表来说，这为构建、测试和基准测试流程增加了大量时间，尽管它们是自动化的。 您是否会犯错误，选择可能永远不会使用的额外功能，或者只提供那些已被要求/您知道有用的视图？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个值得问自己的好问题——概括性（通常；-）是一件好事，但正如您所观察到的，过度概括可能会让您陷入组合爆炸。 当用户尝试使用 DDL 时，您是否可以安排“及时”生成所需的 DDL 位（当然，保留一些已证明有用的位的“缓存”）？
如果这是不可行的，那么，考虑到“潜在有用的视图”在表和列的数量上呈指数级增长的可能性，我会不情愿地选择“只制作已知有用/所需的内容”策略（并努力使当用户需要我添加更多内容时，用户可以非常轻松地让我知道...）。
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...).