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

Question

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

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

此前有没有人面对过这种系统的创造，如果是这样的话，在我进一步深入之前，有什么重要的我遗漏或者我可能想要考虑的任何事情吗？我的意思是我可能会遇到一些问题，以后我可以通过做某事来避免这种问题？或者，是否有任何技术可以提供很多帮助？我试过Linq但发现很难根据我的需要定制它。我目前正在使用VB.Net 2.0（由服务器设置的限制;不在我的控制之下）和Sql Server 2008.我创建了自己的系统，该系统源自MVC类型的架构。

提前致谢。

此致

理查德

编辑：

我的新数据库结构是：

表：ItemType

• ID
• 名称

表：ItemTypeProperty

• ID
• ItemTypeID
• 名称
• 描述
• 字段类型字段

表：项目

• ID
• ItemTypeID

表：ItemPropertyValues

• ID
• 的ItemID
• ItemTypePropertyID
• 值

Answer 1

这里有哪些主要的建筑驱动因素？可维护性有多重要？您如何将它们与性能等运行时需求进行比较？

这可能听起来有点陈词滥调 - 但是对于什么是重要的和什么不重要有明确的想法将帮助你做出正确的决定。

我这样说的原因是因为用户可以定义通常在应用程序中更严格设置的内容的系统隐含地更复杂，因此更难以使用。基本上这是一个权衡：一些任务将变得更容易 - 其他任务更难。

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

具体细节：

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

<强>更新

  

“它似乎有效，但我不知道   直到我有多个ItemTypes和   那些“

的实例

这正是我想要对数据建模做出的观点。通过数据建模，我没有太多意思是DB的物理构造，而是对底层数据的彻底理解 - “逻辑数据”。从笔＆amp;开始纸/白板是一个伟大的第一步;从那开始，你可能会使用一个或多个数据库进行一些设计工作，以便在提交到完整系统之前实际​​尝试。

  

“如果这个尺寸的系统可以如此   因为它是有效的，为什么不能   吗？“

你可能想要比较苹果和梨。 一些原因：

• 硬件和配置。我猜你的系统和这个系统并不完全一样。
• 建筑优先事项：我猜想这个网站的构建考虑到了性能;它肯定不是你可以添加的东西，但是，这并不意味着你无法改善旧系统的性能 - 你当然可以 - 虽然它是一种专业技能。
• 缓存，预计算：使用缓存是提高性能的一种相当明显的方法。另一种方法是在请求之前预先计算数据。这是你可能想要考虑的事情。