[development] SQL and connection strings

[Daniel F. Kudwien]

> Or, for that matter, use the D6 backport of the
> D7 DB layer, which is far more robust: http://drupal.org/project/dbtng
...
> The question is security.  Anyone who can write a data 
> modification query (insert, update, delete) has root access 
> to your site.  End of story.  I presume you don't want that.  
> In your case you're hitting a DB other than the main Drupal 
> DB so that's the DB that would be at risk.
...
> So first off, you'd need to whitelist SELECT queries and 
> disallow anything else.

Crell's considerations are awesome, as always.  Reading them, I'd recommend
to

1) Create a new database user, having read (SELECT) privileges only, on
selected tables only.

2) Switch to that user at runtime to perform the queries.  Ideally using the
backport of DBTNG.  Perhaps try to parse the user input, or as Crell
suggests, use Views + Views UI as query builder.

3) When thinking Views, your question about storage translates into "export
into code" for file storage.

However, I'm not sure whether Views is ready for end-user consumption,
usability-wise.  Of course, if you didn't have any query builder UI in mind
in the first place, then Views sounds like ice-cream.

Lastly, don't forget to report about your evaluation, progress, and
decisions on Planet Drupal. :)  I guess this topic is quite interesting for
many users, perhaps especially enterprise users.

sun