Is directly executing SQL bad app design?

Posted by Michael Lowman on Stack Overflow See other posts from Stack Overflow or by Michael Lowman
Published on 2011-01-07T20:54:43Z Indexed on 2011/01/12 18:54 UTC
Read the original article Hit count: 165

Filed under:
|
|

I'm developing an iOS application that's a manager/viewer for another project. The idea is the app will be able to process the data stored in a database into a number of visualizations-- the overall effect being similar to cacti. I'm making the visualizations fully user-configurable: the user defines what she wants to see and adds restrictions.

She might specify, for instance, to graph a metric over the last three weeks with user accounts that are currently active and aren't based in the United States.

My problem is that the only design I can think of is more or less passing direct SQL from the iOS app to the backend server to be executed against the database. I know it's bad practice and everything should be written in terms of stored procedures. But how else do I maintain enough flexiblity to keep fully user-defined queries?

While the application does compose the SQL, direct SQL is never visible or injectable by the user. That's all abstracted away in UIDateTimeChoosers, UIPickerViews, and the like.

© Stack Overflow or respective owner

Related posts about sql

Related posts about stored-procedures