Question

I have a somewhat complex query with multiple (nested) sub-queries, which I want to make available for the applications developers. The query is generic and generates a view with computed values over a collection of data sets, and the developer is expected to need only some records from what the query returns (i.e. they will limit the result for some entity’s ID or a date range or some such).

I can see 3 ways to implement this:

1. Let the developers embed the query into each application and add their own WHERE clauses as needed.
2. Create a stored procedure that accepts as parameters all the conditions I expect developers to need (for the sake of the argument lets say that I can predict what will be needed for the foreseeable future), and the procedure will run the complex query and filter it according to the parameters passed.
3. Implement the query as a view with several sub views (because MySQL doesn’t allow sub-queries in views) and have the developers use this as a table and use WHERE to have each application applies the filters they need. Currently I’m looking at 3 additional sub-views, mostly because some sub-queries are used multiple times and doing them as sub-views prevents duplication – otherwise it could have been worse ;-).

What will be better performance wise? (assuming all indexing is equivalent in all cases) Go for worst case scenarios, if you may.

what will be better in code maintenance terms, do you think?

Answer 1

I like questions that define “good” – you’ve specifically asked about performance and maintainability, which allows answers to talk about that trade-off.

From a performance point of view, I don’t think there’s likely to be any difference between the 3 options, as long as the queries and data fit within your expected scenarios. I’d test with 100 times more data, and potentially widening the “where” clause to see what happens, but the indexing structure etc. is more likely to affect the performance than whether you execute the same SQL from a stored proc, through a view, or from a client application.

The best way to answer that question is to test it – there are, of course, many specific details that could invalidate the general “I’d expect x, y, or z” answers we overflowers can give. If performance is a critical concern, use a database filling tool (Redgate make on, I’ve used DBMonster in the past) and try all 3 options.

From a maintenance point of, view, I’d provide an option 4, which – in my view – is by far the best.

Option 4: build a data access library which encapsulates access to your data. Have the library expose methods and parameters to refine the selection of records. Consider using the specification pattern (http://en.wikipedia.org/wiki/Specification_pattern). Use whatever queries are best inside the library, and don’t bother the developers with the implementation details.

If that doesn’t work – heterogeneous application code, too much of a change for a simple requirement – I’d evaluate the options as follows:

1. Embedded SQL: depending on the number of times this SQL is re-used, this may be okay. If there’s only one part of the code that runs the SQL, it’s logically similar to the data access library. If, however, the same snippet needs to get re-used in lots of places, it’s a likely source for bugs – a small change in the SQL would need to be repeated in several places.

2. Stored procedure: I generally dislike stored procedures for maintenance reasons – they tend to become brittle by over-loading, and create a procedural way of thinking. For instance, if you have other requirements for using this SQL calculation in a separate stored procedure, very quickly you end up with a procedural programming model, with stored procs calling each other.

3. Views: this is probably the best choice. It puts the specific data logic in a single place, but promotes the use of set-based logic because the access route is through a SELECT statement, rather than by executing a procedural statements. Views are easy to incorporate into other queries.