可扩展性的最佳数据库设计

时间:2013-07-22 17:23:45

标签: php database yii database-relations

我正在使用Yii框架为我的实习设计数据库和匹配网站,主要使用PHP。我们的目标是允许管理用户完全灵活地显示他们想要显示的信息,因此我们试图保持应用程序的动态。因此,我们的想法是数据库中的选项/数据,而不是代码内部。我目前有一个工作设置,但我不确定这是否是正确的方法。很棒的帖子,对不起。目前我们有:

关系
+用户HAS MANY user_phone
+ user_phone HAS MANY用户
+ user_phone HAS user_phone_type


用户< - user_phone_assignment - > user_phone - > user_phone_type

user_phone_type
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
limit INT NOT NULL

基本用户配置文件信息存储在用户中,为了减少家庭和兄弟姐妹实例中的重复数据,user_phone有一个潜在的多对多的分配表。 user_phone_type的想法是我们存储一个名称,如“Home”,“Work”,“Fax”,“Other”等。

user_phone_type.limit < 0
 +字段已禁用,未显示for actionCreatePhone
user_phone_type.limit = 0
 +字段已启用,允许无限制条目,始终显示
user_phone_type.limit > 0
 +字段启用,显示计数(user_phone)&lt; user_phone_type.limit

我觉得这个系统可行,但我不确定这是否是最好的方法。有没有人有任何其他选择来保持应用程序灵活和面向数据库,同时保持更容易的关系?也许是某种配置表设置,我们可以将配置值存储在模型或控制器中的局部变量中。

1 个答案:

答案 0 :(得分:1)

小心你的标准化。一些看似潜在的多对多关系的东西实际上只是属性。电话号码和地址,虽然您可以将它们建模为多个,但在这种情况下可能难以管理,因为您必须处理更改的电话号码和地址。在一对多模型中,当地址或电话号码发生变化时,用户会有多个地址或电话号码,您只需在表格中更新即可。在地址或电话号码发生变化的多对多模型中,您必须确定是正在更改的地址还是用户对正在更改的特定地址的分配。我见过人们试图实现这一点,并且它总是最终出错,因为你通常会指定一个邮寄地址和一个客户地址,或一个家庭电话和一部手机,或一个传真号码,而UI通常不是您可以从地址列表或电话号码中选择多对多的用户界面。

让我们尝试使用电话号码的简单方案:

说用户#1工作电话号码是513-555-1234,他的手机号码是513-555-4321。假设用户#2具有相同的工作电话号码513-555-1234和手机号码513-555-4322。

现在说用户#1会丢弃他们的工作电话号码,或者将其更改为其他内容。在丢弃号码的情况下我们想要做的是删除用户和电话号码之间的链接,因为如果我们只删除电话号码字段,用户#2也会丢失他们的工作电话。现在,如果我们刚刚取消链接的用户是指向电话号码的最后一个用户,我们必须决定该怎么办。我们是否删除了电话号码或保留以防其他人接听电话号码?更改电话号码更加复杂。由于无法知道更改是否是对无效电话号码的更正,并且对于与之相关的每个人都应该更改,我们必须决定是否更改电话号码会改变每个人(最终是一个坏主意)因为如果用户更改了作业并且他们的工作号码发生了变化,那么来自用户原始工作场所的其他人也会发生变化,这显然是错误的),或者如果对电话号码的更改仅影响分配给它的单个用户。可能是基于标准用户维护UI的最佳选择,因为它模仿了一对多方法的行为。但是,您不仅要更改电话号码,还必须删除电话号码的链接,然后创建新的电话号码记录,然后将客户链接到该电话号码。在这两种情况下,您还必须检查以确保新电话号码不存在,而不是仅插入新记录。如果它确实存在,那么您只需将用户链接到新号码,而不是创建新号码并链接到该号码。真的,所有这些复杂性能为您节省多少?不多。如果你做这样的事情,也许有点时间验证地址。也许是一个小空间,其中1%的电话号码与工作电话号码重叠,但是现在大部分工作电话都是直接拨号,所以这甚至可能不是真正的节省。我甚至看到地址被分成不同的文件而根本没有管理,只是添加了一个新的地址,无论是否重复,只是将地址放在父表中没有节省。

所以我认为,这就是所有这个问题都会产生的,是你不应该担心将电话号码或地址放在他们自己的单独表格中,除非很有可能许多可能的地址或电话号码将丢失,并且在这些情况下您不会写入空白地址记录。即使您将它们保存在单独的表中,也不要担心删除重复项(通过使用多对多关系),因为这会给应用程序增加不必要的复杂性。

相关问题