2008/6/20 Leandro DUTRA [EMAIL PROTECTED]:
2008/6/20 Leonardo Cezar [EMAIL PROTECTED]:
Mesmo que a tradução estivesse incorreta e fosse traduzido para o
termo randômico, estaria certo porque randômico em inglês significa:
falta de ordem ou causa.
Creio que não existe essa palavra em
2008/6/21 Leonardo Cezar [EMAIL PROTECTED]:
2008/6/20 Leandro DUTRA [EMAIL PROTECTED]:
Creio que não existe essa palavra em português.
randômico: Adj. V. aleatório(3). ~ V. amostra.
fonte: Novo Aurélio Século XXI, ISBN: 85-209-1010-6
Hmpf. Mais um empréstimo inútil…
Existe, é
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
2008/6/19 Osvaldo Rosario Kussama [EMAIL PROTECTED]:
E a coisa tem a ver com o índice interno do SGBD, que é o OID, que a cada
update é alterado, alterando a ordem.
Errado. A coisa não tem nada a ver com OIDs de tuplas, porque estes
são estáticos em
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
(...)
Acredito que o texto do manual, e como também relatam em alguns livros,
talvez precise ser mais claro.
Sei que muita gente não procura testar estas coisas, mas o que eu entendi
ao ler foi que ao executar simultâneos selects eu receberia os
2008/6/20 Leonardo Cezar [EMAIL PROTECTED]:
2008/6/20 Ribamar Sousa [EMAIL PROTECTED]:
SELECT foo.CTID,foo.OID,foo.*; -- deve ter movido CTID para bloco 0 e
versão 1 ((0,1));
Aqui acusa que não tenho foo.OID (minha versão? 8.2.9).
A partir da 8.1 a diretiva default_with_oids vem
2008/6/20 William Leite Araújo [EMAIL PROTECTED]:
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
(...)
Acredito que o texto do manual, e como também relatam em alguns livros,
talvez precise ser mais claro.
Sei que muita gente não procura testar estas coisas, mas o que eu entendi
ao ler foi que
2008/6/20 Ribamar Sousa [EMAIL PROTECTED]:
Willian, sem querer ter razão na marra, mas apenas me justificando. Veja o
texto do manual:
Quando a tabela é lida, as linhas aparecem em uma ordem aleatória, a não
ser que a classificação seja requisitada explicitamente.
Mas este longo debate foi
Ribamar Sousa escreveu:
2008/6/20 William Leite Araújo [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
2008/6/19 Ribamar Sousa [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
(...)
Acredito que o texto do manual, e como também relatam em alguns
livros, talvez
2008/6/20 Osvaldo Rosario Kussama [EMAIL PROTECTED]:
Ribamar Sousa escreveu:
Uma tabela em um banco de dados relacional é muito semelhante a uma
tabela no papel: é formada por linhas e colunas. O número e a ordem das
colunas são fixos, e cada coluna possui um nome. O número de linhas é
2008/6/20 Leonardo Cezar [EMAIL PROTECTED]:
Mesmo que a tradução estivesse incorreta e fosse traduzido para o
termo randômico, estaria certo porque randômico em inglês significa:
falta de ordem ou causa.
Creio que não existe essa palavra em português.
Aliás, existe aleatório em inglês?
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o SQL não
garante a ordem em que os registros são retornados pelas consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
...
5.1. Noções básicas de tabela Uma tabela em um banco de dados relacional é
muito
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
Já li em alguns livros e agora na documentação do PostgreSQL, que o SQL não
garante a ordem em que os registros são retornados pelas consultas.
[corte]
Eu fui testar mas não consegui reproduzir esse comportamento.
Quer a tabela tenha chave primária
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o
SQL não garante a ordem em que os registros são retornados pelas
consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
...
Uma tabela em um banco de dados relacional é muito
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o
SQL não garante a ordem em que os registros são retornados pelas
consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
...
Eu não faço idéia onde você quis chegar com isso,
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
Já li em alguns livros e agora na documentação do PostgreSQL, que o SQL não
garante a ordem em que os registros são retornados pelas consultas.
[...]
Eu fui testar mas não consegui reproduzir esse comportamento.
Nesse caso eu diria que a documentação
So para lembra que o comando do UPDATE correto e este aqui :
UPDATE foo SET bar = 0 where bar = 10 OR bar = 1;
isto para o exemplo do Leonardo.
Em 19/06/08, Osvaldo Rosario Kussama [EMAIL PROTECTED] escreveu:
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação
So para lembra que o comando do UPDATE correto e este aqui :
UPDATE foo SET bar = 0 where bar = 10 OR bar = 1;
isto para o exemplo do Leonardo.
Em 19/06/08, Osvaldo Rosario Kussama [EMAIL PROTECTED] escreveu:
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação
2008/6/19 Leonardo Cezar [EMAIL PROTECTED]:
2008/6/19 Ribamar Sousa [EMAIL PROTECTED]:
Já li em alguns livros e agora na documentação do PostgreSQL, que o SQL
não
garante a ordem em que os registros são retornados pelas consultas.
# CREATE TABLE foo(bar int);
# INSERT INTO foo
2008/6/19 Osvaldo Rosario Kussama [EMAIL PROTECTED]:
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o SQL
não garante a ordem em que os registros são retornados pelas consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
] Ordem dos registros nas tabelas
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o
SQL não garante a ordem em que os registros são retornados pelas
consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
...
Uma tabela em um
2008/6/19 Leandro Damascena [EMAIL PROTECTED]:
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que o
SQL não garante a ordem em que os registros são retornados pelas
consultas.
http://pgdocptbr.sourceforge.net/pg80/ddl.html#DDL-BASICS
Ribamar Sousa escreveu:
2008/6/19 Osvaldo Rosario Kussama [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Ribamar Sousa escreveu:
Olá!
Já li em alguns livros e agora na documentação do PostgreSQL, que
o SQL
não garante a ordem em que os registros são
2008/6/19 Osvaldo Rosario Kussama [EMAIL PROTECTED]:
Exato, qualquer atualização ou um vacuum full podem modificar a ordem
física dos registros. Em um ambiente onde ocorrem transações
simultâneas é quase como se fosse aleatório, na realidade não é
aleatório mas é praticamente impossível
Galera, essa situação eu pude presenciar em um sistema em produção com
grande acesso e modificações aos dados:
1) independente da quantidade de selects, os dados virão sempre da mesma
forma em que se encontram na base, ou seja, sem alterar sua ordem.
1.1) Qualquer procedimento de manutenção nos
24 matches
Mail list logo
