sql - 对于这个特定的数据库设计问题，您会使用哪种方法？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




只是寻找对以下两种情况的意见。

我们有一个表，用于存储我们的出站短信。每次我们的一项服务发送溢价消息时，它都会将它们存储在此表中……迄今为止，所有需要存储的重要信息都采用相同的格式。

SMSMessages
----------------------
ID              int PK NOT NULL Identity
Mobile          nvarchar(50) -- the number we're sending to
NetworkID       int FK -> Table containing networks (voda, o2, etc...)
ShortcodeID     int FK -> Table containing our outbound shortcodes
DateSent        DateTime

现在其中一个网络已经实现了一个全新的 API，我们需要与它集成，这需要更多参数。这些附加参数中的 1 个是“命令”。根据我们发送的命令，我们需要发送 4 到 8 个附加参数。为简单起见，我们会说只有两个命令......“InitialSend”和“AnniversarySend”

显然，仅仅添加 将是非常糟糕的数据库设计。全部 这些额外的列到我们现有表的末尾所以......我们认为我们有两个选择。

选项1。

创建许多新表，特定于每个命令，链接回
原表。

SMSMessages_CommandTypes --Contains "InitialSend" & "AnniversarySend" + other commands
--------------------------
CommandTypeID   int PK
Command     nvarchar(50)


SMSMessages_OddBallNetwork
--------------------------
ID              int PK, FK --> SMSMessages.ID
CommandTypeID   int FK ---> SMSMessages_CommandTypes


SMSMessages_OddBallNetwork_InitialSend
--------------------------------------
ID              int PK, FK --> SMSMessages.ID
Param1          nvarchar(50)
Param6          nvarchar(50)
Param9          nvarchar(50)
Param14          nvarchar(50)

SMSMessages_OddBallNetwork_AnniversarySend
--------------------------------------
ID              int PK, FK --> SMSMessages.ID
Param1          nvarchar(50)
Param2          nvarchar(50)
Param7          nvarchar(50)
Param9          nvarchar(50)
Param12          nvarchar(50)

//There are 4 other Command Types as well so 4 More Tables...

根据我们的 DBA 的说法，这个专业人士都是纯粹主义者。每个可能的组合都被严格定义。关系很清楚，它是表现最好的。

从我的 POV 来看，缺点是开发时间、接触点数量、具有不同命令类型的消息的复杂检索规则/程序，以及缺乏可重用性......此移动网络或其他网络上的新命令引入这种方法需要数据库关卡设计和实现……不仅仅是代码层面。

选项 2。

此选项是尝试设计一个具有更少、更多可重用结构的动态实现。

SMSMessages_AdditionalParameterTypes
------------------------------------
ParamterTypeID  int PK NOT NULL Identity
ParamterType    nvarchar(50)

/*
This table will contain all known parameters for any messages
CommandName
Param1
Param2
etc..
*/

SMSMessages_AdditionalParameters
--------------------------------
ID              int PK NOT NULL Identity
MessageID       int FK --> SMS Messages
ParamTypeID     int FK --> SMSMessages_AdditionalParameterTypes
Value           nvarchar(255)

所以这个有利有弊。

缺点:
您不太清楚哪些参数与哪些消息相关联
还有一个小的性能问题... 电话 每条消息插入，而不仅仅是 2

优点:
对抗(imho)开发要容易得多。您只需为给定的 messageID 获取参数名称 -> 值的列表

它的可重用性也更高……如果奇怪的网络添加了新命令、命令上的新参数，或者即使另一个网络出现并实现了类似的“我想要更多信息”API，我们不需要任何结构更改在我们的系统上。

所以...你会怎么做？

Answer 1

为什么
为什么需要存储这些信息？有报道吗？搜索？用于摘要和分类分析？实时？频繁地？
少做
如果此数据仅用于日志记录，请将其粘贴在文本或 xml 字段中并忘记它。 YAGNI(你不需要它)似乎很可能......
严重地
在不知道这些数据用于什么的情况下，没有人可以回答这个问题，包括你。
是的，完全规范化的逻辑数据库结构很棒并且提供了清晰性等。但是它有用吗？
并非所有数据都是黄金；有些只是 CYA