相关疑难解决方法(0)

在数据库字段中存储电话号码的良好数据结构是什么？我正在寻找足够灵活的东西来处理国际号码,还有一些能够有效查询号码各个部分的东西.

编辑:只是为了澄清这里的用例:我目前将数字存储在一个varchar字段中,并在客户输入时将其保留.然后,当代码需要该数字时,我将其标准化.问题是,如果我想查询几百万行来查找匹配的电话号码,它涉及一个功能,如

where dbo.f_normalizenum(num1) = dbo.f_normalizenum(num2)

这是非常低效的.当只是一个varchar字段时,寻找像区域代码之类的东西的查询变得非常棘手.

[编辑]

人们在这里提出了很多好建议,谢谢!作为一个更新,这里是我现在正在做的事情:我仍然在varchar字段中存储与输入完全相同的数字,但是在查询时没有规范化事物,我有一个触发器,可以在插入记录时完成所有工作或更新.所以我对我需要查询的任何部分都有内联或重要内容,并且这些字段被编入索引以使查询运行得更快.

我正在尝试规范化地址.

下图显示了我认为的这个问题的相关表格.我想知道如何将ZipCodes集成到模型中.这将是国际地址,所以我知道Zip/PostalCode并没有在任何地方使用.我认为City :: ZipCode是1 :: 0-n(我读过其他人说这并非总是如此,但他们从未提供过证据).如果他们是正确的,那么我想这将是一个多对多的关系.由于每个地址最多只能包含一个ZipCode,而ZipCode可以包含许多地址,因此我在如何规范化此模型时会丢失.

由于地址可能包含或不包含ZipCode,因此我需要避免在地址表中将其作为可空的FK.

编辑: 只是想强调所提供的实体和属性从实际数据库中大幅缩减.它仅用作参考并解决我对将zipcodes包含在模型中的问题的关注.

在我们的数据库模型中,我们有一个受益人实体.受益人可以是自然人或公司受益人; 一个物理受益人有许多属性,如姓名,性别等; 此外,受益人(公司或自然人)可以是外国的,也可以不是; 这种进一步的区别转化为"共同"属性集的不同域值(例如,在我居住的意大利,税ids可能具有与英国税ids不同的数据格式).

我们现在正在重新设计受益人表,因为最初从事数据库分析和建模工作的开发人员做了一个(IMO)短视选择.他将主键约束放在属性BeneficiaryName上,用于存储公司名称(例如"Microsoft Corporation")(如果是公司受益人)或姓氏(例如Smith)用于实际受益人.这样我们就有了(不可接受的)约束,我们的数据库中不能有超过1名姓氏为"Smith"(或名为"Smith"的公司)的受益人.

我对这种"重新分解"的方法将引入受益人实体的概括; 我会

1. 清洁受益人表,仅保留常见数据;
2. 将一个代理主键添加到受益人表,我们称之为BeneficiaryID;
3. 拆分受益人表,创建两个子实体(CorporateBeneficiary&PhysicalBeneficiary,受主受益人表中的标志区分),与受益人表的1..1关联(外键将参考BeneficiaryID)
4. 查找(有意义的)CorporateBeneficiary和PhysicalBeneficiary的主键;

这应该解决上述BeneficiaryName的唯一性问题.到目前为止似乎还可以吗？

我遇到的真正问题是:我该怎样/应该如何处理这个模型中"外来"属性所增加的复杂性？我应该留下外国,即受益人的旗帜属性吗？如果是这样,我如何处理对于概念上类似的信息(即邮政编码,税号)以及重复属性(zipcode_foreign,zipcode,taxid_foreign,taxid等)的不同属性的需求？我是否真的应该努力将不同的域值容纳到一个字段中？

任何建议都会受到欢迎......