Спасибо! :)
JavaScript и PHP в терминах нашей системы — навыки. Навыки не являются исключающими фильтрами, а учитываются при сортировке.
В данном случае ошибочно определённая космическая зарплата победила наличие навыка в процедуре ранжирования :)
Они ищут простым поиском по тексту вакансии, со всеми вытекающими. У нас вакансия анализируется и категоризируется для поиска по фильтрам.
В indeed вроде фильтр только по городу и ЗП. Даже по должности нет.
Про ORM. Они формируют строку SQL примерно так же, конкатенацией. Я не говорю, что во всех ORM есть уязвимость, я говорю о том, что её вероятность сравнительно с вероятностью инъекции при вызове ХФ высока. В первом случае есть потенциально опасное место — склейка строк, во втором — нет.
Никто не мешает писать хранимки на Java в Oracle, или на Python, JS и прочих в PostgreSQL.
Но моё ИМХО — если логика такая сложная, что реально требуется язык общего назначения — надо выносить.
Кстати, да! С Ms я мало общался, для Oracle проблем ни с ide, ни со статическим анализом нет, а вот для Pg нормальной IDE так и не нашел, все что есть — либо убоги, либо заточены только под администрирование, а нормальную разработку вести неудобно.
Можно. Но тут речь о том, что в этом случае никакого SQL injection быть не может (обычно).
А prepared statement сам по себе строка. Перед тем как вызвать prepare он где то формируется. Там и может быть injection.
У нас, например, применяется релизная схема. DDL объектов (и таблиц и функций) и скрипты миграции лежат в одном репозитории.
Я недавно публиковал статью с примером схемы, в которой это так реализовано. В том примере миграции нет правда.
Про хайлоад уточню — я говорю про проблемы с горизонтальным масштабированием. Как при использовании ХФ (с ними сделать шардинг сложней, если они были изначально на это не рассчитаны), так и вообще как общая проблема РСУБД.
Ну тут можно возразить, что компактность кода это конечно хорошо, но есть ещё много факторов, влияющих на оценку языка программистом. Декораторы, генераторы и прочие «плюшки» в языках общего назначения появляются раньше.
JavaScript и PHP в терминах нашей системы — навыки. Навыки не являются исключающими фильтрами, а учитываются при сортировке.
В данном случае ошибочно определённая космическая зарплата победила наличие навыка в процедуре ранжирования :)
В indeed вроде фильтр только по городу и ЗП. Даже по должности нет.
Но моё ИМХО — если логика такая сложная, что реально требуется язык общего назначения — надо выносить.
А prepared statement сам по себе строка. Перед тем как вызвать prepare он где то формируется. Там и может быть injection.
Я недавно публиковал статью с примером схемы, в которой это так реализовано. В том примере миграции нет правда.
Всегда храню код в файлах, файлы в системе контроля версий.
Опишите подробней, в чём проблема?