Hibernate em Oracle e SQLServer

Question

Eu estou introduzindo uma camada DAO em nossa aplicação atualmente trabalhando em SQL Server porque eu preciso transportá-lo para Oracle.

Eu gostaria de usar o Hibernate e escrever uma fábrica (ou o uso de injeção de dependência) para escolher os DAOs corretas de acordo com a configuração de implementação. Quais são as melhores práticas neste caso? Devo ter dois pacotes com diferentes hibernate.cfg.xml e arquivos .hbm.xml * e buscá-las em conformidade, a minha fábrica? Existe alguma chance de que meus DAOs funcionará corretamente com ambos os DBMS sem (muito) aborrecimento?

Answer 1

Assumindo que os nomes de tabelas e colunas são os mesmos entre os dois, você deve ser capaz de usar os mesmos arquivos hbm.xml. No entanto, você certamente precisa fornecer um valor diferente de configuração do Hibernate (hibernate.cfg.xml), pois você vai precisar para mudar dialeto do Hibernate a partir SQLServer para Oracle.

Se houver diferenças de nomes ligeiras entre os dois, então eu iria criar dois conjuntos de arquivos de mapeamento - um por servidor de banco de dados - e empacotá-os para cima em frascos separados (como o yourproject-sqlserver-mappings.jar e yourproject-oracle-mappings.jar), e implementar o aplicativo com um JAR ou o outro dependendo do ambiente.

Answer 2

Eu fiz isso para um cliente um tempo atrás - a implantação, dependendo de um conjunto de propriedades em um arquivo production.properties eu mudei o hibernate.dialect no arquivo cfg usando Ant (você pode usar qualquer transformador xml). No entanto, isto só funcionam se o código Hibernate é perfeita btw tanto DBs ou seja, há chamadas de função específicas do db etc. HQL / JPAQL tem chamadas de função padrão que ajuda ion este respeito como UPPER(s), LENGTH(s) etc.

Se as implementações db deve ser necessariamente diferente, então você teria que fazer algo como o que @ Matt sugeriu.

Answer 3

Eu tenho trabalhado em um aplicativo que suporta uma grande quantidade de bancos de dados (Oracle, Informix, SQL Server, MySQL). Temos um arquivo de configuração e um conjunto de mapeamentos. Usamos jndi para a conexão de banco de dados de modo que não têm de lidar com URLs de conexão diferentes no aplicativo. Quando inicializar o SessionFactory temos um método que deduz o tipo de banco de dados a partir da conexão subjacente. Por exemplo, obter uma conexão manualmente via JNDI e, em seguida, usar connection.getMetaData (). GetDatabaseProductName () para descobrir o que o banco de dados é. Você também pode usar uma variável de ambiente recipiente para defini-la explicitamente. Em seguida, definir o dialeto usando configuration.setProperty (Environment.DIALECT, deducedDialect) e inicializar a SessionFactory como normal.

Algumas coisas que você tem que lidar com:

• geração de chave primária. Nós usamos uma versão personalizada da estratégia TableGenerator por isso temos uma tabela de chave com colunas para o nome da tabela e próxima tecla. Desta forma, cada banco de dados pode usar a mesma estratégia em vez de seqüência no Oracle, nativo para SQL Server, etc.
• funções específicas para bancos de dados. Nós evitá-los quando possível. dialetos Hibernate lidar com as mais comuns. Ocasionalmente nós vamos ter que adicionar o nosso próprio para nossas aulas de dialeto personalizados, .e.g. Data aritmética é bastante diferente do padrão, por isso vamos apenas fazer-se um nome de função e mapeá-lo para o caminho de cada banco de dados de fazê-lo.
geração
• Esquema - usamos a classe geração de esquema Hibernate - ele trabalha com os dialetos para criar o DDL corretas para cada tipo de banco de dados e as forças de banco de dados para coincidir com os mapeamentos. Você tem que estar ciente das palavras-chave para cada banco de dados, por exemplo, não tentar ter uma tabela de usuário no Oracle (USUÁRIOS vai funcionar), ou uma tabela de conversão em MySQL.

Answer 4

Há uma mesa mapear as diferenças entre Oracle e SQLServer aqui: http://psoug.org/ referência / sqlserver.html

Na minha opinião as maiores armadilhas são: 1) Datas. As funções e mecânicos são completamente diferentes. Você terá que usar código diferente para cada DB. 2) Criação de chaves - Oracle e SQLServer usar diferentes mecânicas e se você tentar evitar a geração "nativo" completamente por ter sua própria tabela de chaves - bem, você serializado apenas completamente todos os seus "inserções". Não é bom para o desempenho. 3) simultaneidade / bloqueio é um pouco diferente. Partes do código que é o desempenho sensíveis provavelmente será diferente para cada DB. 4) Oracle é sensível a maiúsculas, SQLServer não é. Você precisa ter cuidado com isso.

Existem muitos mais :) Escrever código SQL que será executado em dois bancos de dados é um desafio. Tornando-o rápido pode parecer quase impossível às vezes.