灵活的目录管理系统......我有什么遗漏吗？

Question

我正在为我父亲的公司创建一个目录管理系统。我在过去几年中设计和推出的当前版本既好又高效，但它有其局限性，如果他想将属性添加到项目类型，那么我必须将其添加到数据库中和代码并重新启动系统。

现在，对于下一个主要版本，我正在尝试修改它，以便他可以自己定义所有列 - 所以我有一个 ItemType 表，他在其中命名项目类型；一个 ItemTypeProperty 表，以便他可以定义所有列及其数据类型，一个 Item 表，其中存储所有项目及其 ItemType 的 ID，以及一个 ItemPropertyValue 表，它使用 ItemID、ItemTypePropertyID 并存储值。目的是使他能够说他想要一个类型的列，这样，如果有两个 ItemType 称为 Range 和 Collection，他可以说他希望 Collection 是 Range 的一个属性。

这里有没有人曾经面临过这种系统的创建，如果是这样，在我走得更远之前，我有什么主要的遗漏或者我可能想要考虑的任何事情吗？我的意思是像我以后可能遇到的某种问题，我现在可以通过做某事来避免？或者是否有任何技术可以提供很多帮助？我曾尝试过 Linq，但当时很难根据自己的需要对其进行自定义。我目前正在使用带有 Sql Server 2008 的 VB.Net 2.0（服务器设置的限制；不受我控制）。我创建了自己的系统，该系统源自 MVC 类型的架构。

提前致谢。

问候，

理查德

编辑：

我的新数据库结构是：

表格：ItemType

• 身份证
• 姓名

表格：ItemTypeProperty

• 身份证
• ItemTypeID
• 姓名
• 说明
• 数据类型

表格：项目

• 身份证
• ItemTypeID

表格：ItemPropertyValues

• 身份证
• 物品ID
• ItemTypePropertyID
• 价值

Answer 1

这里的主要架构驱动因素是什么？可维护性有多重要？您如何将它们与性能等运行时需求进行比较？

这听起来可能有点陈词滥调，但清楚地了解什么是重要的，什么不是，这将有助于您做出正确的决定。

我之所以这么说是因为用户可以定义“通常”在应用程序中设置得更严格的系统隐含地更复杂，因此使用起来更具挑战性。基本上这是一种权衡：一些任务会变得更容易，而另一些则更难。

另一方面，找到这样的系统并不少见 - 因此，如果您之前没有做过，您肯定会发现这是一次值得体验的体验。我要说的是，如果当前的设计“有效”，那么只有在有充分理由的情况下才应该更改它。

具体说明：

• 正确使用数据模型很重要。在你走得太远之前，请确保你理解5th Normal Form：基本上你会（可能）遇到两个在现实世界中无法链接的概念可能会出现在你的系统中的问题——因为它们都是值（ ItemTypes) 在同一个表中（this link 可能更好）。
• 报告会更难 - 因为你没有一个很好的平面表结构来处理，所以你也可能得到更少的工具支持（只是一种预感 - 完全不受支持的意见）。
• 您可能会发现自己在系统中添加了“更多”常量 - 如果您确实提前将它们映射得相对较好（这与正确使用数据模型有关）。

更新：

“它似乎有效，但我不知道 直到我有多个 ItemTypes 和 这些实例”

这正是我想就数据建模提出的观点。通过数据建模，我并不是指数据库的物理构造，而是对底层数据——“逻辑数据”的透彻理解。从笔和纸/白板开始是很好的第一步；从那以后，您可能会继续使用一个或多个数据库进行一些设计工作，以便在提交完整系统之前进行实际尝试。

"如果这个规模的系统可以像 高效，那么为什么不能 这个？”

您可能正在尝试比较苹果和梨。 一些原因：

• 硬件和配置。我猜你的系统和这个不完全一样。
• 架构优先级：我猜想我认为这个网站的构建考虑了性能；这当然不是您事后才能添加的东西，但是，这并不意味着您不能提高旧系统的性能 - 当然可以 - 尽管这是一项专业技能。
• 缓存，预计算：使用缓存是提高性能的一种相当明显的方法。另一种方法是在请求数据之前预先计算数据。这是您可能需要考虑的事情。