可扩展资产数据库模式

Question

背景

我在硬件行业为一家规模可观的公司工作。目前，我们有许多不同的资产需要跟踪。直到最近，这都是手工完成的，这是一种(显然)容易出错的做法。我们现在(最后)将其放入适当的RDBMS中，尽管还没有选择确切的DBMS。

幸运的是，每个资产已经被一个唯一的资产标记/编号所跟踪。

问题

我正在努力找出哪一种方式是最好的方式跟踪登记和入住。我在这件事上做了一些谷歌搜索，但我似乎找不到我要找的东西。我只需要跟踪给定的资产何时签出并随后签入。目前，我正在考虑三个主要方案：

1. 为入住和退房各提供一张桌子。这样做的好处是清晰地分离了两个概念，避免了任何空值。然而，它确实使对此类信息的查询更加复杂。
2. 一个用于签入和签出的表；不同行的签入和签出。这允许我重用相同的表，但是它需要大量的自连接才能得到任何东西。我也不喜欢依赖某种常量来区分“out”和“in”记录。
3. 一个用于签入和签出的表；同一行的签入和签出。这是我目前最喜欢的，因为它使得查询变得琐碎，并以非常容易理解的方式将这两个概念('out‘和随后的返回)结合在一起。我对此唯一的犹豫是，它依赖于NULL来确定一个资产是否仍然被签出。我的经验是，NULL可能是一个苛刻的情妇，特别是当设计是DBMS独立的时候。

我知道很多事情可能取决于我的特定需求；然而，这个问题似乎很普遍，我希望得到某种级别的预期最佳实践，以及为什么选择这种实践。

太久了；没有读

哪种与RDBMS无关的设计技术最适合跟踪资产的签出和签入，以及原因：

• 两张桌子，一张用于退房和一张入住。
• 两个表中的一个；“out”和“in”的不同行
• 两个表中的一个表；“out”和“in”在同一个记录中

提前感谢您的帮助。

Answer 1

选项#3

诺尔斯是你的朋友。选择平台后，研究NULLs如何为平台工作并拥抱它们。在这种情况下，它们准确地反映了没有签入。在Oracle中，没有索引，所以您可以创建一个基于函数的索引，用于交换空状态，为您提供一个非常小的索引，该索引只包含未签入的条目。

选项1将需要一个连接，随时您需要签入日期或状态。联接也是您的朋友，但在这种情况下，除非有一次单个签出可以产生多个签入，否则分离这些数据没有好处。选项2需要重复数据，甚至需要比选项3更多的NULLS。下面是三个充实到表、列和数据的概念。

#1
CheckOut
   Asset CheckInOut User DateTime
   1     1          1    3/10/2013
   2     2          1    3/10/2013
   3     3          2    3/11/2013

CheckIn
   CheckInOut DateTime   
   1            3/11/2013

#2
CheckInOut
   Asset CheckInOut User DateTime   InOrOut
   1     1          1    3/10/2013  O
   2     2          1    3/10/2013  O
   1     1          1    3/11/2013  I   
   3     3          2    3/11/2013  O

#3
CheckOut
   Asset CheckInOut User OutDateTime InDateTime
   1     1          1    3/10/2013   3/11/2013
   2     2          1    3/10/2013
   3     3          2    3/11/2013

SQL显示了选项2和选项3，并附加了额外的要求，Joel补充说，以及如何在SQL中回答各种问题。

#2 - http://www.sqlfiddle.com/#!4/55e72/25

#3 - http://www.sqlfiddle.com/#!4/e2f27/6

Answer 2

你必须决定你想让你的世界对程序员来说是简单的，还是对用户有用。

最有用的场景是最直接地处理现实世界中发生的事情的情景。在您的情况下，这是您的第二种场景:一个用于签入的表，以及每个不同行的签出。

这个场景之所以最像现实世界，是因为它正在对库存事件进行建模。

表中的每一行记录某人对一件设备的物理处理。你要么把它拿出来，要么把它放回去。不需要使用空列。这种方法存在的问题是，外出和输入不一定是很好、整洁的一对。但是，这很可能是您实际操作中的一个事实。在现实世界中，文书工作有时会丢失，或者人们在程序上过于草率。如果您按照选项3的方式构建您的系统，那么在某个时候，会有人要求制定一条业务规则，上面写着“不要签出未签入的东西”。虽然这在教科书样例问题中很有意义，但在现实世界的应用程序中，这将是一个麻烦。

当需要扩展系统的需求时，这种方法也是最有用的。例如，假设您的系统的第二阶段是实现物理库存过程。在选项1中，您需要一个全新的表。在选项3中，您需要另一个表或一个新列。在选项2中，您只需要为“库存移动类型”列提供一个新的值。接近现实世界的建模通常会使您的数据库模式成为未来的证明。

作为单个记录跟踪所有事件，然后构建应用程序逻辑来解释事件流。