MySQL To DerbyDB: mudanças entre as edições
Sem resumo de edição |
|||
(4 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 15: | Linha 15: | ||
|CREATE TABLE pdvlocal_locationcountry ''(...)'' | |CREATE TABLE pdvlocal_locationcountry ''(...)'' | ||
|}</center> | |}</center> | ||
=== Add Column "After" === | |||
O DerbyDB até o momento não suporta a função de definir a posição da nova coluna durante o ALTER TABLE. | |||
Mesmo que seja conveniente visualmente definir onde queremos adicionar a nova coluna na tabela, o código da aplicação nunca deve usar o índice da coluna como referência. | |||
=== Auto Increment === | === Auto Increment === | ||
Linha 78: | Linha 83: | ||
|? | |? | ||
|CREATE INDEX fk_pdvlocal_locationstate_pdvlocal_locationcountry1_idx ON pdvlocal_locationstate(idpdvlocal_locationcountry); | |CREATE INDEX fk_pdvlocal_locationstate_pdvlocal_locationcountry1_idx ON pdvlocal_locationstate(idpdvlocal_locationcountry); | ||
|}</center> | |||
=== ALTER TABLE - CHANGE COLUMN === | |||
O DerbyDB não tem o comando CHANGE COLUMN, em compensação tem o comando ALTER COLUMN. Porém seu funcionamento é um pouco diferente dependendo da alteração que se deseja fazer: | |||
<center> | |||
{| class="wikitable" style="width:80%;" | |||
!scope="col" style="width:50%;"|MySQL | |||
!scope="col" style="width:50%;"|DerbyDB | |||
|- | |||
|Trocat o tipo de dados (ou mesmo o tamanho) | |||
|Para alterar o tipo de dados ou o tamanho devemos usar o comando '''SET DATA TYPE''' e em seguida a nova especificação da coluna. Não esquecer de incluir o '''NOT NULL''', caso contrário o campo passará a ser '''NULL'''. | |||
Ex: ''ALTER TABLE pdvlocal_cupom ALTER COLUMN sefazxmotivo SET DATA TYPE VARCHAR(255);'' | |||
|}</center> | |}</center> | ||
Linha 96: | Linha 115: | ||
|'''[http://db.apache.org/derby/docs/10.1/ref/rrefsqlj16221.html#rrefsqlj16221 SMALLINT]''' | |'''[http://db.apache.org/derby/docs/10.1/ref/rrefsqlj16221.html#rrefsqlj16221 SMALLINT]''' | ||
|O menor campo pra INT do DerbyDB é o SMALLINT, que usa 2 bytes. Mesmo que o TINYINT do MySQL só use 1 byte, não há campo igual no DerbyDB. O que melhor substitui é o SMALLINT, mesmo sendo de maior capacidade. | |O menor campo pra INT do DerbyDB é o SMALLINT, que usa 2 bytes. Mesmo que o TINYINT do MySQL só use 1 byte, não há campo igual no DerbyDB. O que melhor substitui é o SMALLINT, mesmo sendo de maior capacidade. | ||
|- | |||
|'''[https://dev.mysql.com/doc/refman/5.0/en/binary-varbinary.html BINARY(?)]''' | |||
|'''[https://db.apache.org/derby/docs/10.0/manuals/reference/sqlj145.html#VARCHAR+FOR+BIT+DATA VARCHAR(?) FOR BIT DATA]''' | |||
|Para armazenar uma quantidade pequena de bytes o MySQL utiliza o '''BINARY(X)''', onde x é o tamanho em bytes do dado a ser armazenado. A declaração equivalente no DerbyDB é utilizar o '''VARCHAR(X) FOR BIT DATA''', onde X representa o mesmo tamanho definido para o MySQL. O tamanho máximo permitido no DerbyDB é de 32,672 bytes. | |||
|- | |||
|'''[https://dev.mysql.com/doc/refman/5.5/en/integer-types.html TINYINT(1)]''' ou '''BOOLEAN''' | |||
|'''[http://db.apache.org/derby/docs/10.7/ref/rrefsqljBoolean.html BOOLEAN]''' | |||
|No MySQL o TINYINT(1) e o BOOLEAN são exatamente as mesmas coisas, no DerbyDB o jeito para declarar um boolean segue sendo BOOLEAN. | |||
|}</center> | |||
== Outros Comandos Derby == | |||
=== Exportar os dados para arquivo === | |||
O Derby DB tem alguns comandos internos que permitem a exportação dos dados. Esse abaixo permite que uma tabela seja exportada em CSV. Atenção para os nomes dos schemas e tabelas que são '''Case Sensitive'''. | |||
<code>CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE('BISERP', 'PDVLOCAL_REDUCAOZLOG', 'arquivo.csv', null, null, 'UTF-8');</code> |
Edição atual tal como às 13h37min de 27 de fevereiro de 2016
Este tópico sintetiza as diferenças de comandos e outros detalhes entre o MySQL e o DerbyDB (JavaDB). O principal propósito é criar um guia de referência para facilitar a migração entre os bancos já que o modelo é todo feito no MySQL Workbench (que utiliza o MySQL como referência), e algumas aplicações como o BISPDV utiliza o DerbyDB como banco local.
Diferenças de Syntaxe SQL
Nomes de Tabelas e Campos
O MySQL costuma envolver o nome de colunas, tabelas e schemas entre crases (´´), como se fossem aspas. O que o impede de confundir as tabelas/colunas com palavras da sintaxe como "index", "update", "from", etc.. O Derby não suporta as crases, sendo obrigatória e remoção de todas. Assim não resta outra maneira além de não utilizar palavras reservadas da sintaxe SQL como nome de tabelas e colunas.
MySQL | DerbyDB |
---|---|
CREATE TABLE `pdvlocal_locationcountry` (...) | CREATE TABLE pdvlocal_locationcountry (...) |
Add Column "After"
O DerbyDB até o momento não suporta a função de definir a posição da nova coluna durante o ALTER TABLE.
Mesmo que seja conveniente visualmente definir onde queremos adicionar a nova coluna na tabela, o código da aplicação nunca deve usar o índice da coluna como referência.
Auto Increment
MySQL | DerbyDB |
---|---|
AUTO_INCREMENT | GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1) |
Null / Not Null
O DerbyDB não suporta a sintaxe "NULL" como o MySQL. Por padrão o DerbyDB já tem os campos NULL, assim quando o campo aceitar NULL não se deve especificar.
MySQL | DerbyDB |
---|---|
`bacencode` VARCHAR(5) NULL | bacencode VARCHAR(5) |
`bacencode` VARCHAR(5) NOT NULL | bacencode VARCHAR(5) NOT NULL |
ON UPDATE/DELETE CASCADE
O DerbyDB não suporta a expressão 'CASCADE'. A forma correta de obter o mesmo efeito no DerbyDB é com a expressão 'NO ACTION'.
MySQL | DerbyDB |
---|---|
ON UPDATE CASCADE | ON UPDATE NO ACTION |
CREATE TABLE
Diferenças entre o comando CREATE TABLE no MySQL e no DerbyDB
Diferença | Descrição |
---|---|
Índice para FK | Ao criar uma tabela com ForeignKeys o MySQL Workbench cria uma linha no script de criação da tabela para criar o índice para a FK. O DerbyDB não precisa da criação explícita de índices para FK, ele cria automaticamente. Por isso essa linha deve ser removida; |
IF NOT EXISTS | O DerbyDB não suporta a sintaxe de 'IF NOT EXISTS' no CREATE TABLE, essa expressão deve sempre ser removida. |
CREATE INDEX
Para criar um índice auxiliar em alguma tabela use a seguinte sintaxe:
MySQL | DerbyDB |
---|---|
? | CREATE INDEX fk_pdvlocal_locationstate_pdvlocal_locationcountry1_idx ON pdvlocal_locationstate(idpdvlocal_locationcountry); |
ALTER TABLE - CHANGE COLUMN
O DerbyDB não tem o comando CHANGE COLUMN, em compensação tem o comando ALTER COLUMN. Porém seu funcionamento é um pouco diferente dependendo da alteração que se deseja fazer:
MySQL | DerbyDB |
---|---|
Trocat o tipo de dados (ou mesmo o tamanho) | Para alterar o tipo de dados ou o tamanho devemos usar o comando SET DATA TYPE e em seguida a nova especificação da coluna. Não esquecer de incluir o NOT NULL, caso contrário o campo passará a ser NULL.
Ex: ALTER TABLE pdvlocal_cupom ALTER COLUMN sefazxmotivo SET DATA TYPE VARCHAR(255); |
Relação entre Tipos de Dados
Para representar os mesmos tipos de dados há algumas diferenças entre os bancos de dados. Mesmo tipos que tem o mesmo nome podem ter escopos e dimensões diferentes.
MySQL | DerbyDB | Detalhes |
---|---|---|
DATETIME | TIMESTAMP | Para guardar data + tempo no Derby é obrigatório utilizar o formato TIMESTAMP. |
TINYINT | SMALLINT | O menor campo pra INT do DerbyDB é o SMALLINT, que usa 2 bytes. Mesmo que o TINYINT do MySQL só use 1 byte, não há campo igual no DerbyDB. O que melhor substitui é o SMALLINT, mesmo sendo de maior capacidade. |
BINARY(?) | VARCHAR(?) FOR BIT DATA | Para armazenar uma quantidade pequena de bytes o MySQL utiliza o BINARY(X), onde x é o tamanho em bytes do dado a ser armazenado. A declaração equivalente no DerbyDB é utilizar o VARCHAR(X) FOR BIT DATA, onde X representa o mesmo tamanho definido para o MySQL. O tamanho máximo permitido no DerbyDB é de 32,672 bytes. |
TINYINT(1) ou BOOLEAN | BOOLEAN | No MySQL o TINYINT(1) e o BOOLEAN são exatamente as mesmas coisas, no DerbyDB o jeito para declarar um boolean segue sendo BOOLEAN. |
Outros Comandos Derby
Exportar os dados para arquivo
O Derby DB tem alguns comandos internos que permitem a exportação dos dados. Esse abaixo permite que uma tabela seja exportada em CSV. Atenção para os nomes dos schemas e tabelas que são Case Sensitive.
CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE('BISERP', 'PDVLOCAL_REDUCAOZLOG', 'arquivo.csv', null, null, 'UTF-8');