MS Access 中的唯一性约束
在我必须为 MS Access 设计的数据库中,我有一个名为“Measurements”的表,其中存储某些测量参数(测量值、标准偏差等) - 每行都有一个整数 ID 作为其主键。
然后其他表使用外键关系链接到该测量表。 某些表包含两个不同的“measurementID”字段,它们都链接到这一测量表。 但是,每个测量值只能与这些字段中的一个相链接。
如何对多个表中的多个字段强制执行唯一性约束? 有办法吗?
In a database I'm having to design for MS Access, I have a table called "Measurements", which stores certain measurement parameters (Measured Values, Std Deviation, etc.) - each row has an integer ID as its primary key.
Other tables then link to this measurement table using foreign key relationships. Some tables contain two different "measurementID" fields, which both link to this one measurement table. However, each measurement should only ever be linked to by one of these fields.
How can I enforce a uniqueness constraint over several fields in several tables? Be there a way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
此类约束确实可以在 ACE/JET 中使用
CHECK
约束来实现。那些说他们通常会使用触发器来处理此类事情的人并没有意识到 ACE/Jet 和 SQL Server 中的
CHECK
约束之间的区别:在 SQL Server 中,它们不能包含子查询,这意味着它们不能引用同一表中其他行或其他表中的值,而在 ACE/Jet 中可以。在理想的(但据我所知还不存在)SQL-92 产品中,所描述的唯一性将在模式级别使用
ASSETION
来实现。 由于 CHECK 约束是表级的,并且仅在对其定义的表进行 UPDATE 或 INSERT 操作时才进行检查,因此您需要放置适当的 CHECK 对所有引用表的约束(同样适用于 SQL Server 触发器)。 这是一个简单的例子:但是,我想知道您是否有子类(即可以键入 ID 表示的每个实体),在这种情况下您应该能够使用
FOREIGN KEY
和 row-级别CHECK
约束(或者验证规则,如果您更熟悉 MS Access 接口而不是CHECK
约束所需的 SQL DLL)。 该逻辑比表级 CHECK 约束更容易实现,只需注意 CASCADE 引用操作中的循环即可。 这是另一个简单的例子:Such constraints can indeed be implemented in ACE/JET using
CHECK
constraints.The person who said they would usually use triggers for this kind of thing possible isn't aware of the difference between
CHECK
constraints in ACE/Jet and SQL Server respectively: in SQL Server they cannot include subqueries, meaning they cannot refer to values in other rows in the same table or to other tables, whereas in ACE/Jet there can.In an ideal (but as yet AFAIK non-existent) SQL-92 product, the uniqueness described would be implemented using an
ASSETION
, being at the schema level. Because CHECK constraints are table-level and are only checked when the table on which they are defined areUPDATE
d orINSERT
ed, you would need to put appropriateCHECK
constraints on all the referencing table (the same would apply to SQL Server triggers). Here's a quick example:However, I'm wondering if you have subclasses (i.e. each entity represented by an ID can be typed), in which case you should be able to use
FOREIGN KEY
s and row-levelCHECK
constraints (or Validation Rules if you are more comfortable with the MS Access interface than SQL DLL that is required forCHECK
constraints). The logic will be easier to implement than table-levelCHECK
constraints, just watch for cycles inCASCADE
referential actions. Here's another simple example:Microsoft ACE/Jet 引擎不支持触发器,而这通常是实现此类功能的方式。
编辑:正如 @onedaywhen 所指出的,JET 4.0 及以上版本确实支持检查约束,但跨两列实现异或类型约束并不简单。
如果您使用的是 Access Forms,您可以实现表单的更新前事件并检查您的约束条件。
Microsoft ACE/Jet engine does not support triggers, which is how you would normally implement this type of functionality.
EDIT: As pointed out by @onedaywhen, JET 4.0 onwards does support check constraints, but it is not simple to implement an xor type constraint across two columns.
If you are using Access Forms, you could implement the before update event of the form and check your constraint criteria.
关于 Access 的可能性,Mitch 是正确的。 然而,假设您在某处有 BL,这就会逐渐成为合法的业务规则。 这就是我最有可能做的事情。
Mitch is right about what's possible in Access. However, assuming you have a BL somewhere, this is edging into what's legitimate as a Business Rule. That's what I'd most likely do.
鉴于您正在设计这个数据库。 您确定您的表结构遵循标准规范化规则吗?
表 A 中的一行能够引用表“测量”中的两行,这听起来是一种不寻常的结构,具体取决于您正在查看的 A.row 字段。
我感觉表 Measurments 中的数据确实需要分成两个或
更多桌子。
Given that you are designing this database. Are you sure your table structures are following standard normalisation rules.
It sounds an unusual structure for a row in table A to be able to reference two rows in table Measurements depending upon which A.row field you are looking at.
I get the feeling that the data in table Measurments really needs to be split into two or
more tables.
我自己对触发器和检查约束持谨慎态度,主要是因为我在没有它们的情况下开发了大部分应用程序(Access/Jet 和 MySQL/MyISAM)。 我同意 BobClegg 的观点,这听起来像是超类型/子类型的情况。 在这种情况下,您将使用一个连接表,该表在外键上具有唯一索引,并有一列指示它的测量类型。 FK 上的唯一索引将阻止添加第二种类型。 这也意味着您的主记录中不会有空字段。 当然,一个空数字字段不是存储问题,但两个互斥字段对我来说总是看起来像一个设计错误。
I am myself wary of triggers and check constraints, mostly because I've developed most of my apps without them (Access/Jet and MySQL/MyISAM). I agree with BobClegg that this sounds like a supertype/subtype situation. In that case you'd use a join table with a unique index on the foreign key and a column indicating which type of measurement it was. The unique index on the FK would prevent the addition of a second type. It would also mean you wouldn't have empty fields in your main record. Certainly one empty numeric field is not a storage problem, but two fields that are exclusive always looks like a design error to me.