Melhor maneira de organizar consultas SQL armazenadas no seu código? (ou deveria?) [fechado]

Fechado . Esta questão precisa ser mais focada . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela se concentre apenas em um problema editando esta postagem .

Fechado há 5 anos .

Tenho certeza de que não sou o único que fica frustrado ao ver uma página de código repleta de consultas SQL. O ActiveRecord e outros padrões ORM ajudam a mitigar uma boa quantidade de SQL usada em um projeto, mas em muitos casos de consultas complexas, o uso do SQL é aparentemente inevitável.

Estou procurando opiniões sobre como as consultas SQL devem ser organizadas com o restante do código (ou externamente) para impedir que ele seja espalhado por todo o lugar? Uma idéia óbvia é o uso de Views, mas muitas vezes as Views podem ser uma fonte de problemas de desempenho ao lidar com várias tabelas indexadas grandes, etc.

EDIT 1 - Estou assumindo que você já o separou na camada do modelo

sql code-formatting

— água-viva
fonte

Esta questão é definitivamente apropriada aqui - organização do código: 'inspira respostas que explicam "por que" e "como". e é dos assuntos 'Design patterns' e 'Architecture' (do Faq )

— Michael K

Eu estava prestes a fazer a mesma pergunta. Eu gostaria que houvesse mais respostas aqui.

— Michael Kristofik 13/10/11

Respostas:

Para mim, o SQL é uma parte fundamental (em muitos casos, a maioria) do código de lógica de negócios. Se você tentar separá-lo do código que opera nos dados retornados, é mais provável que você desequilibre a compreensibilidade e a capacidade de manutenção do código.

Na minha opinião, ler dados, processar dados, gravar dados, pesquisar dados ... são todas operações semelhantes e devem ser mantidas no mesmo local.

Se você começar a perceber uma duplicação de esforços nas consultas, talvez seja necessário uma visualização do banco de dados ou um objeto que possa encapsular esse aspecto do acesso ao banco de dados.

Outra dica é realmente ter um bom método de consulta ao banco de dados. No software que escrevo (PostgreSQL, MySQL, SQL Server), assegurei que a maior parte das minhas operações de consulta pudesse ocorrer como uma única declaração de código.

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

Essas são (aproximadamente) as principais chamadas de função que eu garanto que fazem parte do meu "objeto de conexão". Depende da linguagem, o que você realmente implementa, mas meu objetivo é mantê-la realmente, realmente simples e indolor.

Em resumo, trate o SQL como parte nativa da programação e não faça abstrações por abstração.

— gahooa
fonte

uma ótima resposta. talvez eu só precise dar um passo atrás e começar a olhar para o SQL como parte do código, não apenas espalhado por ele.

— perfil

"não abstraia por abstração" - Bom argumento. Resumo por uma questão de código mais compreensível.

— Jason Baker

'Outra dica é realmente ter um bom método de consulta ao banco de dados': concordo definitivamente. Ajuda muito quando há apenas um lugar para modificar o código quando a lógica de negócios muda.

— Michael K

Onde você coloca o SQL? É compilado no aplicativo e enviado usando os métodos acima?

— 31414 johnny

Baseado no comentário do OP sobre a resposta de Jason Baker, "olhando para o barril de uma consulta SQL gigante ...", como isso resolve o problema de ler grandes blocos de texto SQL?

— Jeffo

Geralmente, ter uma camada de modelo separada é a melhor abordagem. Existem vários padrões de design corporativo que oferecem maneiras de arquitetar isso.

— Jason Baker
fonte

desculpe, eu deveria ter sido mais específico ... Eu já estou assumindo que você os separou em uma camada de modelo. Mas uma camada de modelo ainda pode ficar bastante dispersa com o código SQL. Talvez isso seja inevitável. A outra coisa que me assusta no código do modelo é o código que "constrói uma consulta SQL" com base em alguma lógica ... talvez isso deve ser separada em sua própria fábrica ou algo assim ...

— jellyfishtree

@jellyfishtree - Receio não entender qual é o problema. Quero dizer, você tem medo de que sua camada de modelo possa acabar com muito código de modelo?

— Jason Baker

uma refutação válida. Estou preocupado com a legibilidade. Um bom código de modelo geralmente é bastante fácil de entender, mas olhar para o barril de uma consulta SQL gigante não tem exatamente o seu significado. Obviamente, a primeira coisa a fazer é comentar adequadamente essas consultas, mas não é o mesmo que um bom código de auto-documentação e esse tipo de seção se espalha pelo modelo. Eu aceito isso, mas eu queria saber se existe uma melhor maneira de isolar ou organizar instruções SQL loucos no modelo ...

— jellyfishtree

Pode ser uma boa idéia separar a camada do modelo em três subcamadas - "entidades", "repositórios" e "serviços". Isso permitirá separar as preocupações e reunir o SQL em um único local, fora da lógica de negócios.

Nesse cenário, todo o código de recuperação de dados, incluindo SQL complexo - estará localizado em repositórios. Portanto, o objetivo do repositório é ocultar instruções SQL complexas por trás de métodos autoexplicativos getUsersWithActiveSubscription().

A entidade abstrai os nomes reais dos campos da tabela do banco de dados com getters e setters, pode fornecer alguma conversão de dados entre os tipos e tipos de campos do banco de dados disponíveis na sua aplicação / linguagem de programação. Se o seu ORM suportar isso, as entidades podem lidar com associações.

Camada de serviço é o local para a lógica de negócios. O serviço recupera entidades usando repositórios, age sobre elas e as armazena de volta.

— GerKirill
fonte