И, соответственно, любые операции по изменению таблицы также возможны, правильно понимаю?

да

Спасибо....

Вячеслав, ящитаю, с тебя пиво!

Привет всем.
Нуждаюсь в мнении профиссионалов, так как я сейчас обычный студент.
Раньше, если мне нужно было сделать приложение, то я использовал СУБД SQL Sever, ASP.NET фреймворк, шаблон MVC и архитектуру REST.
Можно сказать, что напрямую с SQL запросами я не работаю, т.е. работаю с объектами и просто выполняю миграции, а вывод у меня в json.
Но сейчас мне нужно сделать курсовой на FireBird с реляционной основой (без использования объектов), где нужно писать все на запросах.
Так вот вопрос в том, как правильно это сделать?
Я слышал мнение, что писать динамические запросы прямо в коде - это плохой тон, так как это создает понятие толстого клиента и гоняет много трафика.
Тогда получается, что все запросы нужно хранить непосредственно в самой БД на сервере (например, на выборку) и как - то обращаться к ним из кода? Если да, то как это граммотно сделать?
Хотя я себе слабо представляю, как например для добавления и обновления можно сделать готовые запросы, если в запрос полюбому нужно будет встраивать переменные.

🍺 Спасибо)) Угощаю ))

Я слышал мнение, что писать динамические запросы прямо в коде - это плохой тон, так как это создает понятие толстого клиента и гоняет много трафика.

Это бредни. Чушь.
Напиши запросы хоть как-то, как угодно, в общем, для учебного задания это нормально.
Но и для промышленного кода ничего плохого в этом нет (могут быть другие проблемы, связанные с этим, но может и не быть их)
Какого-то "правильного" способа писать запросы не существует. Можешь делать это на клиенте БД, или внутри БД в виде процедур, или как-то ещё.
Чего-то плохого в "толстом клиенте" как таковом тоже нет. Бывают разные архитектуры, они равночасто применяются.

Тогда получается, что все запросы нужно хранить непосредственно в самой БД на сервере

Вовсе не обязательно, но можно - в виде хранимых процедур, триггеров, view. Но они имеют некоторые ограничения.

как например для добавления и обновления можно сделать готовые запросы, если в запрос полюбому нужно будет встраивать переменные.

Можешь написать процедуру с параметрами, которая делает INSERT, и вызвать её с клиента, передавая параметры.

P.S. FireBird IMHO не лучший вариант для изучения, лучше бы тот же SQLServer, или MySQL  или Postgres.

Там ещё что-то добавили...

Искренне благодарю за потраченное время и развернутый ответ 👍

что касается промышленной системы, в ней все регулярные запросы (в том числе те, которые формируются клиентом динамически) должны быть строго сосчитаны и для каждого из них подготовлены соответствующие индексы для гарантированного быстродействия. поэтому то что ты написал не соответствует практике промышленного программирования.

типа "пиши, как бог на душу положит" - это бред, имхо

Согласен.
Но "не соответствует" вывод тоже неправильный.
То, что запрос "динамический" не определяет то, что он плохой, что под него нет индекса.

Для учебного задания даже полезно.

https://wiki.postgresql.org/wiki/Serializable
А вообще, почему Вы не спрашиваете там, где положено ответят с куда большей вероятностью ( https://t.me/pgsql )? ;)

Наоборот, IMHO. Точно так же, как и в "практике промышленного программирования" в целом.
И это правильно.

Например, товарищ пишет, что запросы могут гонять много данных.
Вот пусть напишет такой запрос и САМ УВИДИТ, почему так происходит, а не слушает сказки из сети.

И поймёт, что это — не из-за того, что запрос "динамический" на клиенте, а потому, что запрос плохой, или архитектура решения плохая.

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

Без разницы, как делать.

Я бы тебе советовал именно наклепать кучу, и, если ты увидишь, что это вдруг не работает, исправлять и делать как-то по другому.

Ну я думаю, что буду использовать домены, триггеры, хранимые процедуры по максимому)