Создание хранимой процедуры и SQLite?

Ответ: НЕТ

Вот почему... Я думаю, что ключевой причиной для хранения procs в базе данных является то, что вы выполняете код SP в том же процессе, что и механизм SQL. Это имеет смысл для движков баз данных, предназначенных для работы в качестве подключенной к сети службы, но императив SQLite намного меньше, поскольку он работает как DLL в вашем прикладном процессе, а не в отдельном процессе работы с SQL-машиной. Поэтому имеет смысл реализовать всю вашу бизнес-логику, включая то, что было бы SP-кодом на языке хоста.

Однако вы можете расширить SQLite с помощью собственных пользовательских функций на языке хоста (PHP, Python, Perl, С#, Javascript, Ruby и т.д.). Затем вы можете использовать эти настраиваемые функции как часть любого SQLite select/update/insert/delete. Я сделал это в С#, используя DevArt SQLite для реализации хэширования паролей.

SQLite не имеет sprocs.

Если вы все еще заинтересованы, Крис Вольф сделал прототип реализации SQLite с хранимыми процедурами. Вы можете найти информацию в своем блоге: Добавление хранимых процедур в SQLite

Просто потому, что большинство приложений, использующих SQLite, не используют хранимые procs, не означает, что они не полезны.

Одно из основных применений, которое у меня есть для них, заключается в том, что мне не нужно повторно распространять все приложение, когда запрос слегка меняется. Просто db изменяется, и что простой script, обычно меньше 1k.

Я рассматриваю вопрос о том, должен ли я опубликовать мой сохраненный код С#/SQL proc. Я нашел эту тему, когда искал, кто-нибудь еще это сделал.

Я не согласен с тем, что люди (иногда) хотят, чтобы sproc выполнялся в том же пространстве выполнения, что и сервер, но SQLite по определению находится в том же пространстве, что и приложение.

Тем не менее, можно подделать его, используя специальную таблицу, названную для вашего fake-sp, с триггером AFTER INSERT. В выделенных строках таблицы содержатся параметры для вашего поддельного sp, и если ему нужно вернуть результаты, вы можете получить вторую (poss. Temp) таблицу (с именем, связанным с fake-sp), чтобы содержать эти результаты. Для этого потребуются два запроса: сначала данные INSERT в таблицу fake-sp-trigger, а вторая - SELECT из таблицы fake-sp-results, которая может быть пустой или иметь поле сообщения, если что-то пошло не так.