Я не излагал в статье своё понимание данного термина, кстати.
Насколько я понимаю, автоматически выполнять при «update/insert/delete» — можно триггеры. А триггеры и хранимые процедуры — не одно и то же.
Я знаю, чем хранимая процедура отличается от одиночного SQL-запроса, поверьте. И совершенно согласен с определением в Википедии )). Возможно, название статье дал не самое удачное, согласен.
Решить эту проблему полноценно нельзя в приципе, поскольку в SQLite просто нет хранимых процедур от рождения.
Но я часто использую хранимые процедуры именно просто как хранилище SQL-кода. Просто для того, чтобы отделять SQL-код от Delphi-кода. И именно эту функциональность реализует данный класс. Но никак не полноценные хранимые процедуры, конечно.
И всё-таки интересно — есть ли лучший способ отделить SQL-скрипты от кода? Пока тут прозвучало только одно предложение, но, ИМХО, довольно бредовое ))
Я вам по секрету скажу, что хранимая процедура — это и есть набор SQL-инструкций.
Разница в том, что она может содержать переменные и более чем один запрос.
Но я потому и назвал статью "Альтернатива хранимым процедурам".
И кто вам пообещал прогреес для науки? Это просто маленький лайфхак ))))
Друзья! Многие комментарии напоминили мне ивестную историю «Как правильно резать лук в борщ?» )))
На вс. сл. — вопрос не стоит — почему именно борщ и почему именно лук. тут лишь рассказывается как резать этот самый лук в этот самый борщ! ))
Вы слишком строги к разработчикам IDE :) Да, Делфи не идеальна. Но идеальных IDE я пока и не видел. Поначалу восхищался вот Android studio. Пото спали розовые очки и начал потихоньку материть её )))
Я использую и компоненты (TFDQuery например) тоже в проектах. Но когда количество запросов измеряется десятками — это уже совсем не комильфо, поверьте. Чтобы отредактировать текст запроса, я должен найти компонент на форме и дважды щелкнуть по нему. Это гораздо менее удобно. Я уж не говорю о том, что всё это довольно громоздкие объекты, которые жрут память, ресурсы… Так я использую один объект. А в вашем варианте их буде создано одновременно несолько десятков.
Впрочем, я не настаиваю. Мне удобнее — так. Но на вкус и цвет… :)
Выбор СУБД не обсуждается в моём случае. Он предопределен заказчиком. И у него имеются веские аргументы.
А потом, статья ведь не о выборе СУБД совсем :)
Ну и чем лучше форма, содержащая десятки а то и сотни компонент? Найти и отредактировать в ней нужный запрос — тот еще квест ))))))
Предложенное вами решение — крайне неудобно, ИМХО
Да, была мысль разбить это дело на файлы как-то. Но отказался. Сам запрос отлаживается в SQLite Expert. И в проект помещается уже рабочий, единожды. Процедуры легко находятся по имени поиском. Никакого выигрыша от «многофайловости» не будет в работе. Ну разве только если действительно, процдур будет космическое количество и они будут огромны.
Насколько я понимаю, автоматически выполнять при «update/insert/delete» — можно триггеры. А триггеры и хранимые процедуры — не одно и то же.
Я знаю, чем хранимая процедура отличается от одиночного SQL-запроса, поверьте. И совершенно согласен с определением в Википедии )). Возможно, название статье дал не самое удачное, согласен.
Решить эту проблему полноценно нельзя в приципе, поскольку в SQLite просто нет хранимых процедур от рождения.
Но я часто использую хранимые процедуры именно просто как хранилище SQL-кода. Просто для того, чтобы отделять SQL-код от Delphi-кода. И именно эту функциональность реализует данный класс. Но никак не полноценные хранимые процедуры, конечно.
И всё-таки интересно — есть ли лучший способ отделить SQL-скрипты от кода? Пока тут прозвучало только одно предложение, но, ИМХО, довольно бредовое ))
Разница в том, что она может содержать переменные и более чем один запрос.
Но я потому и назвал статью "Альтернатива хранимым процедурам".
И кто вам пообещал прогреес для науки? Это просто маленький лайфхак ))))
На вс. сл. — вопрос не стоит — почему именно борщ и почему именно лук. тут лишь рассказывается как резать этот самый лук в этот самый борщ! ))
Впрочем, я не настаиваю. Мне удобнее — так. Но на вкус и цвет… :)
А потом, статья ведь не о выборе СУБД совсем :)
Предложенное вами решение — крайне неудобно, ИМХО