基于hibernate 的JPA规范 如何反向生成数据库 请详细点，最好有简单的实例， J2se J2ee的都需要

反向生成是要依赖数据库中的数据表，以及hibernate模板的，模板网上有写好的，你也可以根据自己的需求自己写，在myeclipse里打开DB界面，连接到你用的数据库，找多要生成反向工程的表右击有个hibernate reverse的项，在里面设置参数然后选择hibernante模板，finish就可以了

大约一年以前 我为了学习一些Hibernate专业知识 因此我参加了一个Hibernate项目 从那时起 我一直在使用Hibernate框架下的JPA（Java持久API）实现 使用的思想仍就是一样的 那个项目使用了一个数据库 这个数据库规模有些大 略显落后 并且还被许多的应用程序共用 为了尽快加入到项目中 我开始学习一些Hibernate知识 从书本上的例子开始学习 感觉很简单 学起来也很快 但是发现从零开始开发一个项目 并且控制它又是另外一回事了 试着在一个大型 复杂 被许多应用程序共用的数据库上使用Hibernate就又完全不同了 弄清楚了我可能遭遇到的技术难点 我开始想别的招了 要尽快从另外的方向开始 克服困难

在最终的学习和实践中 我发现我还是学到了许多重要的东西 虽然我们的项目还没有完全做完 但是我认为我们目前已经非常漂亮的应用了Hibernate/JPA的一些思想 现在我需要重新思考反省我所学到的东西 如下便是我学到的一些心得

）和数据库管理员成为朋友

目前存在一个趋势 就是一些Java开发者忽视数据库管理员的重要性 这便犯了一个很大的错误 对于要取得任何的ORM（对象关系映射）技术的成功 和数据库管理员保持一个良好的工作关系是至关重要的 有如下两个原因

单独数据库管理员虽然不能使Hibernate项目成功 但是他们通常可以让这些项目失败

数据库管理员对数据库本身具有很好的洞察力 很好的职业习惯 告诉你一些易犯的错误和 *** 作建议 我能记起这样的很多例子 一个数据库管理员的建议节约了我们很多的时间和提供给我们一个很好的解决方案

在大多数情况下 拥有好的数据库管理员 并且和他们保持良好的关系对你ORM（对象关系映射）工作至关重要

）从一开始使用（最好强制使用）好的命名标准

我们知道对命名标准的讨论将会有争议的 但是我们必须明确一件事情 我们的命名要让我们的数据模型有意义 这能让开发者使用起来简单 以免他们迷惑 所以 如何命名实体和属性是非常重要的 我有我喜欢命名标准 并且认为他们是最好的 但是在这里我不想把他们强加于你们 最重要的是你自己做出决定使用什么样的命名标准 并且让所有人使用它 实际上 不仅仅命名标准需要统一 其它的也需要（如 布尔型用 Y/N 或者 / 表示）

）不要试着映射所有的属性

我们总是设法使用工具 如Dali来映射所有的东西 然后形成一张表格（一些表格有上百列 ！） 这最终会很麻烦 为什么？因为我们使用的是共用的 先前的数据库 有许多的字段是我们并不关心和从来不使用的 映射它们只会导致性能问题和造成混乱

）让数据库做自己擅长的工作

我们想有一个好的 清晰的数据模型 因此我们不惜任何代价写一些额外的查询语句来获取对象相关数据 要么使用存储过程 要么使用函数 这是做法是错误的 数据库优势在于存储 而不是保持Hibernate创建或读写的数据 举个例子 我们有一个对象 与之相关联的有一个状态 这个状态在整个应用程序中都要用到 因此 它毫无疑问是要执行的 但是 我们不想每次都要单独的写一个查询语句 这个问题在于 这个状态是从一些统计计算中派生出来的 并且这些统计计算需要用到一对多的关系 每次从加载的对象中读取数据的代价是非常高的 后来跟我们其中的一位数据库管理员交流了一下 发现一个我们可以使用的sql函数能够很快的获得该状态 我们使用@Formula来映射成一个状态属性 就能得到我们所需要的所有东西 这仍就是域模型的一部分 但是执行起来非常好 有时像这样的一个折衷的办法能够起到很大的效果

）分解数据库

在一开始 我就想在Hibernate中模型化整个数据库 结果发现这是不切实际的 原因如下 a）这是一项巨大的工程 并且要花费几周的时间 而用户根本看不到你做了什么实际的工作

b）我不可能在第一次就把它弄好 后继的开发者无论如何都会修改它们的

现在有一个趋势 就是希望在开始之前 将所有的事情都进行映射 但是 当时你开始这么做后 你不需在这上面花很多的时间 我后来发现一个好的办法 就是将数据库分解 工作的时候一块一块的进行 发现这很有帮助

）密切注意触发器

密切注意数据库触发器有如下两个原因

a）在后台触发器很隐蔽的执行了一些功能 让你很是疑惑 不知道发生了什么

b）当你在Hibernate端需要复制一些东西的时候 触发器会做一些手脚 之前我们好几次没有认识到这个教训 导致我们丢失了很多数据 这些都是由触发器引起的 这几乎让我们很是郁闷

）避免使用工具来自动生成你的模型

没错 这些工具的使用可以节约时间（虽然我们发现了Dali有一个很严重的bug 但是我们还是使用它） 但是最后你不得不重新做很多的事情 其实手动也花费不了你很多的时间 当你亲自做的时候 这可以让你有机会熟悉那些数据

） 尽量多的使用命名查询语句（NamedQueries）

虽然很容易写查询语句 但是在许多的情况下 使用NamedQueries会更好 这会有助于你完成两件事情

a）它能更加重用 因为被命名的查询语句通常在代码的重要地方

b）你的查询语句在开始的时候就是正确的 那么在查询语句中的错误更加容易发现

要习惯这样做需要花一些时间 但是这么做是值得的

）预期管理

对于任何一种框架 技术 甚至观念来说 这是非常重要的 要铭记在心 由于某些原因 人们倾向于专注某一个特征 这些特征实际上或许不存在 或许被夸大 有时它很小 很容易理解（举个例子 理解一些实际的工作 需要在Hibernate中映射） 有时我也不知道他们是如何管理实现一些概念（如Hibernate是如何管理计划修正的） 无论如何 找到预期目标是什么 然后管理它们是非常重要的 如果你的团队认为Hibernate会使得数据库管理员没有用处 把他们解雇 那么你将会有一个潜在的问题存在

）使用富域模型（rich domain modeling）

lishixinzhi/Article/program/Java/ky/201311/28274

IDEA ULTIMATE 版支持此功能。

配置IDEA中此项目的Database。添加hibernate支持。

使用Generate Persistence Mapping---->By Database Schema选项。

选择数据库表文件以及生成路径，名称等后自动生成文件。支持注解方式和XML配置方式。

opendatasource('sqloledb,'Data Source=服务器地址;UserID=sa;Password=pass@word1 ')数据库名字dbo[表名] 这是跨服务器的调用，如不是不是跨服务器，直接数据库名dbo表名

以上就是关于基于hibernate 的JPA规范 如何反向生成数据库 请详细点，最好有简单的实例， J2se J2ee的都需要全部的内容，包括:基于hibernate 的JPA规范 如何反向生成数据库 请详细点，最好有简单的实例， J2se J2ee的都需要、Hibernate/JPA成功使用的十点心得、intellij怎么用jpa通过数据库生成实体类等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！