MySQL To DerbyDB: mudanças entre as edições
Sem resumo de edição |
|||
Linha 96: | Linha 96: | ||
|'''[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. | |||
|}</center> | |}</center> |
Edição das 23h27min de 21 de maio de 2015
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 (...) |
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); |
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. |