简体   繁体   English

DB表中的可变结构以Web形式读取

[英]Variable structure in a DB table to be read in a Web form

I have a "variable" structure to be put in a table DB. 我有一个“变量”结构要放在表数据库中。 By "variable" I mean a sequence of couples field/value in which the "kind" of field determines the value type, I don't know exactly field order and I don't know how many times fields can repeat. “变量”是指一系列字段/值对,其中字段的“种类”确定值的类型,我不知道确切的字段顺序,也不知道字段可以重复多少次。 Sometimes group of fields will repeat several times (it is a fiscal model). 有时,一组字段会重复几次(这是一种财务模型)。

Additional requirement: I should map these variable data into web page forms, handling some CRUD work. 附加要求:我应该将这些变量数据映射到网页表单中,以处理一些CRUD工作。 JQuery-ui, Struts 2, Hibernate. JQuery-ui,Struts 2,休眠 Preferred DBMS: MySQL. 首选的DBMS:MySQL。

The solutions I thought of: 我想到的解决方案:

  1. vertical table. 垂直表。 I could have some performance issue, which I could resolve with materialized views that "pivot" the rows in columns when I need massive data process. 我可能会遇到一些性能问题,可以使用物化视图解决该问题,这些视图可以在需要大量数据处理时“旋转”列中的行。 Not gone so far in this direction as it seems to be very expensive for development. 在这个方向上并没有走太远,因为开发似乎很昂贵。
  2. LOB fields. LOB字段。 Pack my columns into one of those, perhaps having a "mapping" table to decode each column. 将我的列打包为其中的一个,也许有一个“映射”表来解码每个列。 My idea is to pull-out searchable fields as "real" columns in order to leave in the LOB just the less interesting mob of data and not to generate performance problems. 我的想法是将可搜索字段提取为“实际”列,以便仅将不太有趣的数据留在LOB中,而不会产生性能问题。
  3. or better 2a. 或更好的2a。 Use an xml inside the LOB field. 在LOB字段内使用xml。 This could be useful to pack/unpack data more comfortably, specially having to map data to a web form. 这对于更舒适地打包/解压缩数据很有用,特别是必须将数据映射到Web表单时。

What do you think? 你怎么看? And more, is there some way to create automatic views from xml fields? 还有更多的方法可以从xml字段创建自动视图吗? Or better to map such data to web form? 还是更好地将此类数据映射到Web表单? I suspect Hibernate Tools won't work in any of the cases I described. 我怀疑Hibernate Tools在我描述的任何情况下都无法使用。

I hope I have been clear, it's still a bit confusing even to me :) 我希望我已经很清楚了,甚至对我来说还是有点困惑:)

Your option 1 is the Entity-Attribute-Value antipattern. 您的选项1是Entity-Attribute-Value反模式。

See my answer to Product table, many kinds of product, each product has many parameters and my blog post EAV FAIL for alternatives and some reasons why EAV is wrong, at least for a relational database (I cover EAV in my book, SQL Antipatterns: Avoiding the Pitfalls of Database Programming ). 请参阅我对产品表,多种产品的回答,每种产品都有许多参数,以及有关替代品和EAV错误的某些原因的博客文章EAV FAIL ,至少对于关系数据库而言(我在本书的SQL Antipatterns中介绍了EAV :避免数据库编程的陷阱( )。

Also read this article about how a similar structure nearly doomed a company: Bad CaRMa . 还请阅读本文,了解类似的结构如何几乎注定了一家公司: Bad CaRMa

Your options 2 & 3 are similar to described in How FriendFeed uses MySQL to store schema-less data . 您的选项2和3与FriendFeed如何使用MySQL存储无架构数据中的描述类似。 I don't know of any automatic way for an ORM to maintain that structure for you. 我不知道ORM为您维护该结构的任何自动方式。 You do have the chore of keeping your inverted index tables in sync with your LOB data. 您确实需要使倒排索引表与LOB数据保持同步。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM