【问题标题】:storing an account number with or without dashes存储带有或不带有破折号的帐号
【发布时间】:2018-08-01 04:52:46
【问题描述】:

我确定有人问过这个问题,但我一直只找到有关电话号码的讨论。

我正在为一个控制多个在线商店的供应商组设计一个系统。有 5 种不同类型/级别的商店(基于他们的购买群体,等等)。 这些帐户可以从我们的仓库订购产品,也有自己的客户集合,可以从他们那里订购产品。

由于商店帐户及其客户帐户都将存储在我们的系统中并由我们的系统访问,但商店将独立访问他们的客户帐户,我想为帐号设置一个“有组织”的结构,该结构适用于双方系统。

我计划使用 10 位数字的帐号,前 5 位数字标识商店(第一个数字将标识商店类型/级别),最后 5 位数字标识客户。

例如,

First LEVEL1 store account : 10001-00000
Their customer accounts : 10001-00001, 10001-00002, etc.

Third LEVEL2 store account : 20003-00000
Their customer accounts : 20003-00001, 20003-00002, etc.

这应该有足够的增长来支持我们潜在的商店数量及其客户数量。

我的问题是,我应该用破折号分隔数字吗?

这当然让人类更清楚,但感觉在数据库中存储为真正的 int 会更好,虽然我不知道我会多久比较一次,等等。

我是否应该将其存储为不带破折号的 INT,并在向用户显示时对其进行格式化? (那么显然一定要接受带或不带破折号的帐号输入)

【问题讨论】:

  • 这个问题的答案完全是主观的。为什么叫 Blend-O-Tron 9000B 而不是 Blend-O-Tron 9000/B 或 9000-B 或 9000+B?您可以使用任何您想要的分隔符,但请考虑您拥有的用户类型,以及是否会输入这些,在发票上看到它们等。有时越短越好,在这种情况下,AFX00001 可能比 20003-00001 更好.字母可以用更少的字符处理更多的可能性。
  • 正确设计您的表格。这种结构只会在以后给您带来问题。阅读一些介绍性的数据库设计书籍。
  • 感谢您的反馈!是的,这是非常主观的。从系统的角度来看,我更好奇破折号的一些缺点是什么。就我们的用户而言,在总部,我们只会与我们的经销商沟通(因此我们可能会要求提供前 5 位数字部分,然后我们将审查他们商店下的帐户),而我们的经销商只会与他们的客户打交道,因此他们永远不需要使用具有不同起始部分的帐号。我认为破折号可以帮助用户了解商店编号的结束位置和用户编号的开始位置。

标签: mysql sql


【解决方案1】:

1NF 表示每个属性中的值必须是原子的。通过添加破折号并将两个属性存储为一个,您违反了 1NF。


您(理想情况下)必须做什么?

每个商店都有一个 ID,所以商店的表应该有一个包含它的 ID 列。

接下来,客户的表中也应该有自己的 ID。

最后,商店和客户之间的关系(或联结)表应包含商店 ID 和客户 ID 作为每一行。

或者,客户可以有一个外键,它告诉客户应该从哪家商店购物,假设客户只绑定到一家商店。

【讨论】:

  • 非常感谢您的建议!我一直在可视化用户表都错了!我不知道为什么我使用关系表来关联我的产品和类别表,然后是用户和商店的外键。我为产品这样做的所有原因都同样适用于用户。
  • (顺便说一句,我喜欢你的名字)我确实对这个实现有疑问。如果我在 stores 表中有 2 个具有唯一 storeIDs 的商店,并且它们每个都有 2 个客户存在于客户表中。所有客户真的需要唯一的客户编号吗?我从客户表的角度了解他们为什么这样做(显然他们需要一个唯一的主键),但从经销商的角度来看,他们的两个客户都可以(并且可能应该)是 00001 和 00002,但属于不同的商店。我想我们的一些经销商会质疑为什么他们的第 10 个客户是 00204。
  • @Aaron:如果您将客户的 ID 暴露给经销商,他们会询问他们。客户 ID 是您添加的详细信息(用于唯一标识每个客户)。因此,不应让经销商了解这些知识。在幕后,您的代码可以毫无问题地使用 ID。只是不要把它一直带到处理他/她商店的人面前。 (1/2)
  • 如果您希望每个商店的客户连续编号,那么您应该将商店的 ID 作为外键添加到客户表中,并将 {StoreID, CustomerID} 的组合作为您的键客户表。 (2/2)
  • 有很多像我这样的手柄。周围有一个'usr','HaveNoDisplayName'等。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-03-11
  • 1970-01-01
  • 2018-07-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多