将 Oracle 表限制为单行的简单约束
我正在寻找一种简单的方法来将应用程序配置表限制为 1 行。我知道我可以使用包含子查询的虚拟列或顶部的物化视图来完成此操作,但实际上这是一个简单的表,我想要一个约束,它不需要比创建表更多的行来实现。
我想到的最简单的方法是将 ID 字段设置为 1,并且检查约束 ID 必须为 1 - 但这会向表中添加一个令人困惑的额外字段,所以我希望有一些明显的我遗漏的东西,就像检查约束,其中 UNIQUE_FIELD = MAX(UNIQUE_FIELD),这是不允许的。
I'm looking for a simple way to limit an application configuration table to 1 row. I know I can do this with a virtual column containing a subquery, or a materialized view on top, but really it's a simple table I'd like a constraint that doesn't take more lines to implement than to create the table.
Simplest way I've thought of is an ID field set to 1, and a check constraint that the ID has to be 1 - but this adds a confusing extra field to the table so I'm hoping there's something obvious I'm missing, like a check constraint where UNIQUE_FIELD = MAX(UNIQUE_FIELD), which is not allowed.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
最简单的是在常量上建立基于函数的唯一索引
替代方案:
您可以查看 DUAL,而不是表
这实际上意味着任何更新实际上都是创建或替换视图,这可能不合适。如果函数从包体或全局应用程序上下文返回值可能会导致无效问题,那么它可能是一种解决方法。
在 11g 中,可以选择只读表(或者,在早期版本中,只读表空间中的表)。
Simplest is a unique function-based index on a constant
Alternatives:
Rather than a table, you could have a view over DUAL
That would really mean any UPDATE would actually be a CREATE OR REPLACE VIEW which may not be appropriate. Functions returning values from a package body or global application contexts might be a workaround for that if it causes invalidation problems.
With 11g a READ ONLY table (or, in earlier versions, a table in a read only tablespace) is an option.
以下是一些选项:
Here are some options:
SELECT 1024 as buffer_size, '/var/tmp' as temp_dir, 'other constant' as other_constant from dual
. This isn't a solid solution.(未经测试)
SQL 没有简洁的语法来将空属性集指定为键,这很遗憾,因为它将消除对冗余额外列的需要。这里的有效键实际上是空集,这就是为什么我使用 UNIQUE 约束而不是 PRIMARY KEY 作为对 x 的约束。
(untested)
SQL doesn't have a concise syntax to specify the empty set of attributes as a key, which is a shame because it would eliminate the need for the redundant extra column. The effective key here actually IS the empty set, which is why I've used a UNIQUE constraint instead of PRIMARY KEY for the constraint on x.