可能的重复:
世界上所有地址都有共同的街道地址数据库设计吗？
在数据库中存储国际地址的"最佳"方式是什么？
在数据库中实现一致且全面的地址存储的最佳实践

我目前有四个表,客户,联系人,设施和客户.

每个表都有以下字段:AddressLine1,AddressLine2,City,StateOrProvince,PostalCode.

我想将地址移到一个单独的表中,并且还能够指定地址类型(计费,运输,主要等).

我的解决方案如下:

1. 从客户,联系人,设施和客户中删除AddressLine1,AddressLine2,City,StateOrProvince,PostalCode.
2. 创建地址表,其中包含AddressID(PK),AddressLine1,AddressLine2,City,StateOrProvince,PostalCode,LastUpdateUser,LastUpdateTime字段.
3. 使用字段AddressTypeID,AddressTypeName,AddressTypeDescription,AddressTypeActive,LastUpdateUser,LastUpdateTime创建AddressTypes表
4. 使用字段CustomerID,AddressID,AddressTypeID,CustomerAddressActive,LastUpdateUser,LastUpdateTime创建CustomerAddresses表
5. 使用ClientID,AddressID,AddressTypeID,ClientAddressActive,LastUpdateUser,LastUpdateTime字段创建ClientAddresses表
6. 使用字段ContactID,AddressID,AddressTypeID,ContactAddressActive,LastUpdateUser,LastUpdateTime创建ContactAddresses表
7. 创建FacilityAddresses表,其中包含FacilityID,AddressID,AddressTypeID,FacilityAddressActive,LastUpdateUser,LastUpdateTime字段

我正在寻找指导,以确定是否有比我设计的解决方案更好的解决方案.大家为什么这么想？

编辑:此时我并不关心美国以外的任何事情,也不关心如何存储街道地址,即街道号码与整个街道地址.我担心数据库设计和表结构的立场.

我们为客户提供的许多LOB应用程序具有营销/促销性质(抽奖活动,活动注册等).大多数应用程序虽然非常简单,但对数据库要求很高.想象一下,"注册"型网站作为在超级碗期间播出的商业广告的支持,例如(是的,我们有几个).

虽然我们已经非常善于优化我们的Web应用程序代码,但数据库始终是一个问题,尽管应用程序相对简单.流程通常类似于:

1. 从数据库读取以检测现有记录
2. 如果记录是新的,写入数据库

在许多情况下,这是我们的应用程序需要执行的所有数据访问.但是,鉴于它是应用程序的唯一目的,因此对这个简单的过程进行大大优化非常重要.

出于这个问题的目的,我们有一台服务器为数据文件运行raid 5磁盘阵列,为日志运行另一个raid 5阵列.此时,操作系统是Windows 2003标准32位,服务器有4 GB内存.一些应用使用SQL 2005标准,而其他应用使用MySQL 5.1.我非常清楚这里可以进行某些操作系统和硬件优化,但我希望首先从软件方面解决我的需求.广泛的分析告诉我们,磁盘IO通常是主要的瓶颈.

说了这么多,并且知道缓存不会有多大帮助,因为大多数读取都是唯一的并返回非常少的数据(通常只是指示记录是否存在),我正在考虑进入一个领域. -memory数据库作为真实数据库的写缓存层.这似乎是一个很好的选择,因为我们的大部分高流量流量本质上是零星的,并且不会持续数小时.此外,在大多数情况下,由于服务器崩溃可能会丢失几分钟的数据.

在最简单的形式中,我会修改一个典型的注册应用程序来执行以下操作:

1. 查询磁盘DB和内存DB以查找现有记录
2. 如果不是,则将数据写入内存DB并返回
3. 定期将内存DB刷新到磁盘DB

我的问题是:这个中间内存数据库有哪些选择？我已经尝试了内存中的哈希表,数据表等,但我正在寻找其他选项,甚至是针对完全不同的方法的建议.

面向文档的数据库(特别是RavenDB)真的很吸引我,而且我想和他们玩一下.然而,作为一个非常习惯于关系映射的人,我试图想到如何在文档数据库中正确建模数据.

假设我的C#应用​​程序中有以下实体的CRM(省略了不需要的属性):

public class Company
{
    public int Id { get; set; }
    public IList<Contact> Contacts { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Contact
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Task
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public Contact Contact { get; set; }
} …

有一段时间我一直在努力解决如何最好地处理SQL中的层次结构.由于邻接列表的限制和MPTT /嵌套集的复杂性而感到沮丧,我开始考虑简单地存储密钥路径,作为一个简单的node_key/node_key/...字符串.我决定编译这三种技术的优点和缺点:

创建/删除/移动节点所需的呼叫数:

• 邻接= 1
• MPTT = 3
• Path = 1(用包含该路径的所有节点上的新节点路径替换旧节点路径)

获取树所需的调用次数:

• 邻接= [子级数]
• MPTT = 1
• 路径= 1

获取节点/祖先路径所需的调用次数:

• 邻接= [超级数]
• MPTT = 1
• 路径= 0

获取子节点数所需的调用次数:

• 邻接= [子级数]
• MPTT = 0(可以从右/左值计算)
• 路径= 1

获取节点深度所需的调用次数:

• 邻接= [超级数]
• MPTT = 1
• 路径= 0

需要DB字段:

• 邻接= 1(父)
• MPTT = 3(父,右,左)
• 路径= 1(路径)

结论

除了一个用例之外,存储的路径技术使用与每个用例中的其他技术相同或更少的调用.通过这种分析,存储路径是明显的赢家.更不用说,它实现起来要简单得多,人类可读等等.

所以问题是,不应该将存储路径视为比MPTT更强大的技术吗？为什么存储路径不是更常用的技术,为什么不在给定实例中使用它们而不是MPTT？

另外,如果您认为此分析不完整,请告诉我们.

更新:

这里至少有两件事MPTT可以开箱即用,存储的路径解决方案不会:

1. 允许计算每个节点的子节点数,而无需任何其他查询(如上所述).
2. 在给定级别的节点上强加订单.其他解决方案是无序的.

目前我正在开发一款移动应用.基本上人们可以发布他们的照片,而粉丝可以喜欢像Instagram这样的照片.我使用mongodb作为数据库.像Instagram一样,单张照片可能会有很多喜欢.因此,使用带有索引的单个"喜欢"的文档似乎不合理,因为它会浪费大量内存.但是,我希望用户快速添加.所以我的问题是如何建模"喜欢"？基本上,数据模型与instagram非常相似,但使用的是Mongodb.

给出以下星型模式表.

• 事实上,两个维度,两个措施.

#   geog_abb  time_date amount     value
#1:       AL 2013-03-26  55.57 9113.3898
#2:       CO 2011-06-28  19.25 9846.6468
#3:       MI 2012-05-15  94.87 4762.5398
#4:       SC 2013-01-22  29.84  649.7681
#5:       ND 2014-12-03  37.05 6419.0224

• 地理维度,单层次结构,层次结构中的3个级别.

#   geog_abb  geog_name geog_division_name geog_region_name
#1:       AK     Alaska            Pacific             West
#2:       AL    Alabama East South Central            South
#3:       AR   Arkansas West South Central            South
#4:       AZ    Arizona           Mountain             West
#5:       CA California            Pacific             West

• 时间维度,两个层次结构,每个层次结构4个级别.

#    time_date time_weekday time_week time_month time_month_name time_quarter time_quarter_name time_year
#1: 2010-01-01       Friday …

在你向我展示重复之前,请注意我在网站上搜索了一些已找到的例子,但对我的问题并不十分具体:)

在SQL中创建友谊表的最佳方法是什么,但确保每一行都是唯一的,即不管属于哪个列,相同的UserID和FriendID永远不会被赋予？

我有这个粗略的例子

CREATE TABLE [dbo].[Friendship](
    [UserID] [uniqueidentifier] NOT NULL,
    [FriendID] [uniqueidentifier] NOT NULL,
    [FriendshipStatus] [int] NOT NULL
)

User表和FriendID共有2个Users表的外键.

目前,我可以在用户之间插入友谊两次,从而创建一个副本.例

UserID    FriendID    FriendshipStatus
Guid 123   Guid 789    1
Guid 789   Guid 123    1

我如何确保强制执行这种完整性,可能是2个PK？某种独特的指数？或者你会建议一起更好的桌子设计吗？另外,你会自动增量FriendshipID吗？如果是这样,你能解释一下原因吗？

考虑以下:

我有两个表(Customers和Cases)定义如下:

**Customers**
CustomerId (PK)
CustomerName
CustomerPhone

**Cases**
CaseId (PK)
CaseManager
CaseNotes

每个客户可以拥有无​​限量的案例,但每个案例只能属于一个客户.因此,为了将表相互关联,我将使用一个交集表(CustomerCases),它分别由每个表中的外键组成.

但是,我不能只将Customers表中的CustomerID作为Cases表的外键添加吗？我觉得我错过了什么.如果我选择不使用交叉表,是否有任何陷阱我应该注意？

信息模型和本体论有什么区别？

他们看起来和我一样.

谢谢!

处理删除或启用/删除行及其引用表的最佳实践是什么？

例如,假设我有一个非常简单的'论坛'应用程序.

我有一个users包含我的webapp帐户的表,其中threads包含用户创建的线程,以及一个comments包含用户对线程评论的注释的表.

现在,假设在注册时我想在激活其帐户之前验证用户的电子邮件.这是最好的方法吗？什么是最佳做法？也许通过一个只返回带字段的行的视图is_active=true？使用2个分离的表pre_users(包含仍需要验证的用户)和users(经过验证的表)？

同样,您将如何处理想要暂停其帐户的用户？它的主题和评论？您是否会添加另一个标志is_suspended,并更新视图以考虑该标志？如果它不是一个视图,而是两个单独的表,我怎么能处理引用呢？

另外,删除一个帖子.假设在线程删除时我不希望实际删除该线程,因为我不希望发布注释的用户突然看不到他们的注释.怎么处理这个？

这类问题的最佳做法是什么？