Java EE 中的动态类型表/模型？
通常在Java EE中，当我们创建Model时，我们在编译之前通过XML或注释来定义字段和字段类型。有没有办法在运行时更改这些？或者更好的是，是否可以在运行时根据用户的输入创建一个新模型？这样列的数量和字段的类型是动态的（在运行时确定）？
非常感谢您的帮助。谢谢。
我觉得有必要澄清一下自己。
是的，当谈论模型时，我指的是数据库建模。
对于用例，我想为用户提供一种定义和创建自己的表的方法。不需要无限的灵活性。然而，必须有一定程度的自由：例如，用户可以定义描述其产品所需的字段。
Usually with Java EE when we create Model, we define the fields and types of fields through XML or annotation before compilation time. Is there a way to change those in runtime? Or better, is it possible to create a new Model based on the user's input during the runtime? Such that the number of columns and types of fields are dynamic (determined at runtime)?
Help is much appreciated. Thank you.
I felt the need to clarify myself.
Yes, I meant database modeling, when talking about Model.
As for the use cases, I want to provide a means for users to define and create their own tables. Infinite flexibility is not required. However some degree of freedom has to be there: e.g. the users can define what fields are needed to describe their product.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您听起来好像希望能够根据运行时的用户输入来更改对象和架构。对我来说，这听起来像是一场灾难。我从来没有见过它被完成。
我见过将外键关系合并到名称/值对的通用表中的通用模式，但这些往往会成为无限灵活的抽象，在性能方面既不能轻易理解，也不能摆脱自己的方式。
我敢打赌，您的用户确实不想要无限的灵活性。我警告你不要走这个方向。最好弄清楚你的真实用例。
当然，一切皆有可能。我的直接经验告诉我，如果你能成功的话，你的用户会讨厌它，这是一个坏主意。祝你好运。
You sound like you want to be able to change both objects and schema according to user input at runtime. This sounds like a chaotic recipe for disaster to me. I've never seen it done.
I have seen general schemas that incorporate foreign key relationships to generic tables of name/value pairs, but these tend to become infinitely flexible abstractions that can neither be easily understood nor get out of their own way when it comes to performance.
I'm betting that your users really don't want infinite flexibility. I'd caution you against taking this direction. Better to get your real use cases straight.
Anything is possible, of course. My direct experience tells me that it's a bad idea that your users will hate if you can pull it off. Best of luck.
我在一个拥有此类设施的系统上工作。为了保持效率，我们将为客户模式动态生成/更改表。我们还需要嵌入一个元模型（模型的模型）来动态处理实体中的信息。
选项 1：使用自定义表，您可以获得充分的灵活性，但它也会显着增加复杂性，尤其是现有数据的更新/迁移。以下是您需要考虑的事项列表：
选项2：一个轻量级的替代方案是在不同类型的业务表中添加一些“备用”列（例如：“USER_DATE_1”、“USER_DATE_2”等）我见过一些次。它会让您的 DBA 尖叫，并且实际上并不被认为是一个好的实践，但至少可以促进一些事情，例如（迁移脚本、ORM 集成）。
选项 3：另一个选项是将所有内容存储在具有结构属性/数据的表中。但这对于数据库性能来说确实是一场灾难。任何不完全琐碎的事情都需要许多连接。 DBA 会尖叫得更厉害。
选项 4：它是选项 2 和 3 的混合。核心表是固定的，但可以使用具有属性/数据的表以某种方式扩展它们。
总之：在走这条路之前要三思而后行。这是可以做到的，但对应用程序的设计和维护有重大影响。
I worked on a system where we had such facilities. To stay efficient, we would generate/alter the table dynamically for the customer schema. We also needed to embed a meta-model (the model of the model) to process information in the entities dynamically.
Option 1: With custom tables, you have full flexibility, but it also increases the complexity significantly, notably the update/migration of existing data. Here is a list of things you will need to consider:
Option 2: A lightweight alternative is to add a few "spare" columns in the business tables of different types (e.g.: "USER_DATE_1", "USER_DATE_2", etc.) I've seen that a few times. It will makes your DBA scream and is not really considered a good practice, but at least can facilitates a few things, e.g. (migration scripts, ORM integration).
Option 3: Another option is to store everything in a table with a structure property/data. But then it's really a disaster for database performance. Anything that is not completely trivial will require many joins. And the DBA will scream even more.
Option 4: It is a mix of options 2 and 3. Core tables are fixed, but a table with property/data can be used to somehow extend them.
In summary: think twice before you go this way. It can be done, but has a significant impact on the design and maintenance of the application.
使用元建模技术，这在某种程度上是可能的：
但这有明显的限制（缺乏强类型对象），恕我直言，它会很快变得非常复杂（不是甚至确定如何处理关系）。我不会使用这种方法来完全定义域对象，而只是扩展现有的域对象（产品、文章等）。
如果我没记错的话，这就是一些电子商务解决方案（例如 BroadVision）正在做的事情。
This is somehow possible using meta-modeling techniques:
But this has obvious limitations (lack of strong typed objects) and can IMHO get quickly very complicated (not even sure how to deal with relations). I wouldn't use this approach to define domain objects entirely, but only to extend existing ones (products, articles, etc).
If I remember well, this is what some e-commerce solutions (e.g. BroadVision) were doing.
我想我自己已经找到了一个很好的答案。那些新的 no-sql（hbase、cassandra）数据库似乎正是我正在寻找的。谢谢大家的回答。
I think I have found a good answer myself. Those new no-sql (hbase, cassandra) database seems to be exactly what I was looking for. Thanks everyone for your answeres.