表设计-用户管理

Question

我为一个简单的用户管理系统设计了一个数据库，这个系统包括以下内容，

1. 用户-用户可以是卖方/雇员/买方。
2. 用户-用户可能有多个地址-/传递/计费/配置文件/公司地址。
3. 用户-一个用户可以有一个以上的角色-销售经理/经理/首席执行官。
4. 用户-用户可以使用单个登录凭据(用户名/电子邮件地址)访问他的所有角色/需要。

在这方面，我设计了这个系统。这是我的第一个应用程序，我需要知道设计的应用程序是否满足所有的要求，这在这个设计中有用吗？

与此相关的任何建议和想法，以及一些最佳实践的建议。提前谢谢。

Answer 1

“数据模型资源手册”第1卷为所有这些提供了完整和有效的结构。我建议你喝杯咖啡--它也会详细讨论这些细节。

您有一个问题--用户和UserRole --一个用户可能处于多个角色中，角色应该是有时间限制的，这样他们就可以随着时间的推移而改变，而不会使您的审计跟踪无效。如果供应商变成了买家，你会怎么做？您陷入了假设用户(实体/表)包含角色的典型陷阱--它不应该。用户是ID --就像你的护照不包含你的工作一样。

角色附加到user (UserRole)表，但用户不包含角色。

AddressType也是如此--如果我想使用相同的地址来开发票和发货怎么办？类型应该添加标记。或者在角色中有指向特定地址的指针(ShippingAddressId等)。

您编写的地址非常详细-这是很好的，但也完全不好，如果你遇到的地址是不标准的。拥有邮政编码、城市、国家这样的字段是很有意义的--但即使是国家也是不相关的(永远不要在地址上给出)，但更糟糕的是所有的地址字段。街道?那些不使用这个的国家呢？没有合适的房号？你们的运输地址有15条线长吗？这些确实存在。阅读http://online.wsj.com/news/articles/SB10001424052702304870304577489094121477570以获得参考。有一个很好的点，有一个免费的文本字段，为类似的东西-以及额外的路由细节，你现在还不知道。

电话号码-一样的。请。ContactItem是一张很好的桌子--可以是电子邮件，电话等等--允许人们拥有多个电话号码。

PinCode？你想在里面存储一个可读的密码吗？初学者编程:永远不要在数据库中存储密码或密码。用标准的安全方法存储经过盐渍的哈希。黑客不能轻易用来伪装成用户的东西。20年前，存储密码在法律上是严重的疏忽。今天仍然是。

因此，看起来像一个非企业的模型，由一个人现在意识到现实世界的复杂性。我只能推荐一份“数据模型资源手册”的副本来很好地描述所有这些情况。