Java EE中的动态类型表/模型？ [英] Dynamic Typed Table/Model in Java EE?

问题描述

通常使用Java EE创建Model时，我们通过XML或注释在编译时间之前定义字段和字段类型。有没有办法在运行时更改这些？或者更好，是否可以在运行时基于用户的输入创建一个新的模型？这样列的数量和字段类型是动态的（在运行时确定）？

帮助非常感谢。非常感谢。

我觉得需要澄清自己。

1. 是的，我的意思是数据库建模，当谈到模型。




2. 对于用例，我想为用户提供一种手段来定义和创建他们自己的表。不需要无限的灵活性。然而，必须有一定程度的自由度：例如。用户可以定义描述他们的产品所需的字段。

解决方案

我在一个系统，我们有这样的设施。为了保持高效，我们将为客户模式动态生成/更改表。我们还需要嵌入一个元模型（模型模型）来动态处理实体中的信息。

选项1：自定义表，您具有完全的灵活性，但也显着增加了复杂性，尤其是现有数据的更新/迁移。以下是您需要考虑的事项：

• 如果列的类型改变了怎么办？


• 如果添加了列，该怎么办？是否有默认值？


• 如果列被删除会怎么样？我可以舍弃现有信息吗？


• 如何管理列的重命名？


• 如何使数据库之间可移植？


• 如何在数据库级别$ b
• 如何管理人为错误（例如，用户删除列，然后改变主意）？


• 如何管理迁移（脚本，部署等）

> 选项2：一种轻量级替代方法是在不同类型的业务表中添加一些备用列（例如：USER_DATE_1，USER_DATE_2等）。我看到几次。这将使你的DBA尖叫，并不是真正被认为是一个好的做法，但至少可以促进一些事情，例如。 （迁移脚本，ORM集成）。

选项3：另一个选择是将结果属性/数据存储在表中。但是，这真的是数据库性能的灾难。任何不完全微不足道的东西都需要许多连接。

选项4：它是选项2和3的混合。核心表是固定的，但是一个具有属性/数据的表格可以用于以某种方式扩展它们。

总之：在你这样做之前，想两次。这可以完成，但对应用程序的设计和维护有重大影响。

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.

1. Yes, I meant database modeling, when talking about Model.

2. 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.

解决方案

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:

• What if the type of a column change?
• What if a column is added? Is there a default value?
• What if a column is removed? Can I discard the existing information?
• How to manage renaming of a column?
• How to make things portable across databases?
• How to make it efficient at database-level (e.g. indexes) ?
• How to manage a human error (e.g. user removes a column then changes its mind)?
• How to manage migration (script, deployment, etc.) when new version of the system is installed at customer site?
• How to have this while using an ORM?

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.

这篇关于Java EE中的动态类型表/模型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！