Fórum Sub-query nao funciona no Interbase?? #44926
17/06/2004
0
SELECT X,Y,Z FROM
(SELECT A,B,C FROM TABELA)
Aliás, notei que só consigo usar sub-query na cláusula WHERE, como:
SELECT * FROM TABELA
WHERE EXITS (SELECT A,B,C FROM TABELA2) etc etc
Mas o problema é que tenho uma UNION com 3 tabelas e preciso ordená-la por um dos campos, mas como fazer isso no Interbase? No Oracle, SQL Server ou DB2 eu uso:
SELECT X,Y,Z FROM (
SELECT X,Y,Z FROM TABELA1
UNION ALL
SELECT X,Y,Z FROM TABELA2
UNION ALL
SELECT X,Y,Z FROM TABELA3 ) AS T
ORDER BY X
No Interbase nao funciona, faço apenas as UNION como abaixo, mas sai tudo fora de ordem:
SELECT X,Y,Z FROM TABELA1
UNION ALL
SELECT X,Y,Z FROM TABELA2
UNION ALL
SELECT X,Y,Z FROM TABELA3
O que fazer?
Skyzytuz
Curtir tópico
+ 0Posts
17/06/2004
Gandalf.nho
Gostei + 0
18/06/2004
Skyzytuz
Só que eu não queria ´poluir´ o banco com dezenas de views, visto que faço amplo uso sub-queryes em diversos lugares, tanto dentro de storeds como em TQuerys usadas para relatórios no Delphi.
Mas parece que não há outra solução mesmo...
Gostei + 0
18/06/2004
Afarias
Não tem mesmo!
Mas nos casos das UNION não tem nada q ver com isso e no IB/FB funciona perfeitamente.
T+
Gostei + 0
19/06/2004
Bon Jovi
Criar muitas Views realmente deixa o banco poluído..., além de stored procedures, etc. O melhor é o banco de dados só cuidar dos dados e a parte funcional ser sempre via aplicação servidora. Imagina manter views/stored procedures repetidas pra cada banco diferente q a aplicação for usar..., se não usa vários agora, pode ser q mais tarde sim, ou então mudança pra outro banco. Prender a aplicação em um banco só é pedir retrabalho futuro.
Gostei + 0
19/06/2004
Bon Jovi
Claro, se houver possibilidade de troca de banco no seu caso... Não é conversa de vendedor, só estou querendo expor que existe opção melhor no mercado do que o Interbase, e respeitando o custo.
A maioria dos programadores Delphi se levam pro mundo Interbase/Fb pelo fato de ter sido um produto q cresceu em uso por ser parte integrante do Delphi, e as vezes deixam de ver SGDBs melhores.. Não que Ib seja ruim, por si só é ótimo, mas cada caso é um caso.., pra aplicações multibanco ele é um dos q já me deram mais trabalho pra tratar ´ifs´.
Gostei + 0
20/06/2004
Skyzytuz
Só fiquei muito surpreso de um banco como o IB não aceitar sub-query, é o primeiro banco que vejo (além do MySql) com essa limitação. (E olha que não estou falando de sub-querys na cláusula WHERE, essas quase não uso pois quase sempre dá para substituir por JOINs, muito mais eficientes)
Outra coisa que estranhei é a impossibilidade de usar na mesma query dados de dois databases diferentes. Vou ter que reunir as tabelas de todos os sistemas e jogar tudo em um imenso banco único. Por si só, isso não é problema algum, apenas acho desorganizado jogar as tabelas de sistemas diferentes em um único banco.
Gostei + 0
20/06/2004
Bon Jovi
Mas ao mesmo tempo seria deixar o banco organizado e o programa ´desorganizado´:
DataSet1.Connection := ConnectionBanco1;
DataSet1.Open;
DataSet2.Connection := ConnectionBanco2;
DataSet2.Open;
//tendo a necessidade, manipular relacao entre os dois via while not Eof...
: / é feio tb, mas é só pra expor essa possibilidade...
Gostei + 0
20/06/2004
Skyzytuz
Mas ao mesmo tempo seria deixar o banco organizado e o programa ´desorganizado´:
DataSet1.Connection := ConnectionBanco1;
DataSet1.Open;
DataSet2.Connection := ConnectionBanco2;
DataSet2.Open;
[/quote:a8d91d0bd3]
É uma possibilidade, mas como você mesmo salientou, geraria uma bagunça danada no código, não vale a pena.
Aproveitando , o que posso fazer com a instrução SET DATABASE? Não consegui fazê-la funcionar e confessa que nem mesmo entendi direito sua real função.
Gostei + 0
21/06/2004
Bon Jovi
Gostei + 0
21/06/2004
Afarias
Interessante este conselho... :lol:
[quote:ef68f6d6a1=´Bon Jovi´]Criar muitas Views realmente deixa o banco poluído..., além de stored procedures, etc.[/quote:ef68f6d6a1]
Engraçado q VIEWs e STORED PROCs jão justamente o grande lance de SGBD-Rs
[quote:ef68f6d6a1=´Bon Jovi´]O melhor é o banco de dados só cuidar dos dados e a parte funcional ser sempre via aplicação servidora. Imagina manter views/stored procedures repetidas pra cada banco diferente q a aplicação for usar..., [/quote:ef68f6d6a1]
Particularmente tenho uma opnião bem diferente.
T+
Gostei + 0
21/06/2004
Skyzytuz
Exato. Não achei nenhuma documentação que realmente explicasse a utilidade deste comando, apenas se limitam a sintaxe.
Gostei + 0
21/06/2004
Skyzytuz
Sim, mas como qualquer outro recurso, não é panacéia. VIEWS e STOREDs são ótimas para representar as regras de negócio e simplificar as consultas mais comuns aos dados, mas daí a ser obrigado a criar uma nova VIEW apenas porque eu tenho um novo relatório com apenas um detalhe qualquer diferente de outro (como uma ordenação), é bem diferente.
Imagine eu ter 5 relatórios iguais e mude apenas a ordenação, preciso criar 5 VIEWS? Claro que não.
Gostei + 0
21/06/2004
Afarias
mas, voltando ao assunto, pq vc não posta aqui a consulta q quer fazer... é possível apenas q vc não esteja sabendo usar os recursos do SELECT corretamente!
Eu, particularmente, raramente senti falta de um recurso de sub-query.
T+
Gostei + 0
21/06/2004
Skyzytuz
Vide a primeira msg deste tópico. Note que é impossível ordenar as 3 UNION sem usar uma sub-query OU uma VIEW.
De qq forma, para mim é caso encerrado, a solução com VIEW está ok. Apenas estranhei o IB não aceitar sub-query, pois simplesmente acho mais elegante (e econômico) resolver pontualmente com sub-query no componente TQuery do que criar uma VIEW só para satisfazer uma única consulta oriunda de um único relatório.
Gostei + 0
21/06/2004
Afarias
Já disse q é possível!
Vc só não pode ordenar as diferentes querys por campos diferentes!! E, isso nào tem nada q ver com sub-querys (ao meu ver)
T+
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)