首页 > 解决方案 > 制作可以与层次结构中的任何对象关联的记录的聪明方法是什么?

问题描述

我正在向我的程序添加消息/电子邮件功能。在大多数情况下,它的功能与一个非常基本的电子邮件应用程序相同,它需要一个SENDER, RECEIVER, MESSAGE. 现在是诀窍,我还需要能够将其与特定客户、位置、区域、资产或项目相关联。

在我的程序中,我有这个层次结构,其中每个项目必须与资产相关联,每个资产必须与区域相关联,每个区域必须与位置相关联并且每个位置必须有一个客户,但是链可以结束于例如,任何一点我都可以有一个带有位置的客户,仅此而已。

供参考 - Customer->Location->Area->Asset->Project

每条消息必须至少与一个客户相关联,但它可以更具体。

这是我的问题 - 我将如何将其存储在数据库中?
我有两个想法 - 一个是为每个级别的关联创建一个列,并在适用和NULL不适用时存储 ID。

所以桌子看起来像

CREATE TABLE messages 
(
    fromUserId int,
    toUserId int,
    message varchar(100),
    customerId int NOT NULL,
    locationId int,
    areaId int,
    assetId int,
    projectId int
)

因此,与区域级别相关联的消息将具有类似

customerId     locationId    areaId    assetId    projectId
=============================================================
1235           4321          5938      NULL       NULL

我的第二个想法是记录最具体的 ID 以及它到底是什么,比如

CREATE TABLE messages 
(
    fromUserId int,
    toUserId int,
    message varchar(100),
    parentId int NOT NULL,
    parentObject Varchar
)

同样的先前消息会像这样

parentObject      parentId
===============================
"areaId"          5938

现在,我倾向于第一种方式,因为这些消息也将采用表格格式,并且过滤客户、位置、区域、资产或项目是我必须实现的功能。第一种方法很容易,但我觉得如果这是一个大型应用程序,列占用的额外空间会占用额外空间。幸运的是,鉴于有多少人使用此应用程序(这是内部使用的小型内部事物),我真的不必担心这一点,但在不同的情况下,这似乎不太理想。

第二种方法似乎节省了空间,但它也会使过滤查询更加复杂。如果我想按客户过滤,现在我必须先获取与该客户相关的每个位置、区域、资产和项目,才能正确过滤。

对于如何处理这种情况是否有一些共识?还有第三个最好的方法吗?

我主要是问,因为我已经看到其他开发人员在我的应用程序的其他地方使用了这两种方法。想知道你的想法是什么

标签: sql

解决方案


是的 - 实际上有一个非常漂亮的解决方案(假设我没有读错问题) - XML。

当您的 SQL 表列将包含结构松散或完全非结构化的数据时,建议使用 XML。真正好的是,如果你让你的类可序列化,你就可以得到类的序列化并将其放入现场;稍后,您可以毫不费力地将 XML 重新转换为 .NET 对象。你甚至可以做一些很酷的事情,比如在 SQL 端使用节点索引来搜索 XML 中的元素(如果你愿意的话。)


推荐阅读