社区
Java EE
帖子详情
HIBERNATE要连接C-Tree数据库,要配置哪个方言?
naturemickey
2011-05-25 02:16:12
网上搜了很久,没找到。
有相关经验者帮个忙解答,
没有相关经验的帮忙搜一下。
C-Tree数据库页面:
http://www.faircom.com/ace/index_t.php
...全文
87
9
打赏
收藏
HIBERNATE要连接C-Tree数据库,要配置哪个方言?
网上搜了很久,没找到。 有相关经验者帮个忙解答, 没有相关经验的帮忙搜一下。 C-Tree数据库页面: http://www.faircom.com/ace/index_t.php
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
9 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
naturemickey
2011-06-20
打赏
举报
回复
上面一点回音都没有,很可能不考虑用它了。
yingzhuo2011
2011-05-25
打赏
举报
回复
如果最后决定自定义方言的话,那麻烦你最后公布一下结果好吗?
naturemickey
2011-05-25
打赏
举报
回复
公司是不缺钱的。
公同内部一百多个系统,80%用的都是ORACLE,
已经几年了。
所以肯定不会是因为比较便宜而选择C-Tree或MySQL等数据库。
至于为什么选择C-Tree,我不知道,
不过看FairCom公司网上的Success Stories应该不是假的:
http://www.faircom.com/ace/customers_ss_t.php
C-Tree一定有些优势,才会被选中。
我还在看文档,具体好不好用,看看再说吧。
yingzhuo2011
2011-05-25
打赏
举报
回复
嗯。 不错,最坏情况就是要自己实现一个方言了。
其实数据库的选择为什么是这个“非主流”的呢?有免费开源的MySql不就挺好的吗?
naturemickey
2011-05-25
打赏
举报
回复
已经试过DerbyDialect了,目前试了一些基本的SQL,是没问题的,
但对于分页查询DerbyDialect中没有支持,Hibernate只能用最笨的方法。
SQLServerDialect对于分页查询与C-Tree是一样的,但我看了C-Tree的SQL文档,
它对于与null做比较的表达式处理与sqlServer不一样,它是与ORACLE一样的。
目前还没有找到合适的。
最理想的办法就是劝说公司不要用这个数据库,否则可能要自己写方言了(公司的框架用的Hibernate,这是不能改的)。
yingzhuo2011
2011-05-25
打赏
举报
回复
C-Tree 我也没有用过, 你要是试了不行也别埋怨我啊。
我只是叫你尝试一下。
yingzhuo2011
2011-05-25
打赏
举报
回复
试一试
org.hibernate.dialect.DerbyDialect
Derby 数据库完全支持 SQL92F标准,没准你那个也是呢?
naturemickey
2011-05-25
打赏
举报
回复
怎么没人回呀!
支持多
数据库
的ORM框架ef-orm.zip
ef-orm A Simple OR-Mapping framework on multiple databases. 使用手册(中文)http://geequery.github.io/ef-orm/manual/EF-ORM-user-guide.docx 使用示例工程 https://github.com/GeeQuery/ef-orm/
tree
/master/orm-tutorial EF-ORM是一个轻量,便捷的Java ORM框架。并且具备若干企业级的应用特性,如分库分表、JTA事务等。 代码生成插件for eclipse(请在eclipse中Help/Install new software后输入地址并安装)http://geequery.github.io/plugins/1.3.x/特点一 EF的设计的一个主要目的是提高开发效率,减少编码工作,让开发者“零
配置
”“少编码”的操作
数据库
大部分功能。 例如:
数据库
查询条件的传入问题是所有ORM框架都不能回避的一个问题,所以我经常在想——既然我们可以用向DAO传入一个Entity来实现插入操作,为什么就不能用同样的方法来描述一个不以主键为条件的update/select/delete操作?为什么DAO的接口参数老是变来变去?为什么很多应用中,自行设计开发类来描述各种业务查询条件才能传入DAO?为什么我们不能在数据访问层上花费更少的时间和精力? JPA1.0和早期的H框架,其思想是将关系型
数据库
抽象为对象池,这极大的限制了本来非常灵活的SQL语句的发挥空间。而本质上,当我们调用某H框架的session.get、session.load、session.delete时,我们是想传递一个以对象形式表达的
数据库
操作请求。只不过某H框架要求(并且限制)我们将其视作纯粹的“单个”对象而已。JPA 2.0为了弥补JPA1.0的不足,才将这种Query的思想引入为框架中的另一套查询体系——Criteria API。事实上针对单个对象的get/load/persist/save/update/merge/saveOrUpdate API和Criteria API本来就为一体,只不过是历史的原因被人为割裂成为两套
数据库
操作API罢了。 因此,对于关系型
数据库
而言——Entity和Query是一体两面的事物,所谓Query,可以包含各种复杂的查询条件,甚至可以作为一个完整的SQL操作请求的描述。为此,EF彻底将Entity和Query绑在了一起。这种思想,使得—— 开发人员需要编写的类更少。开发人员无需编写其他类来描述复杂的SQL查询条件。也无需编写代码将这些查询条件转换为SQL/HQL/JPQL。DAO层也不会有老要改来改去的接口和API,几乎可以做到零编码。 对单个对象进行CRUD的操作API现在和Criteria API合并在一起。Session对象可以直接提供原本要Criteria API才能提供实现的功能。API大大简化。 IQueryableEntity允许你将一个实体直接变化为一个查询(Query),在很多时候可以用来完成复杂条件下的数据查询。比如 ‘in (?,?,?)’, ‘Between 1 and 10’之类的条件。 xxQL有着拼装语句可读性差、编译器无法检查、变更维护困难等问题,但是却广受开发人员欢迎。这多少有历史原因,也有Criteria API设计上过于复杂的因素。两者一方是极端灵活但维护困难,一方是严谨强大而学习和编写繁琐,两边都是极端。事实上JPA的几种数据查询方式存在青黄不接的问题。选择查询语言xxQL,项目面临后续维护困难,跨
数据库
移植性差;选择Criteria API,代码臃肿,操作繁琐,很多人望而却步。EF的设计思想是使人早日摆脱拼装SQL/HQL/JPQL的困扰,而是用(更精简易用的)Criteria API来操作
数据库
。 基于轻量级Criteria API的操作方式,使得对
数据库
的变更和重构变得非常轻松,解决了SQL语句多对软件维护和移植造成产生的不利影响。 阅读推荐:第3、4章 特点二,将SQL的使用发挥到极致,解决SQL拼凑问题、
数据库
移植问题 大部分OLTP应用系统到最后都不免要使用SQL/JPQL,然而没有一个很好的方法解决SQL在多种
数据库
下兼容性的问题。 EF-ORM中采用了独特的SQL解析和改写技术,能够主动检查并确保SQL语句或者SQL片段在各个
数据库
上的兼容性。 EF中除了Criteria API以外,可以直接使用“SQL语句”或者“SQL片段”。但是这些SQL语句并不是直接传送给JDBC驱动的,而是 有着一个
数据库
方言
层,经过
方言
层处理的SQL语句,就具备了在当前
数据库
上正确操作的能力。这相当于提供了一种能跨
数据库
操作的SQL语言。(E-SQL) E-SQL不但解决了异构
数据库
的语法问题、函数问题、特殊的写法问题,还解决了动态SQL问题、绑定变量扩展等特性。 对于各种常用SQL函数和运算符,都可以自动转换为当前
数据库
支持的
方言
来操作。其函数支持也要多于HQL支持的函数。 阅读推荐:第7、8章 特点三,可能是业界最快的ORM框架. 得益于ASM的动态代码生成技术,部分耗时操作通过动态代码固化为硬编码实现,EF-ORM的大部分操作性能要超过已知的其他框架。 实际性能测试表明,EF的大部分操作都要快于Hiberante和MyBatis, 部分操作速度甚至数十倍于上述框架。 EF在极限插入模式下,甚至刷新了每秒10万条写入的记录。远远超过了其他框架。 一个初步的性能测试:测试代码:http://geequery.github.io/ef-orm/manual/performance-test.rar 测试报告:http://geequery.github.io/ef-orm/manual/performance-compare.docx 阅读推荐:第9、17章 特点四,分库分表 开发过程中参照了
Hibernate
Shards、Alibaba TDDL、Cobar等框架,也是基于词法分析器来提取SQL参数,并计算路由。 能支持分库维度含糊等场景下的分库分表。以及包括多库多表下的 order by , distinct, group by, having等操作。 阅读推荐:第10章 特点五,常用DDL操作的封装 从
数据库
元数据访问,到建表,创建约束,创建sequence等各种DDL操作进行了封装,用户无需编写各种SQL,可以直接通过API操作
数据库
结构。 尤其是ALTER TABLE等修改
数据库
的语句,各种不同的RDBMS都有较大语法差异。特点六、解决各种跨RDBMS的移植问题 1、DML操作、自增值处理与返回、查询这些不同
数据库
操作差异很大的东西,都了统一的封装。 2、DDL操作、建表、删表、trunacte,Sequence创建和TABLE模拟Sequence等,都做了支持。 3、对SQL语法操作和函数的改写与支持。其他特性轻量 该框架对应用环境、
连接
池、 是否为J2EE应用等没有特殊要求。可以和EJB集成,也可与Spring集成,也可以单独使用。整个框架只有两个JAR包,模块和功能都较为轻量。依赖少 整个框架只有三个jar库。间接依赖仅有commons-lang, slf4j等7个通用库,作为一个ORM框架,对第三方依赖极小。简单直接的API 框架的API设计直接面向
数据库
操作,不绕弯子,开发者只需要
数据库
基本知识,不必学习大量新的操作概念即可使用API完成各种DDL/DML操作。 最大限度利用编译器减少编码错误的可能性 API设计和元数据模型(meta-model)的使用,使得常规的
数据库
查询都可以直接通过Criteria API来完成,无需使用任何JPQL/HQL/SQL。可以让避免用户犯一些语法、拼写等错误。JPA2规范兼容 使用JPA 2.0规范的标准注解方式来定义和操作对象。(但整个ORM不是完整的JPA兼容实现)更高的性能 依赖于ASM等静态字节码技术而不是CGlib,使得改善了代理性能;依赖于动态反射框架,内部数据处理上的开销几乎可以忽略。操作性能接近JDBC水平。对比某H开头的框架,在写入操作上大约领先30%,在大量数据读取上领先50%以上。更多的性能调优手段 debug模式下提供了大量性能日志,帮您分析性能瓶颈所在。同时每个查询都可以针对batch、fetchSize、maxResult、缓存、级联操作类型等进行调整和开关,可以将性能调到最优。可在主流
数据库
之间任意切换 支持Oracle、MySQL、Postgres、MSSQL、GBase、SQLite、HSQL、Derby等
数据库
。除了API方式下的操作能兼容各个
数据库
之外,就连SQL的本地化查询也能使之兼容。JMX动态调节 可以用JMX查看框架运行统计。框架的debug开关和其他参数都可以使用JMX动态调整。动态表支持 表结构元数据的API也向用户开放,同时支持在使用过程中,灵活调整映射关系,因此用户可以用API动态的创建表结构的模型,从而实现各种动态类型和表的映射(例如POJO中包含一个Map,用于映射各种动态扩展的字段)企业级特性支持 SQL分析,性能统计,分库分表,Oracle RAC支持,读写分离支持 标签:eform
Hibernate
深入理解----02HelloWorld详解(
Hibernate
.cfg.xml
配置
文件详解,创建持久化对象详解)
参考代码下载github:https://github.com/changwensir/java-ee/
tree
/master/
hibernate
4 1、创建
Hibernate
.cfg.xml
配置
文件 hibernate-configuration PUBLIC "-//
Hibernate
/
Hibernate
Configuration D
【学习笔记-SSH框架】
Hibernate
入门-笔记01-搭建
Hibernate
应用环境及实现增删查改功能、以及Query、Criteria查询
Hibernate
入门-笔记01-搭建
Hibernate
应用环境及实现增删查改功能、以及Query、Criteria查询 目录 使用Maven搭建
Hibernate
项目 自顶向下开发
Hibernate
应用步骤 封装
Hibernate
工具类 实现增删查改功能 使用Query进行HQL查询 使用Criteria进行条件查询 POJO状态 1. 使用Maven搭建
Hibernate
项目 在IDE中创...
为 Cloud Spanner 引入
Hibernate
ORM 以便使用
数据库
文 / Mike Eltsufin,软件工程师Google Cloud 线上课堂5 月 21 日的 Google Cloud 线上课堂,技术工程师郭斌讲带领大家了解企业如何进行
数据库
的选...
第七章
Hibernate
常用
配置
(
hibernate
.cfg.xml)
com.mysql.jdbc.Driver jdbc:mysql://127.0.0.1:3306/
hibernate
root test 20 true
Java EE
67,513
社区成员
225,879
社区内容
发帖
与我相关
我的任务
Java EE
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
复制链接
扫一扫
分享
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章