Простите, не удержусь. Описание —

это примерно то же что и требование, только необязательное к исполнению

.

Спасибо за интересную статью. Заинтересовали некоторые моменты:

• Какие инструменты используете для хранения онтологии и работе с ней в процессе поиска.
• Собралась ли база синонимов ( Гипонимов и гиперонимов) вручную или этот процесс как-то автоматизирован.
• Как работаете со словарем ошибок и опечаток, он сгенерирован автоматически.

>Ну, не так уж чтоб совсем никакой
Если в базе не было внешних ключей (или других ограничений), то, наверное ценность есть) А вот если ключи были, дропнулись при генерации и не восстановились, то это скорее вред)
С ссылочной целостностью интересен скорее аспект, о котором вы выше говорили. То есть не просто соблюсти ограничения (этого ведь и перебором можно достичь), а попытаться смоделировать связи, распределение которых близко к реальному.

В контексте данного инструмента авторы описывают последний шаг: LOADS constraints that it had backed up (Mock-data can fail at this stage if its not able to fix the constraint violations). При этом в логе отражается, все ли ограничения были восстановлены.
В целом согласен с вами, что без ссылочной целостности генерация данных в общем-то ценности никакой не несет, даже если рассматривать кейс подобный моему, когда надо было быстро нагенерить данные для проверки работоспособности пользовательского интерфейса.

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

Раз уж пишут про форматы ФНС, дополню, что свои форматы публикует и ПФР, вот здесь: pfr.gov.ru/info/af
Другое дело, что во всех этих форматах с учетом истории их изменения и прочих вводных без пол-литры и не разберешь…

Да, тема очень широкая. Попробую уточнить то, что было бы интересно мне, как человеку с небольшим опытом:
1. Подход — в каких случаях и для решения каких задач обычно используете или пробовали использовать, но отказались. Иными словами ваше практический подход к вопросу бизнес-логики в БД.
2. Естественно интересны наборы рецептов или «трюков» на PL/pgSQL =)
3. Интересная тема триггерных функций
4. Ну и опыт того, как использование функций в запросах сочетается с поведение оптимизатора (IMMUTABLE/STABLE/VOLATILE в определении функций)

Спасибо за увлекательный цикл статей и explain.tensor.ru! Надеюсь, вы продолжите. Было бы интересно узнать об опыте использования триггеров и хранимых функций или же о причинах неиспользования.

Старое — не значит плохое. Я привел пример, чтобы подчеркнуть тенденцию к тому, что в массовом сознании возникает эквивалентность понятий ИИ и нейросетей. Конечно, с увеличением мощностей и количества данных нейросети получили колоссальное развитие. Однако, не располагаю информацией о больших успехах нейросетей в областях, в которых требуется обоснованный вывод или приведение цепочки рассуждений, приведших к результату.

Статья интересная в первую очередь постановкой вопроса. Ведь от вопроса «Слышали о языке Prolog?» один шаг до вопроса «Слышали о логическом программировании?», а дальше пара шагов до вопросов «Слышали о математической логике?» и «Слышали о реляционной теории?». На мой взгляд даже небольшой опыт работы с Prolog или Datalog сильно облегчает жизнь при работе с большинством мейнстримовых языков/фреймворков для работы с запросами к данным — SQL, LINQ, JPQL, GraphQL, да даже всяческие stream в Java и прочие *QL. Я уже не говорю о том, что работа с логическим выводом, цепочками рассуждений, продукционными системами многими вообще забыта. Помню, что в институте частенько слышал утверждение, что «Prolog — язык искусственного интеллекта», а в этом году слышал от членов жюри одного известного конкурса на гранты что «Если у вас нет нейросетей, а всего лишь какой-то набор формул (система продукционных правил), то о каком искусственном интеллекте вы говорите, ха-ха»

Ну одно да потому. Да, со связыванием переменных результаты будут другими, это именно то, для чего я и придумал этот пример. Почему вы решили, что я не понимаю, как он работает?

Я не говорил о вашем понимании или непонимании. В вашем примере возможность чтения «данных, которые ему знать не положено» отнесена к недостаткам SQL, в то время, как это недостаток избранного вами метода формирования запроса, который вы передаете СУБД. Аналогичным образом вы можете передать в функцию eval() код, полученный из входного строкового параметра и попенять на то, что у вас возникла возможность выполнения произвольного кода. Но претензии ведь не к eval(), а к методу его использования.

Я привел этот пример в ответ на утверждение:
«А по существу — аргумент всего один. В БД переносится только бизнес-логика, а не вся логика целиком. Взломанный бэк просто в принципе не может дропнуть базу или прочитать те данные, которые ему знать не положено.»

Опять-таки могу предложить вам модифицировать ваш пример так, чтобы во входной строке был не запрос на выборку данных, а какой-либо DML-оператор, и посмотреть на результат.

Основной метод чтения «данных, которые ему знать не положено» — это SQL-инъекция. Мой пример показывает, что даже если бизнес-логика в БД, то все равно существует возможность использовать SQL-инъекцию для чтения данных, которые знать не положено. Думаете хакер, который взломал бэк, будет связывание переменных использовать?

В этом утверждении я могу частично согласиться с вами, но что значить «хакер взломал бэк»? Если хакер путем формирования запросов выполнил произвольный SQL, то мы возвращаемся к вопросу о том, что параметры в БД надо передавать через связывание. Если же хакер имеет доступ к приложению, то скорее всего ему известны учетные данные подключения к БД и тут ситуация такова, что вопрос совсем не к использованию или неиспользованию хранимых процедур.

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

$id = $_GET['id'] ?? 0;
$sql = "CALL get_orders(" . $id . ")";
$pdo->exec($sql);

На что-то в таком духе:

$id = $_GET['id'] ?? 0;
$sql = "CALL get_orders(:id_param)";
$pdo->bindParam(':id_param', $id , PDO::PARAM_INT);
$pdo->exec($sql);

Результаты останутся теми же?

Хочу заметить, что, поскольку текст запроса вы собираете конкатенацией строк:

$id = $_GET['id'] ?? 0;
$sql = "CALL get_orders(" . $id . ")";

То при

$id="(SELECT 1 FROM users WHERE username='admin' AND password_hash LIKE 'qw%')"

Результирующая строка у вас будет следующей:

CALL get_orders((SELECT 1 FROM users WHERE username='admin' AND password_hash LIKE 'qw%'))

То есть сначала у вас выполниться вложенный запрос

(SELECT 1 FROM users WHERE username='admin' AND password_hash LIKE 'qw%')

, который вернет 1. Данное значение по типу соответствует параметру функции get_orders и будет передано на вход get_orders. При этом заказ с идентификатором 1 у вас добавлен в БД. Поэтому функция вернет истину. Если бы параметры передавались в запрос путем связывания, то ситуация была бы иной. А так, на вход СУБД пришел валидный запрос, который СУБД исполнила. Инъекция происходит как раз на уровне PHP

Например, даются такие разъяснения:
www.pfrf.ru/branches/spb/info/~vopros_otvet/2638
www.pfrf.ru/branches/spb/news~2015/01/23/83849
Не знаю, насколько соответствуют вашей ситуации

Выдача ИНН и СНИЛС иностранцам, приезжающим на временную сезонную работу тоже особо не нужна, только будет захламлять базы налоговой и ПФР.

Не захламлять, а, в случае ПФР, позволять учитывать пенсионные права)

Я вам больше скажу, встречаются люди, у которых два и более СНИЛС. Когда-то ПФР целенаправленно провел работу по объединению лицевых счетов тех, у кого СНИЛС дублировались, но случаи с дублями все-равно остались.