![]() |
1
7
考虑两个人员及其地址表:
人的主键(唯一标识每一行)是
一些示例数据: 人
地址簿
在这个例子中,kirk有两个地址:一个“home”和一个“work”。这两个中的一个可以(也应该)作为外键(如交叉引用)在
斯波克只有一个带有“其他”标签的地址。因为这是斯波克唯一的地址,所以“其他”的值应该放在
这个模式有一个很好的效果,可以防止同一个人通过意外地重用标签来复制自己的任何地址,同时允许所有其他人使用他们喜欢的任何地址标签。
此外,在
|
![]() |
2
3
为什么完全正常化会“一团糟”?这正是标准化减少混乱的原因。 |
![]() |
3
3
不要害怕规范化数据。标准化,比如 John mentions ,是解决方案而不是问题。如果您试图取消数据的规格化,只是为了避免一些连接,那么将来您将给自己带来严重的麻烦。在拥有一个合理大小的数据集之后,尝试沿着行重构这类数据是没有意思的。 我强烈建议你退房 Highrise 来自36个信号。最近我在找一个在线联系人经理时向我推荐了它。它做得太对了。实际上,到目前为止,我唯一的反对意见是,我认为付费版本太贵了——仅此而已。 今天的情况是,我不适合扁平地址配置文件。我有4-5个经常使用的电子邮件地址,5个电话号码,3个地址,几个网站和即时消息配置文件,所有这些都包括在我的联系人配置文件中。如果你现在开始建立一个联系人管理系统,并且你不受体系结构限制的约束(想想gmail cantacts被锁定到一个电子邮件地址),那么请帮你的用户一个忙,让你的联系人结构尽可能灵活(规范化)。 干杯,D. |
![]() |
4
1
我知道sqlite,但这并没有真正的帮助——我正在讨论如何为存储这些数据制定最佳模式(不管数据库如何)。 |
![]() |
5
1
据约翰所言,我不知道经典的标准化模式会有什么问题。你没有提供太多信息,但是你说用户和地址之间有一对多的关系,所以我会选择一个标准的解决方案,在地址关系中为用户提供一个外键。 |
![]() |
6
0
如果假设每个用户都有一个或多个地址、一个电话号码等,则可以有一个“用户”表、“地址表”(包含主键,然后是对用户的非唯一引用),电话号码也可以有相同的表-允许多行具有相同的用户ID外键,这将使查询“用户X的所有地址”非常简单。 |
![]() |
7
0
我没有脚本,但我有MySQL供您使用。在此之前,我应该提到在SQL中存储vCard似乎有两种逻辑方法:
可能很容易实现(取决于您对数据所做的操作),但如果您有许多条目,则搜索速度会很慢。 如果这只是为了你,那么这可能有效,(如果有什么好处,那就是 从未 然后,您可以使用共享的漂亮模块(或与您共享的其他人)来处理vCard客户端或服务器端。 我看过vCard的发展和 知道 将会有 以后会有一些变化,所以我用三张桌子。 第一张是卡片,(这主要链接回我现有的表格-如果你不需要它,那么你的可以是一个精简版)。 第二个是卡片定义(在vCard语言中,它似乎被称为profile)。 最后是所有卡的实际数据。 因为我让dbix::class(是的,我就是其中之一)完成所有的数据库工作,所以,(三个表)对我来说似乎工作得相当好, (尽管很明显,您可以将类型拧紧以匹配 rfc2426 更紧密地, 但在大多数情况下,每段数据都只是一个文本字符串。) 我没有从那个人那里规范化地址的原因是我已经有了一个 我的数据库中的地址表和这三个地址表仅用于非用户联系人的详细信息。
这不是最好的SQL,但我希望能有所帮助。 |