Data layer allowing query building

Question

I need to deliver a small app allowing the client to create queries (or "rules") against their local database and trigger certain actions (send mails, text messages and stuff).

Since they will be allowed to state the actual SQL for the job, I am wondering how my data layer is supposed to look like. It seems I don't have any need for entities and repositories, because all data interaction will be weakly typed.

So what should my data layer do? Open the connection, accept the input SQL, and return a list of property bags? Do I even need a data layer for this?

[Update]

This is what client wants to have in his app, to be able to write or build queries against their database. It will run on their local computer, meaning that SQL injection attacks are unnecessary for a malicious employee.

But even if I have a visual control for building the query, validating and sanitizing it, the end result of this layer is SQL code, isn't it? How do I abstract that if I want to test it?

Answer 1

Actually, we had the almost same problem more than 10 years ago (though it was not on a local database). IMHO for ad-hoc SQL queries (however they are created, the user could just have a textual shell to type them in), a DAL does not make much sense - for the generic reporting / query part of the application. That does not mean you cannot have a DAL for the parts of the application where data is modified or entered into your database.

You should, however, take care for some things. Obviously, syntactically incorrect queries should give a meaningful error message, and there should be a possibility to interrupt long-running queries.

It may be also a good idea to restrict the ad-hoc query access to certain tables, or provide a layer of certain views, to hide technical parts of your data model away from your users. And I would avoid to allow your users to modify any data in a similar ad-hoc manner - make sure they cannot inject any UPDATE statements into a SELECT statement created by them.

Answer 2

Generally, it is considered dangerous to accept SQL or any inputs to the SQL query directly from the user, as such a code would be prone to SQL Injection attacks. Instead, if this is not a one-off case, and a case where you want to give your users the flexibility to query anything, you should define an intermediate language that the users would use to specify their filtering criteria, which will be used for SQL query generation. This way, you have

1. a chance to sanitize the user inputs before adding them to your query.
2. decoupled your object model from the users, so that if you want to change the object model or the storage itself later on, the users will not be affected at all as long as you write the adapter from this intermediate language to the modified object model or new storage.

We did this in one of our projects to provide users the flexibility to filter, sort, group on any attributes of the underlying data model and this approach works really well.

Answer 3

Build a reporting database / star schema using PL/SQL or better an ETL tool which will allow you to clean / enrich the data, pre-apply business rules, use business language for columns and tables rather than technical terms and make the user queries return fast, and put a reporting tool like Cognos over the star schema which pre-joins all the tables for the user and allows you to apply governorship rules to prevent silliness from the users.

That is the simplest, most effective way, but is not cheap.