Tipos de dados da série de treinamento de dados Shanghai Tengke Education Dameng: Dameng 6.0

Há poucos dias, o editor-chefe Xiong Jianguo do ITPUB me contatou, esperando que eu pudesse participar das atividades aplicáveis ​​à base de dados doméstica Dameng e escrever alguns artigos sobre como utilizá-la. Recentemente, houve muitas coisas manuais e planejei recusar, mas o editor Xiong repetidamente convidou e enfatizou que não é um artigo de pistoleiro, contanto que você escreva a experiência real. Nesse caso, vou escrever algumas experiências experimentais com base no princípio de suporte a bancos de dados domésticos.


  Como o único banco de dados com o qual estou familiarizado é o Oracle, todas as comparações são feitas com o banco de dados Oracle.Neste processo, tentarei ao máximo evitar o amor pelo banco de dados Oracle e me esforçarei para estar em uma posição justa. Faça uma avaliação.

  Este artigo apresenta brevemente os tipos de dados fornecidos pelo banco de dados Dameng.

  Faça login no banco de dados Dameng:


C: \ dmdbms \ bin> isql
isql V6.0.2.51-Build (2009.12.23)
SQL>
nome do servidor de login : localhost
nome de usuário:
senha de teste :
porta: 12345
dm_login tempo usado: 190,370 (ms)


  Primeiro, olhe para os tipos de caracteres CHAR e VARCHAR:


SQL> criar tabela t_type
2 (número de id, nome varchar2 (30));
criar tabela t_type
(número de id, nome varchar2 (30));
tempo usado: 436,197 (ms) tique do relógio: 729306570.
SQL> criar tabela t_char (col char (8000));
criar tabela t_char (col char (8000));
列 定义 长度 超长. código de erro = -1334
SQL> criar tabela t_char (col char (4000));
criar tabela t_char (col char (4000));
列 定义 长度 超长. código de erro = -1334
SQL> criar tabela t_char (col char (3000));
criar tabela t_char (col char (3000));
tempo usado: 20,943 (ms) tique do relógio: 35001630.


  Para ser compatível com os tipos de caracteres do Oracle, Dameng oferece suporte a VARCHAR2, um tipo especial de Oracle. Ao contrário do Oracle, o comprimento máximo do tipo CHAR e do tipo VARCHAR é 8188, mas este valor não é fixo. Quando o tamanho da página do banco de dados é diferente, o valor máximo também não é fixo, como tamanho de página 32K, tipo de caractere CHAR Ou o valor máximo de VARCHAR é 8188 e, se for um tamanho de página de 16K, o tipo de caractere máximo é 8000. Para o tamanho de página atual de 8K, o tipo máximo de caractere é apenas 3900 e se o tamanho da página for 4K, o tipo máximo de caractere é apenas 1900 .


  Para o banco de dados Oracle, o valor máximo do tipo CHAR é 2000 e VARCHAR2 é 4000. Embora o banco de dados Dameng seja maior do que esse intervalo na maioria dos casos, não acho que este seja um bom design. A migração de diferentes bancos de dados antes é muito comum para um sistema maduro, e o tamanho da página de diferentes bancos de dados também é muito comum.Este design de Dameng torna o valor máximo de diferentes páginas o maior possível, mas dá diferentes páginas. A migração do inter-banco de dados plantou o problema. Quando o banco de dados é migrado para um banco de dados de página maior, não haverá problema, mas ao contrário, pode fazer com que a tabela não possa ser criada, os dados sejam perdidos ou os dados sejam truncados. E eu sinto que o banco de dados Dameng ainda tem alguns problemas ao implementar o tipo VARCHAR:


SQL> inserir em valores t_type (1, 'a');
inserir em valores t_type (1, 'a')
1 linhas afetadas
tempo usado: 0,464 (ms) tique do relógio: 765250.
SQL> selecione id, nome || 'a' de t_type;
selecione id, nome || 'a' de t_type;
id
1 1 aa
1 linhas obtidas


  Até o momento não há problema, os espaços no tipo VARCHAR são reservados, mas ao consultar o tipo VARCHAR:


SQL> selecione * de t_type onde nome = 'a';
selecione * de t_type onde nome = 'a';
nome de id
1 1 a
1 linhas têm
tempo de uso: 29,588 (ms) tique do relógio: 49459510.
SQL> selecione * de t_type onde nome = 'a';
selecione * de t_type onde nome = 'a';
nome de id
1 1 a
1 linhas tem
tempo usado: 0,314 (ms) tique do relógio: 517060.
SQL> selecione * de t_type onde nome = 'a';
selecione * de t_type onde nome = 'a';
nome de id
1 1 a
1 linhas tem
tempo usado: 0,421 (ms) tique do relógio: 694830.


  Obviamente, na comparação, os espaços não são levados em consideração, o que não é problema para o tipo CHAR, mas o tipo VARCHAR não parece ter tais características:


SQL> inserir em valores t_type (2, 'a');
inserir em valores t_type (2, 'a')
1 linhas afetadas
tempo usado: 0,401 (ms) tique do relógio: 661320.
SQL> selecione * de t_type
2 onde nome = 'a';
selecione * de t_type
onde nome = 'a';
nome de id
1 1 a
2 2 a
2 linhas
tempo usado: 0,397 (ms) tique do relógio: 653730.
SQL> alterar tabela t_type adiciona chave primária (nome);
alterar tabela t_type adicionar chave primária (nome);
违反 唯一 性 约束. código de erro = -3100


  Obviamente, em Dameng, mesmo os campos do tipo VARCHAR pensam que 'a' e 'a_' (aqui use sublinhados para identificar espaços) são iguais. Esta situação levará à ambigüidade. Achamos que os dados que já são iguais após o mesmo processamento Se tornará desigual novamente:


SQL> selecione id, nome || 'a' de t_type;
selecione id, nome || 'a' de t_type;
id
1 1 aa
2 2 aa
2 linhas obteve
tempo usado: 36.391 (ms) tique do relógio: 60834180.


  Vejamos os tipos numéricos:


SQL> criar tabela t_num
2 (número c1, número
3 c2 (4, 1),
número 4 c3 (4, -1),
número 5 c4 (2, 3));
第 4 行: '-' 附近 有 语法 错误
SQL> criar tabela t_num
2 (número c1, número
3 c2 (4, 1),
número 4 c4 (2, 3));
criar tabela t_num
(número c1, número
c2 (4, 1),
número c4 (2, 3));
无效 的 数据 类型. código de erro = -2520
SQL> criar tabela t_num
2 (número c1,
3 número c2 (4, 1));
criar tabela t_num
(número c1,
número c2 (4, 1));
tempo usado: 42,803 (ms) tique do relógio: 71554500.


  Embora Dameng suporte o tipo numérico NUMBER e o tipo NUMBER do Oracle sejam muito semelhantes, ainda há diferenças entre os dois. Obviamente, Dameng não suporta o caso em que a escala é menor que 0 e não suporta o caso em que a precisão é menor que a escala, e essas situações são no Oracle Ambos são suportados, o seguinte é a situação no Oracle:


SQL> criar tabela t_num
  2 (número c1, número
  3 c2 (4, 1),
  número 4 c3 (4, -1),
  número 5 c4 (2, 3)); A
tabela foi criada.
SQL> insert into t_num
  2 values ​​(1, 234.4, 3225, 0.023);
1 linha foi criada.
SQL> selecione * de t_num;
       C1 C2 C3 C4
---------- ---------- ---------- --------- -
        1 234,4 3230,023


  Embora o tipo NUMBER e o tipo NUMBER do Oracle não sejam exatamente iguais, suas descrições de precisão e escala ainda são consistentes. No entanto, se o Oracle não especificar a precisão de NUMBER, o padrão é 38 e, em Dameng, o padrão é 20.


SQL> inserir em valores t_num
2 (1234567890123456789012, 123.1);
inserir em valores t_num
(1234567890123456789012, 123,1)
数据 溢出. código de erro = -2502
SQL> criar tabela t_num2
2 (número c1 (*, 0));


  Linha 2: há um erro gramatical próximo a '*'. Além disso, Dameng não oferece suporte a NUMBER (*, 0). Dameng, como SQLSERVER, SYBASE e outros bancos de dados, implementa colunas de incremento automático para tipos de dados que representam inteiros:


SQL> CREATE TABLE T_INC
2 (ID NUMBER (5, 0) IDENTITY (1, 2),
3 NAME VARCHAR);
CRIAR TABELA T_INC
(NÚMERO DE ID (5, 0) IDENTIDADE (1, 2),
NOME VARCHAR);
tempo usado: 15,516 (ms) tique do relógio: 25924810.
SQL> INSERT INTO T_INC (NAME)
2 VALUES ('A');
INSERT INTO T_INC (NAME)
VALUES ('A')
1 linhas afetadas
tempo usado: 36,438 (ms) tique do relógio: 60908390.
SQL> INSERT INTO T_INC (NAME)
2 VALUES ('B');
INSERT INTO T_INC (NAME)
VALUES ('B')
1 linhas afetadas
tempo usado: 0,655 (ms) tique do relógio: 1082480.
SQL> SELECT * FROM T_INC;
SELECT * FROM T_INC;


2 3 B
2 linhas tiveram o
tempo usado: 1,769 (ms) tique do relógio: 2943530.


  Em seguida, observe o tipo de tempo do banco de dados Dameng:


SQL> criar tabela t_date
2 (dia data, hora tim, o_date data e hora);
criar tabela t_date
(dia data, hora tim, o_date data e hora);
tempo usado: 60,083 (ms) tique do relógio: 100448590.
SQL> insert into t_date
2 values ​​('2010-04-01', '16: 22: 57 ', to_date (' 2010-4-1 16:22:57 ',' aaaa-mm-dd h
h24: mi: ss '));
inserir em
valores t_date ('2010-04-01', '16: 22: 57 ', to_date (' 2010-4-1 16:22:57 ',' aaaa-mm-dd hh24:
mi: ss '))
1 linha afetada,
tempo usado: 56,728 (ms) tique do relógio: 94839380.
SQL> selecione * de t_date;
select * from t_date;
day tim o_date
1 2010-04-01 16: 22: 57.000000 2010-04-01 16:22:

tempo usado: 0,501 (ms) tique do relógio: 828690.


  O DATE no banco de dados Dameng é essencialmente diferente do DATE no Oracle, que parece ser semelhante ao tipo DATE no SQLSERVER. Ele divide a data e a hora em duas partes, correspondendo a dois tipos diferentes de DATA e HORA. A precisão de DATA é apenas para dias e a precisão de HORA é para milissegundos. Também existe um tipo de dado DATETIME em Dameng que inclui ano, mês, dia e hora, minuto e segundo, ou seja, tipo TIMESTAMP. No entanto, esse tipo é diferente de DATE do Oracle. Ele contém informações em milissegundos e é mais semelhante ao tipo TIMESTAMP do Oracle. No entanto, o TIMESTAMP do Oracle não só oferece suporte a microssegundos, mas também contém informações de fuso horário. Há outro ponto que não é compatível com o tipo de hora de Dameng, a data AC:


SQL> inserir em valores t_date
2 (dia) ('-235-4-1');
inserir em valores t_date
(dia) ('-235-4-1')
Data ilegal e tipo de dados de hora. Código de erro = -2519
SQL> inserir em t_date
2 (o_date) valores (to_date ('- 235-4-1', 'syyyy-mm-dd'));
inserir em t_date
(o_date) valores (to_date ('- 235-4-1' , 'syyyy-mm-dd'))
máscara de formato de hora inválida. código de erro = -2528


  Dameng suporta uma variedade de tipos de tempo INTERVAL.Embora os tipos fornecidos sejam muito mais do que aqueles fornecidos pela Oracle, essencialmente não há novos tipos adicionais adicionados. Uma coisa a se notar é que depois de subtrair os dois tipos de datas do Oracle, o valor obtido é um valor do tipo NUMBER, que representa o número de dias entre as duas datas, e o tipo INTERVAL obtido por Dameng. A seguir, apresentamos brevemente o tipo de campo grande, que é chamado de tipo multimídia no banco de dados Dameng:


SQL> criar tabela t_text
2 (texto c1, blob c2, clob c3);
criar tabela t_text
(texto c1, blob c2, clob c3);
tempo usado: 139,863 (ms) tique do relógio: 233839160.


  O tipo TEXT é semelhante a LONG no Oracle, mas não tem tantas restrições quanto LONG. O comprimento máximo de TEXT, BLOB e CLOB é 2G-1, que é equivalente ao comprimento do campo LONG do Oracle, que tem metade do comprimento de BLOB e CLOB em 8i. Não há nenhum tipo de dados correspondente a BFILE no banco de dados Dameng. Dameng também fornece tipos BOOLEAN que o Oracle não suporta em tipos SQL:


SQL> criar tabela t_bool
2 (col boolean);
criar tabela t_bool
(col boolean);
tempo usado: 66,991 (ms) tique do relógio: 111995500.
SQL> inserir em valores t_bool (verdadeiro);
inserir em valores t_bool (verdadeiro)
1 linhas afetadas
tempo usado: 0,538 (ms) tique do relógio: 889960.
SQL> inserir em valores t_bool (0);
inserir em valores t_bool (0)
1 linhas afetadas
tempo usado: 0,393 (ms) tique do relógio: 647120.
SQL> inserir em valores t_bool (nulo);
inserir em valores t_bool (nulo)
1 linhas afetadas
tempo usado: 0,337 (ms) tique do relógio: 555060.
SQL> selecione * de t_bool;
select * from t_bool;
col
1 1
2 0
3 NULL
3 linhas têm
tempo usado: 37,112 (ms) tique do relógio: 62038100.
SQL> selecione * de t_bool onde col & 0 = 0;
selecione * de t_bool onde col & 0 = 0;
col
1 1
2 0
2 linhas com
tempo usado: 22,225 (ms) tique do relógio: 37149920.
SQL> selecione * from t_bool onde col | 1 = 1;
select * from t_bool where col | 1 = 1;
col
1 1
2 0
2 linhas obteve o
tempo usado: 14,423 (ms) tique do relógio: 24106790.


  Pode-se ver que o julgamento da lógica booleana do banco de dados Dameng para NULL é diferente daquele no Oracle. No Oracle, NULL & 0 resulta em FALSE, e NULL | 1 resulta em TRUE. Em Dameng, o resultado de qualquer operação booleana em NULL ainda é NULL. Além disso, o banco de dados Dameng fornece muitas funções convenientes para operações de bits, como AND bit a bit, OR bit a bit, XOR, etc. As operações bit a bit são de fato muito mais abrangentes do que as fornecidas pela Oracle.

Acho que você gosta

Origin blog.csdn.net/qq_42726883/article/details/108629454
Recomendado
Clasificación