My opinion is that the logic for database queries should be held together with the data. I don't think that embedded vs. non-embedded makes a difference here. One could as well use a MySQL or whatsoever database, and the application code still owned and create the database. This will always be the case, because who else should?
A scenario where it could be important could be encrypted databases. The logic stored in the database would then be encrypted as well. ----- Original Message ----- From: Jens Alfke <j...@mooseyard.com> To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Sent: Friday, November 2, 2018, 00:07:53 Subject: [sqlite] forming sqlite3_statements using stored sql This doesn’t seem very useful for an embedded database engine — the application code owns and creates the database, so it already has those SQL strings; in which case it just seems like extra work to first write them to the DB and then have the DB read them back out again to compile statements. Yes, I could imagine an over-the-air update scenario that updates the strings in the database … but the likelihood of a software update that _only_ affects SQL strings and not any native code is very low. Maybe I’m misunderstanding the feature, but to me it sounds like one of those DBMS server features that doesn’t really belong in SQLite itself. Perhaps it could be added to the shell? —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
