批判我的数据库设计

时间:2009-04-11 10:34:18

标签: database-design

我没有太多设计DB的经验。虽然我有一些粗略的理论知识。

所以,关于我的问题。我们有一堆excel文件的数据(是的,惊喜!),我们希望将它们移动到数据库。

为简化起见,假设系统是集中报警系统。数据从远程位置收集并显示在集中监控室中。 每个位置都有一个唯一的名称和多个设备。在某个位置,设备名称是唯一的,并且设备具有多个警报。在设备中,警报名称是唯一的。

在每个位置,我们都有一个或多个终端单元(TU),用于聚合该位置的警报并发送它。每个TU都有一堆卡片,每个卡片每个TU都有唯一的ID。每张卡都有一个每个警报的接线终端触点,每张卡都有一个唯一的地址。

任何这些实体都可以重命名/重新读取。

如您所见,数据是高度分层的。而且我需要存储每个布线接触报警分配(关系)的历史记录。警报可以将其从一个联系人的分配更改为另一个联系人。

Location             TU
|                    |
+- Device            +- Card 
    |                    |
    +-- Alarm            +--Contact 
        |                     |
        +----Alarm-Contact----+

我的设计: 我为上面显示的每个实体创建了一个表。我使用人工主键作为自动增量整数。层次结构中的表格(Tn)将对合成具有唯一性约束(Tn.name,Tn-1.pk,Tn-2.pk,...),其中Tn是表格(n)深度层次结构和(pk)是表的主键。

我将使用SQL Server,我对自动增量整数PK有疑问。假设我有10条记录,除了最后一条(第10条)我删除了所有记录。下一个添加的记录是否会编号为11,或者DBMS会将它们重新编号为10-> 1和new - > 2.如果前者是正确的,如何解决PK溢出的问题。

另一个问题是我应该如何为此建模历史数据。我想我应该创建一个与Alarm-Contact表有n-1关系的Alarm-Contact-History表。

由于

2 个答案:

答案 0 :(得分:2)

如果您只是创建一个Alarm-Contact-History表,那么您将无法创建准确的历史记录。假设每张卡都可能被移动到另一个TU,那么您所描述的历史记录在报警使用卡的联系人时不会知道卡的安装位置。

可能包含卡ID,TU ID,位置ID和设备ID的增强型警报联系历史记录会更好。这样,您就可以了解生成历史记录时的确切配置。如果在介入的时间范围内出现问题,你就不会介意,因为你知道那时的情况。

SQL Server将继续增加分配给标识符的值。你预计有多少条记录?如果它是一个大量(~214亿)我建议使用bigint作为标识符。

答案 1 :(得分:-2)

我建议采用不同的计划。

热身将数据从Excel转换为MS Access。转换非常简单,因为Excel和Access可以互操作。

请勿使用自动增量编号。相反,安排您在VBA中编写的函数或任何要在插入新数字时运行的函数。创建自己的算法来控制新数字的分配,而不是受DBMS的支配。

在MS Access中使用交互式查询构建器等可帮助您练习或节省您的工作量。但是使用SQL视图来确定所有查询的工​​作方式,即使您没有构建它们。

然后构建一个SQL Server版本。摘要了SQL语言特有的MS Access特性,但是使用了大部分构建原型的知识。您的自动增量代码将处于触发器中。

哦,顺便说一句,不要忘记你学到的理论。它可能会派上用场。