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


Ответы:


217

SQLite пришлось пожертвовать другими характеристиками, которые некоторые люди считают полезными, такими как высокая степень параллелизма, детализированное управление доступом, богатый набор встроенных функций, хранимые процедуры , эзотерические функции языка SQL, расширения XML и / или Java, тера или петабайтная масштабируемость и т. д.

Источник: подходящее использование для SQLite


3
Вы можете использовать SQLite-эквивалент функций SQL CLR для достижения той же цели ( stackoverflow.com/questions/172735/… ).
Devinbost

@bostIT Спасибо за добавление. Ссылка на System.Data.SQLite system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
h3xStream

91

Ответ : НЕТ

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

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


16
Чтобы уточнить ... Я не говорю, что нет никаких причин для реализации SP в SQLite - просто гораздо меньше причин, чем в других движках БД.
Тони О'Хаган

4
КЛЮЧЕВАЯ причина наличия хранимых процедур - предотвращение SQL-инъекций. Однако есть много других причин. Например, возможность поделиться соответствующими запросами, вставив их в файл sqlite. Нет абсолютно никакой разницы между стандартным запросом, который выполняется в контексте SQL Engine, и выбором SP. Они оба работают на ДВИГАТЕЛЕ SQL.
Дан

4
@Dan Во-первых, SP существовали задолго до того, как о SQL-инъекциях даже думали. Тысячи приложений на основе SQL были созданы без них, которые защищены от этой атаки. Я также рассмотрел код небезопасных SP, которые уязвимы для внедрения SQL (как правило, на основе динамического SQL). Так что нет, это не основная причина. Есть много других способов предотвратить дальнейшую атаку в стеке.
Тони О'Хаган

3
@Dan Большинство SQL-движков являются клиент-серверными (НЕ SQLite!). Для них ключевым моментом при выборе места для размещения вашей бизнес-логики является производительность. Выполнение бизнес-логики, будь то запрос ИЛИ интерактивный ИЛИ условный код внутри SP в механизме SQL, может (1) повысить производительность извлечения данных, (2) уменьшить сетевой трафик (3) уменьшить использование памяти уровня приложения (4) планы выполнения запросов кеша (предварительно скомпилированные СФС). Большинство разработчиков приложений предпочитают перенести часть своей бизнес-логики за пределы механизма SQL (очевидно, не запросов!). Для SQLite это менее важно, так как он не поддерживает клиент / сервер.
Тони О'Хаган

Спасибо, Тони. Мне было интересно, почему SQLite не имеет процедур, но имеет встроенные функции ( sqlite.org/lang_corefunc.html )? Верно ли, что для клиент-серверной СУБД, такой как postgresql, функции и процедуры хранятся на стороне сервера? Поскольку SQLite является бессерверным, если SQLite не имеет процедур, то по той же причине, разве у него тоже не должно быть функций?
Тим

17

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


5
Статья сейчас мертва, но проект находится по адресу github.com/wolfch/sqlite-3.7.3.p1 . Файл readme подразумевает, что он не готов к работе и не предназначен для экспериментов. Похоже, это скорее подтверждение концепции.
pqsk

7

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.