jpa获取所有表名，怎么实现

看来LZ并没有认真看API文档啊，在接口Connection中有一个getMetaData（）函数，其返回值是接口DatabaseMetaData，里面有各种数据库的配置信息，如是否支持空、最大连接数、用户可以调用的所有存储过程等，其中包括getSchemas（）-获取所有模式

int型。数据库中，int是一种数据类型，同时，作为函数，int函数指数据库中常用函数中的“向下取整函数”。常用来取一个数中的整数部分。Int是将一个数值向下取整为最接近的整数的函数。为取整函数。

由于需要提升项目的搜索质量，最近研究了一下Elasticsearch，一款非常优秀的分布式搜索程序。最开始的一些笔记放到github，这里只是归纳总结一下。

首先，为什么要使用Elasticsearch？最开始的时候，我们的项目仅仅使用MySQL进行简单的搜索，然后一个不能索引的like语句，直接拉低MySQL的性能。后来，我们曾考虑过sphinx，并且sphinx也在之前的项目中成功实施过，但想想现在的数据量级，多台MySQL，以及搜索服务本身HA，还有后续扩容的问题，我们觉得sphinx并不是一个最优的选择。于是自然将目光放到了Elasticsearch上面。

根据官网自己的介绍，Elasticsearch是一个分布式搜索服务，提供Restful API，底层基于Lucene，采用多shard的方式保证数据安全，并且提供自动resharding的功能，加之github等大型的站点也采用 Elasticsearch作为其搜索服务，我们决定在项目中使用Elasticsearch。

对于Elasticsearch，如果要在项目中使用，需要解决如下问题：

索引，对于需要搜索的数据，如何建立合适的索引，还需要根据特定的语言使用不同的analyzer等。

搜索，Elasticsearch提供了非常强大的搜索功能，如何写出高效的搜索语句？

数据源，我们所有的数据是存放到MySQL的，MySQL是唯一数据源，如何将MySQL的数据导入到Elasticsearch？

对于1和2，因为我们的数据都是从MySQL生成，index的field是固定的，主要做的工作就是根据业务场景设计好对应的mapping以及search语句就可以了，当然实际不可能这么简单，需要我们不断的调优。

而对于3，则是需要一个工具将MySQL的数据导入Elasticsearch，因为我们对搜索实时性要求很高，所以需要将MySQL的增量数据实时导入，笔者唯一能想到的就是通过row based binlog来完成。而近段时间的工作，也就是实现一个MySQL增量同步到Elasticsearch的服务。

Lucene

Elasticsearch底层是基于Lucene的，Lucene是一款优秀的搜索lib，当然，笔者以前仍然没有接触使用过。:-)

Lucene关键概念：

Document：用来索引和搜索的主要数据源，包含一个或者多个Field，而这些Field则包含我们跟Lucene交互的数据。

Field：Document的一个组成部分，有两个部分组成，name和value。

Term：不可分割的单词，搜索最小单元。

Token：一个Term呈现方式，包含这个Term的内容，在文档中的起始位置，以及类型。

Lucene使用Inverted index来存储term在document中位置的映射关系。

譬如如下文档：

Elasticsearch Server 10 （document 1）

Mastring Elasticsearch （document 2）

Apache Solr 4 Cookbook （document 3）

使用inverted index存储，一个简单地映射关系：

Term

Count

Docuemnt

10 1

4 1

Apache 1

Cookbook 1

Elasticsearch 2

Mastering 1

Server 1

Solr 1

对于上面例子，我们首先通过分词算法将一个文档切分成一个一个的token，再得到该token与document的映射关系，并记录token出现的总次数。这样就得到了一个简单的inverted index。

Elasticsearch关键概念

要使用Elasticsearch，笔者认为，只需要理解几个基本概念就可以了。

在数据层面，主要有：

Index：Elasticsearch用来存储数据的逻辑区域，它类似于关系型数据库中的db概念。一个index可以在一个或者多个shard上面，同时一个shard也可能会有多个replicas。

Document：Elasticsearch里面存储的实体数据，类似于关系数据中一个table里面的一行数据。

document由多个field组成，不同的document里面同名的field一定具有相同的类型。document里面field可以重复出现，也就是一个field会有多个值，即multivalued。

Document type：为了查询需要，一个index可能会有多种document，也就是document type，但需要注意，不同document里面同名的field一定要是相同类型的。

Mapping：存储field的相关映射信息，不同document type会有不同的mapping。

对于熟悉MySQL的童鞋，我们只需要大概认为Index就是一个db，document就是一行数据，field就是table的column，mapping就是table的定义，而document type就是一个table就可以了。

Document type这个概念其实最开始也把笔者给弄糊涂了，其实它就是为了更好的查询，举个简单的例子，一个index，可能一部分数据我们想使用一种查询方式，而另一部分数据我们想使用另一种查询方式，于是就有了两种type了。不过这种情况应该在我们的项目中不会出现，所以通常一个index下面仅会有一个 type。

在服务层面，主要有：

Node: 一个server实例。

Cluster：多个node组成cluster。

Shard：数据分片，一个index可能会存在于多个shards，不同shards可能在不同nodes。

Replica：shard的备份，有一个primary shard，其余的叫做replica shards。

Elasticsearch之所以能动态resharding，主要在于它最开始就预先分配了多个shards（貌似是1024），然后以shard为单位进行数据迁移。这个做法其实在分布式领域非常的普遍，codis就是使用了1024个slot来进行数据迁移。

因为任意一个index都可配置多个replica，通过冗余备份的方式保证了数据的安全性，同时replica也能分担读压力，类似于MySQL中的slave。

Restful API

Elasticsearch提供了Restful API，使用json格式，这使得它非常利于与外部交互，虽然Elasticsearch的客户端很多，但笔者仍然很容易的就写出了一个简易客户端用于项目中，再次印证了Elasticsearch的使用真心很容易。

Restful的接口很简单，一个url表示一个特定的资源，譬如/blog/article/1，就表示一个index为blog，type为aritcle，id为1的document。

而我们使用>

大约一年以前 我为了学习一些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配置方式。

以上就是关于jpa获取所有表名，怎么实现全部的内容，包括:jpa获取所有表名，怎么实现、jpa 数据库数值加减设计成什么类型好、elasticsearch JPA执行save方法后，发现elasticsearch有文件生成，但数据库中没数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！