Возможно ли создать хранимую процедуру при использовании SQLite?
SQLite пришлось пожертвовать другими характеристиками, которые некоторые люди считают полезными, такими как высокий concurrency, мелкозернистый контроль доступа, богатый набор встроенных функций, хранимые процедуры, эзотерический SQL языковые функции, расширения XML и/или Java, масштабируемость по tera- или peta-байту и т.д.
Источник: Соответствующее использование для 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, которая может быть пустой или иметь поле сообщения, если что-то пошло не так.