In what use cases should I prefer writing PostGIS views for filtering datasets versus filtering with WFS filter encoding operators and vice versa? In both cases I would be serving the data via GeoServer through the PostGIS table or view.
The main pro I can think of for the WFS filter approach is that the query can be encoded easily through the front end according to the filter specifications without needing to add extra logic to the backend code to handle the PostGIS queries. Also, how does the WFS filter fare performance wise against PostGIS?
Best Answer
Comparing filters which are sent by WFS clients with a fixed views which are created into the database is not very reasonable for my mind. Both have their use cases and normally if WFS service is not made only for delivering the whole featuretype with plain GetFeatures the data that comes from the database are filtered further with WFS filters.
Geoserver tries to convert filters to corresponding SQL queries and in simple cases
there should not be notable difference in the performance . With complicated queries it may happen that Geoserver queries more data from PostGIS than necessary and the final filtering is done on the server. That may be slower but it depends.
Main use case for database views is when there is a need to alter somehow what data will be published from the database in a stable and reliable way. Selecting just a subset of attributes for WFS, changing attribute names, computing new attributes on the fly, using joins etc. it pretty simple to do on the database side and it is also possible to optimize the SQL code and not to rely on the SQL queries which are automatically generated by Geoserver. For hiding some unnecessary of sensitive data the filters are not a real option. Even it is simple to make the client to send certain filters always it would be too easy for the users to fiddle with the code and rip off or modify the filters.
Filters are good for allowing users and applications to do either pre-defined or ad hoc queries and select a small subset of all the available data. The feature type may contain millions of features and they must be available for the users, but usually when user needs data a well filtered handful is enough. Views in the database are good for setting the upper limits for what is available from the database.
The SQL Views in Geoserver lie somewhere in between http://docs.geoserver.org/stable/en/user/data/database/sqlview.html as well as the prepared statements in WFS 2.0.0.