我最近被介绍到新的 Access 2007 功能,它是多值字段。我最初的印象是,在单个字段中使用多个值是个坏主意。传统上,如果您希望一条记录具有多个字段值,您将创建另外两个表并将它们与外键链接。这允许轻松查询并确保重复值引用相同的项目。将列表保存在单元格中似乎违反了数据库的目的。
这些不会让我感到肮脏的领域有什么好的用途吗?
我最近被介绍到新的 Access 2007 功能,它是多值字段。我最初的印象是,在单个字段中使用多个值是个坏主意。传统上,如果您希望一条记录具有多个字段值,您将创建另外两个表并将它们与外键链接。这允许轻松查询并确保重复值引用相同的项目。将列表保存在单元格中似乎违反了数据库的目的。
这些不会让我感到肮脏的领域有什么好的用途吗?
看:
我与访问项目经理 Suraj Poozhiyil 进行了长时间的交谈...... Suraj 和我都完全同意开发人员不需要使用多值字段。了解数据库的人已经有了实现多对多关系的好方法,并且不会从多值字段中获益。
因此,我对开发人员的明确而肯定的建议是不要使用多值字段。除了潜在的痛苦之外,他们没有任何东西可以提供给我们。
这里没有真正回答这个问题,但读者可能会注意到,围绕多值数据库的想法有一个完整的利基行业:
这些数据库与关系数据库的不同之处在于它们具有支持和鼓励使用具有值列表的属性的功能,而不是所有属性都具有单个值
由于在这种情况下,数据库引擎对其查询语言进行了扩展,以适应其表的多维性质(我假设 Access 可能没有),因此它与 Access 中的多值字段并没有真正可比性。但无论如何都是一个有趣的平行(对于以前甚至没有听说过多值数据库的人)。
Access 市场的很大一部分是非开发人员,但属于技术用户。他们可能不了解标准化的价值,但他们可以得到一些工作。他们只需要一些简单的东西,这比人们输入的自由文本字段要好,你希望他们都输入相同的东西。
随着他们了解更多,他们可能会开始使用其他表和外键。但是,有时,多值字段就足够了。
多值字段的想法是支持轻松创建报告/界面对象,此外,可以创建一个显示问题类别的表单。与其做一些紧张的工作,不如上帝禁止加入,据说存储起来更简单:
机械、电气
作为字段中的值而不是
机械电气
就我个人而言,我不喜欢它,并假设这种类型的字段是为像会计师这样的非技术人员创建的:)(开玩笑)。不认真,不要使用它,除非您正在创建一个很少有人会使用并且很少有人会使用的愚蠢工具。
处理这个问题的正确方法是连接,没有重复,并且列内没有多值(无论如何这都是 3nf)。
创建它的另一个原因是支持共享点列表中的多值。
乔恩
多值字段可以轻松地让您不必创建新表和关系。
苏打水 --> 类型
为什么我需要一张全新的桌子只是为了说百事可乐有规律的、节食的等等。
我希望他们允许我们提供多值字段列,然后它们就像一张表,但工作量要少得多
Necro-post...我认为问题应该在线程刚开始时已经修改,但我现在不会进行编辑过程。
问题是“多值字段是个好主意吗?”
应该问的真正问题是“RDBMS 中的多值字段是个好主意吗?”
正如其他人所指出的,有一个完整的 MVDBMS 模型支持多值字段。我是这方面的专家,并且使用该模型已经超过 30 年。当然,在我和每天使用该平台的其他人看来,这是一个好主意。是的,Caché 本身不仅拥有出色的多维模型,而且还支持 MVDBMS 模型。所以在这方面,问题的答案是肯定的。
但是对于 RDBMS,特别是 MS ACCESS,答案几乎肯定是否定的,因为 RDBMS 模型和该平台都不支持该概念。
IMO,接受的答案是正确的,因为它不仅回答了所提出的问题,而且回答了打算提出的问题。但要一丝不苟,对于提出的确切问题,接受的答案是不正确的。
我相信真正的答案是“如果 DBMS 平台支持它,这只是一个好主意,MVDBMS 和其他 NoSQL 平台可能支持,RDBMS 支持不支持。”
拒绝吧!
如果您正在学习 SQL,请学习正确的方法并规范化您的表。如果您知道数据库设计,请正确执行。并非每个功能都必须使用。
我真的不喜欢多值字段。也许他们这样做是为了更容易与其他多值系统(如旧的 PICK/Unidata 系统)交互。我敢打赌,通过大量使用 SQL Server 的这一新功能来提升 Access 数据库的大小会很有趣。