It sounds to me like you are saying “Django ORM should be better”, which is true. But the entire point of SQL is that it’s a common database language. You don’t know what it was like back in the day when every vendor had a different language. Most queries that use a common feature set work fine on ProstgreSQL, MySQL, SQLite, and Oracle. I can only think of one feature that’s written differently in MySQL, SQLite, and Postgres. The real problem comes from missing features in one than another. That multiple join query you mention: I’m almost certain that it will work with everything but MSSQL.
On Oct 6, 2012, at 8:38 AM, Yugal Jindle wrote: > Note : > > - I know we have `Django ORM` already that keeps things database independent > and converts to the database specific `SQL` queries. > - Once things starts getting complicated it is preferred to write `raw SQL` > queries for better efficiency. > - When you write `raw sql` queries 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 `django orm` alone. > > 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 `postgres` specific. 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 `database > independent`. > - 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 ? > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/cQW4Vpc9ueYJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. Peter of the Norse [email protected] -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
