动态产生的持久模型和数据存储,这个词语感觉挺晦涩的,不过估计在实际的项目中或者研发的产品中大家都碰到过这样的场景:
例如在一个简单的考试系统中,出题人在系统中出题,答题人进行相应的答题。
问题:
这一个简单的场景映射到系统中通常会形成这样的问题,出题人所出的题目其实就映射到了一个题目的持久模型,而答题人进行答题时则是基于这个动态产生的持久模型进行的数据存储,这里的问题就是怎么去产生这个动态的持久模型,怎么去将数据存储到这个持久模型里去。
问题分析:
来看正常的情况下关于持久数据的做法,正常情况下,首先我们设计了一个表或PO,在保存数据时则可直接将相应的数据保存至表中。
但在现在的场景下,这个表或PO需要在系统运行时产生,之后数据才能象正常的情况那样去保存。
解决方案:
根 据上面的问题分析,一种解决方案显而易见,就是动态的产生表或PO,这种方案应该是说难不难,说简单也不简单,这里最需要注意的是产生的表的字段的属性的 设置,以及在修改时表的字段的同步维护,如果是动态产生PO的话就比较麻烦,因为按照hibernate的话,还需要生成hbm、修改 hibernate.cfg.xml,并且还需要重载SessionFactory才能生效,这种解决方案在修改持久模型时要特别注意,就是数据的保持, 很多时候采用版本策略也许更为适合。
另外一种解决方案也是经常采用的,就是不去动态的产生表或PO,而是提供一种通用的数据持久策略,一个简单的 实现就是设计一张存储数据的表,这张表的字段由字段名外键、字段值共同构成,字段名外键关联到动态产生的持久模型的字段,字段值则为实际进行数据存储时的 值,这种方案很明显的一个问题就是,会造成这张表的增长速度非常的块,特别是在动态产生的持久模型中有超多字段的时候,另外一个不是很方便的地方就是在查 询的时候很麻烦。
在实际项目中更倾向于第一种解决方案,不过在采用Hibernate之类ORM的时候第一种解决方案就比较麻烦了,第二种解决方案感觉更适用于动态产生的持久模型字段比较少,实际产生的数据也比较少、查询要求比较低的情况下。
不知道大家对于这种场景通常都会采用什么样的解决方案呢?
ps:还有一个场景感觉也是常见的,就是需要动态的扩展目前已有的PO或表,不知道在这个场景中大家会采用什么样的解决方案,预留字段?动态修改表?关联属性扩展表?抑或别的..........
例如在一个简单的考试系统中,出题人在系统中出题,答题人进行相应的答题。
问题:
这一个简单的场景映射到系统中通常会形成这样的问题,出题人所出的题目其实就映射到了一个题目的持久模型,而答题人进行答题时则是基于这个动态产生的持久模型进行的数据存储,这里的问题就是怎么去产生这个动态的持久模型,怎么去将数据存储到这个持久模型里去。
问题分析:
来看正常的情况下关于持久数据的做法,正常情况下,首先我们设计了一个表或PO,在保存数据时则可直接将相应的数据保存至表中。
但在现在的场景下,这个表或PO需要在系统运行时产生,之后数据才能象正常的情况那样去保存。
解决方案:
根 据上面的问题分析,一种解决方案显而易见,就是动态的产生表或PO,这种方案应该是说难不难,说简单也不简单,这里最需要注意的是产生的表的字段的属性的 设置,以及在修改时表的字段的同步维护,如果是动态产生PO的话就比较麻烦,因为按照hibernate的话,还需要生成hbm、修改 hibernate.cfg.xml,并且还需要重载SessionFactory才能生效,这种解决方案在修改持久模型时要特别注意,就是数据的保持, 很多时候采用版本策略也许更为适合。
另外一种解决方案也是经常采用的,就是不去动态的产生表或PO,而是提供一种通用的数据持久策略,一个简单的 实现就是设计一张存储数据的表,这张表的字段由字段名外键、字段值共同构成,字段名外键关联到动态产生的持久模型的字段,字段值则为实际进行数据存储时的 值,这种方案很明显的一个问题就是,会造成这张表的增长速度非常的块,特别是在动态产生的持久模型中有超多字段的时候,另外一个不是很方便的地方就是在查 询的时候很麻烦。
在实际项目中更倾向于第一种解决方案,不过在采用Hibernate之类ORM的时候第一种解决方案就比较麻烦了,第二种解决方案感觉更适用于动态产生的持久模型字段比较少,实际产生的数据也比较少、查询要求比较低的情况下。
不知道大家对于这种场景通常都会采用什么样的解决方案呢?
ps:还有一个场景感觉也是常见的,就是需要动态的扩展目前已有的PO或表,不知道在这个场景中大家会采用什么样的解决方案,预留字段?动态修改表?关联属性扩展表?抑或别的..........