Jump to content

Como guardar muitas queries?


RMS
 Share

Recommended Posts

Estou envolvido num projecto com um tamanho considerável, suportado por uma base dados com cento e poucas tabelas e centenas de queries. Até agora ainda não consegui descobrir "a melhor" forma de guardar todas queries necessárias.

Inserts/updates/deletes estão em stored procedures para poder fazer rollbacks quando necessário. Agora tudo o que são selects estão em ficheiros XML ou no meio do código. Começa a ser complicado gerir tantas queries.

Alguém tem alguma ideia (ou experiência) de qual será a melhor prática para guardar tantas queries, de maneira a facilitar a gestão e actualizações?

Obrigado!

Link to comment
Share on other sites

Ora se bem percebi queres guardar as querys fora do código e depois para que possam ser alteradas facilmente sem ter que mudar código.

Não estou a ver o tamanho da complexidade do caso mas acho que ficheiro de propriedades/configuração dá para o caso, género key/value ou seja nome da query -> query de forma a que quando precisas da query basta chamar pelo nome.

I haven’t lost my mind; it’s backed up on DVD somewhere!

Link to comment
Share on other sites

Uma forma comum para projectos grandes é todas as queries estarem encapsuladas em store procedures e/ou views.

No código a única coisa que se faz é select às views e chamadas às sp.

Isto ajuda porque:

- separa a camada de dados do código da aplicação;

- fica tudo no lado da base de dados;

- a manutenção é bem mais simples;

- actualizações são menos problemáticas.

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Uma forma comum para projectos grandes é todas as queries estarem encapsuladas em store procedures e/ou views.

No código a única coisa que se faz é select às views e chamadas às sp.

Isto ajuda porque:

- separa a camada de dados do código da aplicação;

- fica tudo no lado da base de dados;

- a manutenção é bem mais simples;

- actualizações são menos problemáticas.

Sim ou ficheiros XML que depois são "consumidos" pelos query managers, o importante é implementar o um query manager talvez até um que permita consumir varias fontes DB, XML, ConfigFile, WS etc...

Desta forma o código fica totalmente limpo de SQL e fica muito mais flexível.

I haven’t lost my mind; it’s backed up on DVD somewhere!

Link to comment
Share on other sites

Obrigado.

As views seriam uma boa opção se não tivesse que construir novas queries para filtrar os resultados.

Por outro lado não queria estar a criar um procedure para cada select (pelo trabalho e pela organização).

De momento tenho vários ficheiros XML, provavelmente será melhor melhorar a forma como estão a ser "consumidos".

Entretanto ocorreu-me outra ideia: e se colocasse as queries dentro de uma tabela na base dados?

Link to comment
Share on other sites

Obrigado.

As views seriam uma boa opção se não tivesse que construir novas queries para filtrar os resultados.

Por outro lado não queria estar a criar um procedure para cada select (pelo trabalho e pela organização).

De momento tenho vários ficheiros XML, provavelmente será melhor melhorar a forma como estão a ser "consumidos".

Entretanto ocorreu-me outra ideia: e se colocasse as queries dentro de uma tabela na base dados?

Sim era a isso que me referia quando disse fonte DB, depois apenas tens de ter um select que vai buscar a query pelo nome por exemplo. E de forma a tornar isso ainda mais viável e flexível ao invés de usar esse select directamente no código podes encapsular num método ou função assim caso tenhas de a alterar só tens de o fazer em um sitio

I haven’t lost my mind; it’s backed up on DVD somewhere!

Link to comment
Share on other sites

Colocar as queries dentro de uma tabela vai apenas resultar num esforço e tempo adicionais totalmente desnecessários.

Porquê guardar isso dentro de uma tabela quando as queries podem estar directamente acessíveis na base de dados e, para serem guardadas em controlo de versões, pode ser criado um script SQL com as mesmas?

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Sim era a isso que me referia quando disse fonte DB, depois apenas tens de ter um select que vai buscar a query pelo nome por exemplo. E de forma a tornar isso ainda mais viável e flexível ao invés de usar esse select directamente no código podes encapsular num método ou função assim caso tenhas de a alterar só tens de o fazer em um sitio

Não tinha reparado que tinhas referido DB. 😉 Mas sim era isso mesmo.

Link to comment
Share on other sites

Colocar as queries dentro de uma tabela vai apenas resultar num esforço e tempo adicionais totalmente desnecessários.

Porquê guardar isso dentro de uma tabela quando as queries podem estar directamente acessíveis na base de dados e, para serem guardadas em controlo de versões, pode ser criado um script SQL com as mesmas?

Pois, o "esforço adicional" neste projecto é relevante!

O controlo de versões também interessa, mas neste momento já tenho que copiar os stored procedures e as functions para ficheiros à parte.

Parece-me que o melhor passará sempre por uma solução "híbrida": stored procedures e functions obrigatoriamente na base de dados (e copiados para ficheiros à parte para controlo de versões) e selects mais tradicionais em XML.

Link to comment
Share on other sites

Copiar?

Isso não faz sentido. Exportar para um script de SQL e colocar em controle de versões sim, faz sentido. Além de que o custo é muito inferior a uma cópia manual de todas as SP.

Não faltam ferramentas que ajudam a fazer esta exportação com dois cliques de rato...

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Link to comment
Share on other sites

Eu normalmente quando quero ter esse tipo de flexibilidade uso XML até porque dá para controlar a versão das queries e tudo.

Já agora chegas-te a ponderar a hipótese de usar um ORM, não sei tecnologias estás a utilizar ou linguagem mas actualmente há ORM's para quase todo e no que toca a flexibilidade é o melhor. Mas depende da qualidade do ORM claro!

I haven’t lost my mind; it’s backed up on DVD somewhere!

Link to comment
Share on other sites

@M6

O tempo despendido a copiar não é assim tanto, porque é mais manutenção do que outra coisa. Temos um projecto SQL onde actualizamos e organizamos os stored procedures por sub-projectos. Mas se souberes de alguma ferramenta porreira... 😉

@magician

O projecto é em .Net (com SQL Server), com parte web e parte windows application.

Nunca ponderei o uso de ORM (principalmente por preguiça) porque quando agarrei neste projecto já estava numa fase muita avançada, e neste momento uma mudança desse género tem mesmo que compensar o tempo despendido. Mas estou sempre receptivo a sugestões. 🙂

Link to comment
Share on other sites

Para .NET tens o NHibernate, embora nunca tenha mexido nele já usei o Hibernate que é para Java.

Pois isso vais ter de avaliar o teu caso, se o projecto foi desenvolvimento "correctamente" com estruturas de dados, por exemplo uma classe Cliente para representar a tabela cliente na bd então a mudança é mínima dado que é esse o paradigma usado pelos ORM's.

I haven’t lost my mind; it’s backed up on DVD somewhere!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.