6

This question already has an answer here:

This part of the docs says it supports only a small part of the SQL syntax but does that mean it's SQL based or am I better writing expressions in something else, MySQL?

This is similar to What expressions for QGIS field-calculator? but my query was not limited to the field calculator, it also applied to the filter and label options. I understand from the answer to that question that QGIS has it's own language for the field calculator is that the same for label by expression and filter by expression. I generally try SQL based syntax on these as a first approach with support from here when those fail.

marked as duplicate by whyzar, BERA, Matthias Kuhn, ahmadhanb, mgri Jul 13 '17 at 13:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    Perhaps this post might help: What expressions for QGIS field-calculator? – Joseph Jul 13 '17 at 10:05
  • Might be best to take a look at the examples shown in the Function Help window inside the Field Calculator and get used to the language QGIS uses by practicing ;) – Joseph Jul 13 '17 at 11:50
  • does that mean it's SQL based or am I better writing expressions in something else, MySQL? I don't think there's a general answer to this. :) – Matthias Kuhn Jul 13 '17 at 12:19
6

The QGIS Expressions engine behind labels, data defined symbology, rule based rendering filters, field calculator... is the same [1].

The whole expressions engine is quite powerful (and is one of the parts of QGIS that receives an impressive stream of improvements with each and every QGIS release). It is very close to SQL when it comes to calculating things.

The main difference to a lot of SQL implementations is, that it doesn't implement any parts of DDL, TCL or DCL. It only implements a subset of DML, in particular the part for calculations. While I don't think someone ever reviewed its complicance with SQL-standards it should be close enough to port knowledge.

[...] does that mean it's SQL based or am I better writing expressions in something else, MySQL?

That's a tough question with no general answer.

Some points to consider:

  • Sometimes you are not able to replace it by something else (try running SQL on a shapefile).
  • Sometimes you want it to be portable (QGIS expressions produce the same result regardless if you use a postgis or a csv as data provider)
  • Sometimes you don't have access to the database server to define views or modify data to your needs.
  • It's just so much easier to build an expression than to define a view
  • Sometimes you need to aggregate data from different tables (Note: that's possible with QGIS expressions, but performance is reduced compared to server side calculations)
  • There may be other considerations imposed by your environment or requirements.

What to do?

Try your way through the expressions. If you regularly work with QGIS you WILL want to use them. Make them your everyday swiss army knife tool. Just keep in mind that once in a while you will need to solve tasks with something else. If that's the case, you will know ;)

[1] There are some minor differences depending on the context. For example some variables are only available in certain contexts like variables for the current symbol are only available during rendering and not in the field calculator.

Not the answer you're looking for? Browse other questions tagged or ask your own question.