Devemos ter um banco de dados independente de SQL como linguagem de consulta no Django?

Question

Devemos ter um banco de dados independente de SQL como linguagem de consulta no Django?

Navegue suas respostas

#1 resposta do (6 votos)
#2 resposta do (3 votos)
#3 resposta do (-2 votos)

5

Nota:

Eu sei que temos Django ORM que mantém o banco de dados independente e converte para o banco de dados específico SQL queries.
Quando as coisas começam a ficar complicadas, é preferível escrever raw SQL consultas para uma melhor eficiência.
Quando você escreve raw sql consultas, seu código fica preso ao banco de dados que você está usando.
Eu também entendo que é importante usar todo o poder do seu banco de dados que não pode ser alcançado com o django orm sozinho.

Minha pergunta:

Até eu usar qualquer recurso específico do banco de dados, por que alguém deveria estar preso ao banco de dados.
Por exemplo:

We have a query with multiple joins and we decided to write a raw sql query. Now, that makes my website postgres specific. Even when I have not used any postgres specific feature.

Eu sinto que deveria haver uma linguagem fake sql que pode se traduzir para a consulta sql de qualquer banco de dados. Até mesmo o ORM do Django pode ser construído sobre ele. Então, se você sair do ORM, mas não específico do banco de dados - você ainda pode permanecer independente do banco de dados.

Eu fiz a mesma pergunta para Jacob Kaplan Moss (pessoalmente):

Ele me aconselhou a ficar com o banco de dados que eu gosto e suportar todo o seu poder, com o qual eu concordo. Mas meu ponto não é que devamos ser database independent .
Meu ponto é que devemos ser independentes do banco de dados até usarmos um recurso específico do banco de dados.

Por favor, explique, por que deveria haver uma camada fake sql sobre o SQL real?

================================

Atualização:

================================

Minha sugestão:

Resolva a independência do banco de dados em um nível fake sql e, em seguida, compile o ORM sobre esse sql falso. Então, se eu tiver que escrever uma consulta sql - usarei fake sql que funcionaria em todos os bancos de dados ainda SQL bruto. Dessa forma, vou permanecer independente do banco de dados, a menos que eu use um recurso muito específico para o meu banco de dados.

Portanto, uma consulta como select * from table limit 10; funcionará no postgres e no 'MS-SQL Server'.

Isso é sensato?

Nota:

Eu não estou falando sobre ANSI SQL , estou sugerindo um fake sql para fazer todos os bancos de dados funcionarem com 1 sql padrão. [Que pode não abranger recursos específicos do banco de dados]

sql database python orm django

por Yugal Jindle 22.10.2012 / 07:30

fonte

3 respostas

3

O princípio YAGNI é importante neste caso.

Ao decidir sobre o tópico, você deve considerar as vantagens e desvantagens de estar vinculado a um banco de dados específico.

Não é como se houvesse milhares de bancos de dados diferentes por aí. Para bancos de dados relacionais, as escolhas populares são Postgres e Mysql. E suas diferenças e características distintas são bem conhecidas, por isso é fácil compará-las de antemão para o problema que você vai resolver.

Se você estiver no controle do ambiente de produção, estude as diferenças entre eles e escolha um.

Se você não estiver no controle do ambiente de produção, como se fosse distribuir o software para os usuários finais, e eles os instalassem em suas próprias plataformas, então você deveria apontar para a independência do banco de dados.

A menos que você realmente tenha uma razão convincente para ser independente do banco de dados, será um incômodo e morder você a longo prazo se você pretende fazê-lo. O conselho geral para este tipo de situações é não fazer as coisas apenas para o fazer.

por 22.10.2012 / 11:39

fonte

-2

A API de banco de dados Python usa uma convenção comum, que é praticamente a mesma em bancos de dados diferentes (mas não exatamente!). Você pode ler a documentação do MySQLdb aqui.

Há também uma interface mais rica em recursos para o mysql, chamada oursql. Ele tem uma parametrização real (não apenas uma interpolação de string glorificada), cursores do lado do servidor, fluxo de dados e assim por diante.

por 22.10.2012 / 09:18

fonte

Tags sql database python orm django

Software open source com boa documentação de código para melhorar a habilidade de design [closed] Um site que está executando o software GPL modificado tem a obrigação de liberar suas alterações? [duplicado]

score 6 · Accepted Answer

Acho que você está procurando o padrão SQL ANSI .

Esse padrão é implementado na maioria dos RDBMS para a maior parte.

No entanto, todos os RDBMS decidiram fazer algumas coisas do seu jeito. (Simplesmente porque o padrão não tem o recurso ou outro motivo. LIMIT tem um equivalente desde o SQL: 2008 apenas por exemplo.)

Listar essas diferenças do padrão SQL levaria uma página inteira para isso. Oh espere, foi feito !

Então, para responder a você, por essa mesma razão, você não pode ser independente do RDBMS sem perder o desempenho (ou seja, criar uma camada). As diferenças nas implementações do padrão SQL são o que levou as pessoas a criar ORMs.