История изменений
Исправление KivApple, (текущая версия) :
Про ORM плюсую.
Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.
Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.
Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.
Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).
А если никаких vendor-specific вещей не использовалось и сервис был простым, то может и на уровне SQL запросов хватить совместимости с незначительными изменениям.
По поводу защиты от SQL injection: просто не использовать СУБД и драйвера СУБД не умеющие в prepared statement и ни в коем случае не конкатенировать никаких пришедших извне вещей в SQL запрос. В 99% случаев использовать жёстко заданные запросы, в 1% случаев составлять запрос из заранее захардкоженных кусочков (например, когда нужна фильтрация по произвольному набору полей) и очень тщательно тестировать все граничные случаи.
Исправление KivApple, :
Про ORM плюсую.
Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.
Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.
Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.
Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).
А если никаких vendor-specific вещей не использовалось и сервис был простым, то может и на уровне SQL запросов хватить совместимости с незначительными изменениям.
По поводу защиты от SQL injection: просто не использовать СУБД и драйвера СУБД не умеющие в prepared statement и ни в коем случае не конкатенировать никаких пришедших извне вещей в SQL запрос. В 99% случаев использовать жёстко заданные запросы, в 1% случаев составлять запрос из заранее захардкоженных кусочков и очень тщательно тестировать все граничные случаи.
Исправление KivApple, :
Про ORM плюсую.
Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.
Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.
Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.
Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).
А если никаких vendor-specific вещей не использовалось и сервис был простым, то может и на уровне SQL запросов хватить совместимости с незначительными изменениям.
По поводу защиты от SQL injection: просто не использовать СУБД и драйвера СУБД не умеющие в prepared statement и ни в коем случае не конкатенировать никаких пришедших извне вещей в SQL запрос. В 99% случаев использовать жёстко заданные запросы, в 5% случаев составлять запрос из заранее захардкоженных кусочков и очень тщательно тестировать все граничные случаи.
Исправление KivApple, :
Про ORM плюсую.
Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.
Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.
Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.
Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).
А если никаких vendor-specific вещей не использовалось и сервис был простым, то может и на уровне SQL запросов хватить совместимости с незначительными изменениям.
Исходная версия KivApple, :
Про ORM плюсую.
Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.
Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.
Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.
Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).