Fórum Recuperacao exatamente como inserido #27775

Não sei se você já foi questionado sobre isso antes como eu já fui. Os dados serão recuperados e mostrados na mesma ORDEM que estão sendo inseridos? A resposta foi pode ser que NÃO. Bem, meu encarregado adivinha de tecnologias de gerenciamento de tabelas como Dbase, Paradox... onde os dados são inseridos seqüencialmente, logo ele não assimilou muito bem aquela noticia que acabou de ter. O que ele esperava era que Sistemas Gerenciais de Banco de Dados Relacionais (SGDBR’s) se comportassem da mesma forma no que diz respeito à armazenamento físico! Hummmmmm, não é bem assim!

Ferramentas como o Oracle, Interbase, por exemplo, trabalham com o conceito distintos, ou seja, são Bases Relacionais.

Então a grande diferença esta no conceito, veja só, enquanto uma tabela Dbase não passa de um arquivo físico onde os dados são inseridos seqüencialmente, no Oracle tabelas são relações!

Relações é um conceito advindo de teoria dos conjuntos. Uma tabela não deixa de possuir conjunto de dados contudo ela ainda é uma relação.Bem vamos deixar isso de lado pois isso é um LONGO assunto e vamos à parte que interessa.

Onde quero chegar, quero chegar no seguinte ponto. Se eu disse que os dados em SGDBRs são tratados de forma distinta quero dizer que:

Dada uma rotina de venda (um pedido por exemplo), quando você começa a selecionar os itens que farão parte deste pedido a não ser que você forneça uma forma de recuperação dos dados na ordem como estão sendo inseridos não há como garantir que da próxima vez que você abrir este pedido em tela os dados sejam trazidos(no grid, p.ex) na mesma ordem como você os inseriu (os ítens).

Tudo depende da seguinte compreensão. Podemos dizer que o definição abaixo é verdadeira ou falsa?
Dados os seguinte conjuntos:
P={A,B,C}
P’={A,C,B}
P=P&8217; 

Tendo a seguinte definição
A=B ó (Qualquer x)(x pertence A ó x pertence B)
Posso afirmar que sim, é verdadeira.

Bem, no que isso implica?
Implica que se você tem o pedido número 1 formado pelos itens A,B,C o que impede que após gravado desta forma ao abri-lo novamente para consulta ele traga agrupado da forma como no conjunto P&8217; ? Absolutamente nada pois tudo ainda é igual, apenas mudou a ordem de apresentação, o &8220;ajuntamento das coisas&8221;!

Não sei vocês mas eu já passei por isso antes. Após o cupom fiscal ser impresso e os dados aparecerem no papel em uma certa ordem em tela numa re-consulta eles eram mostrados de forma diferente à impressa e originalmente inserida! Esta errado? NÃO, você que não perdeu tempo o suficiente analisando que problemas como este poderiam e VÃO ocorrer, cedo ou tarde.

Como solucionar isso?
Simples, basta criar uma coluna, por exemplo, nomeada de seqüência e à cada item inserido você atribui à esta coluna um valor seqüencial. Quando recuperar  os dados não se esqueça de traze-los ordenados por esta seqüência (order by sequencia).

Bem, vamos à um exemplo prático para compreendermos melhor o assunto. Para tal vou usar o Oracle como ferramenta. Cabe ressaltar que cada gerenciador de base de dados relacional tem seus critérios específicos de armazenamento contudo isso não quer dizer que só ocorre isso no oracle. Estou usando ele para o teste pois só tenho ele como ferramenta.

O que pretendo mostrar aqui é como isso é essa realidade.
Criarei uma tabela bem simples e acrescentarei 4 registros e apagarei 1 e darei um select nela para mostrar o conteúdo, simples né?
Vamos lá.

SYSTEM@BANCO1>create table t
  2  (a int,
  3  b varchar2(4000) default rpad(´*´,4000,´*´),
  4  c varchar2(3000) default rpad(´*´,3000,´*´)
  5  )
  6  /
Tabela criada.
Decorrido: 00:00:00.00

O que estou fazendo acima é criar uma tabela onde cada registro caiba exatamente num bloco de armazenagem física do Oracle (para quem não sabe exatamente o que isso representa vai ai uma explicação bem rápida. Um bloco é a menor área de armazenagem FÍSICA que o oracle usa. É onde os dados são gravados físicamente). Por que estou usando assim, é preciso usar um bloco todo? Não apenas estou tirando proveito disso mas não é obrigatório. Fica mais RÁPIDO ASSIM, com apenas 4 linhas posso mostrar os resultados desejados.

O que faço abaixo é inserir 3 registros, apagar 1 deles e inserir outro.

SYSTEM@BANCO1>insert into t(a) values(1);
1 linha criada.
Decorrido: 00:00:00.70

SYSTEM@BANCO1>insert into t(a) values(2);
1 linha criada.
Decorrido: 00:00:00.70

SYSTEM@BANCO1>insert into t(a) values(3);
1 linha criada.
Decorrido: 00:00:00.10

SYSTEM@BANCO1>delete from t where a=2;
1 linha deletada.
Decorrido: 00:00:00.00

SYSTEM@BANCO1>insert into t(a) values(4);
1 linha criada.
Decorrido: 00:00:00.50

Simples certo? Bem e agora? Agora vamos dar um select na coluna “a&8221; e ver o que ela traz para nós? TEORICAMENTE o que ela deveria trazer? Deixa eu responder...1,3,4 certo? Certo, contudo...

SYSTEM@BANCO1>select a from t;

         A
----------
         1
         4
         3

Decorrido: 00:00:00.00

... hehehe, estão vendo, não é bem assim que ocorre.

Agora você imagine se seu copum fiscal sai com os itens na ordem 1,3 e 4, o cliente vai até a porta, lembrasse que precisa de uma nota fiscal  da mesma e retorna até você e te comunica do fato. Você gentilmente pede que ele espere, importa o cupom para dentro de sua rotina de emissão de nota fiscal que irá converter este cupom numa nota fiscal e ao trazer os dados e imprimir a nota, nela saem os dados na ordem 1,4 e 3? Bem, no mínimo esquisito não é?

Você pode tentar testar isso no Interbase ou outro banco de dados, contudo esteja atento com os critérios de armazenamento dele. O Oracle tem vários, o mais baixo é o tamanho do Bloco que pode e vai influenciar na recuperação dos dados. O Interbase e outros Bancos tem os seus próprios métodos. Esteja atento pois situações como esta podem e uma hora vão ocorrer especialmente se seus dados não estiverem organizados fisicamente próximos.

Abraço à todos. Assim que possível um outro testinho (View x Materilized View ,Binding, tabelas organizadas por índice, Bulk-Collection, Casar-se com o BD? Pq não!? ).

Qualquer coisa sobre o assunto, podem entrar em contato.
Abraço.


Ricardo Francisco de Pierre Satin
Bacharel em Informática – UEM &8211; Maringá/PR
Pós Graduando em Desenvolvimento em Java. &8211; CESUMAR &8211; Maringá/PR