Keeping Your Data Secure
========================

The whole point of TAP is to allow general relational queries against your tables.  
But what if you have tables that contain sensitive information?  The short answer 
is that you shouldn't make them visible to TAP.  

Similarly, while nexsciTAP limits input SQL to performing SELECT statements, the
tables visible to TAP should be read-only.

In all the DBMSs with which we are familiar, it is possible to create read-only
views of the tables you want to expose in a separate schema.  This schema is 
frequently nothing but views of tables in other schema.  This completely 
protects the data from being corrupted.

Similarly, any sensitive data can be kept out of the directly-readable space.
This doesn't mean you have no access to it.  For instance, some of our implementations
use user and project databases for determining which records in the searchable data
table a user is allowed to access.  This "proprietary filtering" is done in a 
custom module, modifying the query the user entered to include the right joins and
filtering to get the right records.  This code is allowed to see the schema containing
the secure data.

But the user's original query, which gets checked against the TAP_SCHEMA list of 
accessible tables, doesn't mention these sensitive tables and would not be allowed
to query them directly.