我有一个表,它的一些列在编译时是未知的。这样的列可以是整数值,也可以是一些枚举值。有一个表包含这些动态列的所有名称,并且也包含列的类型。这种 “元表” 具有以下的列:NHibernate /流利NHibernate的动态列映射
- DynamicColumnId(PK)
- 名称
- TYPEID(整数/枚举,为Fk从一个单独的表)
整型列具有从这个表名称,而Enum列是表中的Fk列,它具有名称,并进行了一些修改(例如“DynamicTable”前缀)。
我能想到的唯一解决方案就是使用Reflection.Emit动态创建实体类和相应的Mapping类。无可否认,我是NHybernate/Fluent NHybernate的新手,它似乎是一张表格之间相对简单的层次结构,所以我想验证我的解决方案并不像它最初出现的那么丑陋...
我也会欢迎完全无视我的表层次结构的解决方案,以便有效地实现相同的结果(即,枚举动态表上的行,遍历所有列,并知道它们是否是Enums,如果它们是它们的可能的值也是如此)。
(编辑:其他信息重新问题域) 我最初包括最小的细节,以避免太多信息相关的混淆。 这个描述要复杂得多,但它揭示了这个设计背后的动机。
涉及的应用程序旨在自动执行日志/转储分析。分析场景通常由日志/转储专家提供,因此,为了简化需求=>实现=>验证周期的典型过程,此类分析场景由专家直接作为Iron Python代码段执行,并与一些特定领域的构造注入片段的范围。每个片段都有一个与其相关的“上下文”。 “上下文”的一个例子可以是“产品”,“版本”等等。因此,片段本身只在特定的上下文中调用 - 这有助于通过消除分支来简化Python代码(您可以将其视为面向方面编程, 在某种程度上)。非专家可以使用具有给定代码上下文数据库的应用程序在为各种上下文选择值之后分析日志/转储。 当专家决定编写某个代码片段需要一个新的上下文时,他可以添加一个上下文,指出其可能的值。一旦新的上下文被添加到数据库中,运行分析的非专家将被赋予为新添加的上下文选择一个值的选项。 “动态表”是将代码片段与发布代码片段时存在的各种上下文(列)的值相关联的表格,加上当时不存在的列的默认值。
你的意思是你想在运行时修改数据库模式吗? – Paco 2010-03-09 16:26:40
这通常是一种糟糕的设计方法。因此,这总是取决于情况。您能否提供更具体的域名信息,以便我们能够弄清楚自己需要完成什么? – 2010-03-09 16:36:35
我同意Will的观点,我还没有找到“动态表格”有意义的情况。 – 2010-03-09 16:47:08