NHibernate / Fluent NHibernate动态列映射 [英] NHibernate / Fluent NHibernate Dynamic Column Mapping

查看:225
本文介绍了NHibernate / Fluent NHibernate动态列映射的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个表,其中一些列在编译时是未知的。这些列可以是整数值,也可以是一些枚举值。有一个表保存这些动态列的所有名称,并保存列的类型。此metatable包含以下列:

I have a table that, some of its columns are unknown at compile time. Such columns could either be of an integer value, or some Enum value. There is a table that holds all the names of such dynamic columns and also holds the column's type. This "metatable" has the following columns:


  • DynamicColumnId(Pk)

  • 名称

  • TypeId(整数/枚举,作为单独表中的Fk)

整数列具有名称,而枚举列是具有 Name 的表的Fk列,并进行了一些修改(例如,DynamicTable前缀)。

Integer columns have the Name from this table, whereas Enum columns are Fk columns from a table that has that Name, with some modification (e.g. a "DynamicTable" prefix).

我可以想到的唯一解决方案是使用Reflection.Emit动态创建一个Entity类和一个相应的Mapping类。诚然,我是新的NHybernate / Fluent NHybernate,它似乎是一个相对简单的层次结构之间的表,所以我想验证我的解决方案不像最初出现的丑陋...

The only solution I could think of for this situation is using Reflection.Emit to dynamically create an Entity class and a corresponding Mapping class. Admittedly, I'm new to NHybernate / Fluent NHybernate and it seems like a relatively simple hierarchy between the tables, and so I wanted to verify my solution isn't as ugly as it initially appears...

我也欢迎完全忽视我的表层次结构的解决方案,以便有效地获得相同的结果(即枚举动态表上的行,遍历所有列,

I would also welcome solutions that completely disregard my table hierarchy, in order to effectively acheive the same results (that is, to enumerate the rows on the dynamic table, going over all the columns, with knowledge of whether they are Enums and, if they are, their possible values as well).

编辑:附加信息问题域
我最初包含最小的细节,以避免Too-Much-Info相关的混淆。
这个描述要复杂得多,但它会揭示这个设计的动机。

( Additional information re problem domain) I initially included minimal details, as to avoid Too-Much-Info related confusion. This description is much more complex, but it unravels the motives behind this design.

这个应用程序设计用于自动化日志/转储分析。分析场景通常由日志/转储专家提供,因此为了简化requirements => implementation =>验证周期的典型过程,这种分析场景由专家直接实现为Iron Python代码片段,一些域特定的结构注入到片段的范围。每个片段都有一个上下文,它是相关的。 上下文的例子可以是product,version等等。因此,代码片段本身只在特定上下文中被调用 - 这有助于通过消除分支来简化Python代码(你可以将它看作面向方面的编程, 在某种程度上)。非专家可以在为各种上下文选择值之后使用具有给定代码上下文数据库的应用来分析日志/转储。
当专家决定需要一个新的上下文来编目某个代码片段时,他可以添加一个上下文,指示它可能具有的值。一旦将新的上下文添加到数据库,运行分析的非专家将被给予选择为新添加的上下文选择值的选项。
动态表是将代码段与发出代码段时存在的各种上下文(列)的值以及当时不存在的列的默认值相关联的表。 p>

The application involved is designed to automate log/dump analysis. Analysis-scenarios are frequently provided by the log/dump experts and so, in order to streamline the typical process of requirements=>implementation=>verification cycle, such analysis-scenarios are implemented by the experts directly as an Iron Python code snippet, with some domain-specific constructs injected into the snippets' scope. Each snippet has a "context" for which it is relevant. An example of "context" could be "product," "version," etc... So, the snippet itself is only invoked in certain contexts - this helps simplifying the Python code by eliminating branching (you could view it as Aspect Oriented Programming, to some extent). A non-expert could use the application, with a given code-context database, to analyze a log/dump, after choosing values for the various contexts. When an expert decides that a new context is required for cataloging a certain code snippet, he could add a context, indicating the possible values it could have. Once a new context is added to the database, a non-expert that runs an analysis will be given the option to choose a value for the newly-added context. The "dynamic table" is the table that associates a code snippet with values of the various contexts (columns) that existed when the snippet was issued, plus default values for the columns that did not exist at that time.

推荐答案

我不会声称完全理解你的情况,但在我看来你最好使用key-值存储(如 Redis )或无模式数据库(如 CouchDB 而不是SQL。这似乎并不是一个关系数据库的问题,但如果你真的需要使用RDBMS我将映射NHibernate尽可能接近真正的模式(DynamicColumnId,Name,TypeId),然后构建任何你需要的数据结构

I won't claim to fully understand your scenario, but it seems to me that you'd be better off using a key-value store such as Redis or a schema-less database like CouchDB instead of SQL. This doesn't seem to be a problem for a relational database, but if you really need to use a RDBMS I'd map NHibernate as closely as possible to the real schema (DynamicColumnId, Name, TypeId) then build whatever data structure you need on top of that.

这篇关于NHibernate / Fluent NHibernate动态列映射的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆