- I know we have
Django ORMalready that keeps things database independent and converts to the database specific
- Once things starts getting complicated it is preferred to write
raw SQLqueries for better efficiency.
- When you write
raw sqlqueries your code gets trapped with the database you are using.
- I also understand its important to use the full power of your database that can-not be achieved with the
My Question :
- Until I use any database specific feature, why should one be trapped with the database.
- For instance :
We have a query with multiple joins and we decided to write a raw sql query. Now, that makes my website
postgresspecific. Even when I have not used any postgres specific feature.
I feel there should be some
fake sql language which can translate to any database's sql query. Even Django's ORM can be built over it. So, that if you go out of ORM but not database specific - you can still remain database independent.
I asked the same question to
Jacob Kaplan Moss (In person) :
- He advised me to stay with the database that I like and endure its whole power, to which I agree. But my point was not that we should be
- My point is we should be database independent until we use a database specific feature.
Please explain, why should be there a
fake sql layer over the actual sql ?
Solve the independence of the database on a
fake sql level and then build ORM over that fake sql. So, if I have to write a sql query - I will use
fake sql that would work on all databases yet raw SQL. That way, I will remain database independent unless I use a feature very specific to my database.
Therefore, a query like
select * from table limit 10; will work on both
postgres and 'MS-SQL Server'.
Is that sensible ?
- I am not talking about
ANSI SQL, I am suggesting a
fake sqlto make all databases work with 1 standard sql. [ Which may not cover db specific features ]