Как я уже повторил много раз, в моем понимании это утверждение "Обычные crud операции можно реализовать как ХП". В моем крошечном мирке есть обычные crud операции. Значит это утверждение говорит, что в моем крошечном мирке их тоже можно реализовать как ХП. Поэтому у меня появился вопрос "Может и можно, но зачем в моем крошечном мирке это нужно?".
Я спрашивал не про ваши способности в принципе, а про ваше предложение "Может вы попробуете на PHP?". Пишите свою версию на SQL, выкладывайте, попробую на PHP. Сможете?
Увы, это происходит только в Вашем крошечном мирке.
В очередной раз повторяю, хотя не уверен, что вы способны это понять. Я как раз и спрашивал только про свой крошечный мирок. Потому что было утверждение, что я даже в своем крошечном мирке должен писать хранимые процедуры.
Вы хотите сказать, что с многогигабайтными таблицами работают не CRUD операциями? Какими же тогда?
"Обработка одним запросом нескольких десятков многогигабайтных таблиц" это не обычная CRUD-операция. Обычная среднестатистическая CRUD-операция работает с одной таблицей. Я это уже говорил, но видимо вы с одного раза не понимаете.
Вы можете иметь свое понимание слова "обычная", но я не обязан им пользоваться. Что я понимаю под словом "обычная", я повторил уже несколько раз.
А теперь дайте ссылку на СХД
Понятия не имею, как это связано с моими словами. Вы просили примеры, я привел примеры. У нас это была HBase.
- В этом проекте у нас вообще нет действий - Я видел ссылку на этот "проект".
Нет, я вам ссылку на наш проект не давал. И никто другой не давал. И доступа вам к нашей базе мы не давали. То, что вы описываете, это не наш проект.
И я всё время говорю о хранимых процедурах и функциях содержащих только CRUD операции.
Понятно, вы не хотите слушать собеседника. Мне это не интересно. Надеюсь, хотя бы код для тысяч документов сможете написать, как вы сами предложили ниже? Или тоже будете увиливать "Я говорил не про то, а про это, а вы не заметили"?
Это вам нужно читать внимательнее. Вы вырвали часть предложения из контекста и пытаетесь ей что-то доказывать. Можно еще буквы в словах переставить, чтобы получились другие слова.
Слово "исключения" подразумевает, что это исключение из "чего-то". Это указано в первой части, которую вы не процитировали: "ситуации или утверждения, которое применимо в большинстве условий или контекстов". Утверждение "Запрос содержит одновременно INSERT и DELETE" верно для большинства конкретных запросов? Нет.
В общем, я привел определение, по которому можно понимать так, как понял я. Может быть в вашем смысле оно тоже где-то употребляется, но это ничего не меняет. Это оффтоп, не вижу смысла об этом спорить.
Мое предложение сделано для проверки утверждения "Хранимые процедуры не сложнее в поддержке, чем код в приложении". Ваше предложение его ни подтвердит, ни опровергнет, поэтому нельзя сказать, что это "наоборот". Видимо вы возражаете на какое-то другое утверждение, не очень понятно на какое.
Если хотите, можем и это проверить. Делайте скрипт для заполнения базы или дамп в архиве, описание задачи и процедуру с запросом. Попробую сделать такую же логику в приложении как будет время, проверим, насколько приложение будет медленнее.
Я уже указывал выше: "пользователей только 1С в РФ свыше 8 миллионов.
А я указывал выше, что это не имеет никакого отношения к теме необходимости процедур в БД конкретного проекта. Я серьезно не понимаю, с какой целью вы повторяете одно и то же, игнорируя ответы.
что для того, что доказать, что "хранимые процедуры не нужны"
Я не собирался доказывать, что "хранимые процедуры не нужны". Я задал вопрос "Зачем их писать для обычных crud операций?". Если вы не можете на него ответить, то просто не отвечайте, не надо флудить пожалуйста.
Не надо сравнивать количество проектов. И я указывал почему: "более мелкие предприятия ..."
С моей точки зрения эти утверждения никак не связаны, и фраза про предприятия не является ответом на вопрос "почему". Меня не интересуют мелкие предприятия, когда я принимаю решение, делать ли процедуры в БД для нового проекта.
А то, что Вы ни разу не встречали запросы от ORM, которые выполняются десятки минут ... - ничего хорошего о Вашем опыте не говорит.
Не вижу логики в этом утверждении. Хорошо, что я не работал с настолько плохими проектами.
Я указывал, что в природе нет пока ORM, которые всегда формируют оптимальные для СУБД запросы.
Понятия не имею, зачем вы это указывали, я про это не спрашивал. Я спрашивал, зачем надо усложнять код, чтобы делать оптимальные для СУБД запросы, для случаев когда даже неоптимальные занимают меньше секунды.
- Как из этого следует, что мне надо писать свои обычные crud операции в хранимых процедурах? - Ну если Вы сами это придумали, то сами отвечайте.
Так, вы похоже вообще не понимаете, о чем идет речь. Объясняю. Пользователь N4N в этом комментарии сделал утверждение "Обычные crud операции можно реализовать как ХП, и вызывать их, просто передавая параметры в ХП". Я спросил его "Зачем?" Потом в ветку приперлись вы и начали рассказывать про кластеры на десятки миллионов путей в графе и количество пользователей 1С.
Этот вопрос я не придумал в прошлом комментарии, а он был изначально, и задавал я его не вам. Если не хотите на него отвечать, не отвечайте, никто вас не заставляет.
Пользователи, простите, не в "админке" по одной записи сохраняют, а документы, сохранение которых требует длительных расчетов, модификаций БД и обширной транзакции.
Это ложь, у нас есть пользователи, которые в "админке" сохраняют по одной записи, и именно про эти случаи я и спрашивал. Более того, у нас некоторые сервисы даже в большинстве продакшн-действий сохраняют только одну запись в БД.
Хранимая процедура или функция может быть содержать не только CRUD операции.
Ё-моё, еще раз повторяю - меня не интересуют такие случаи, я задавал вопрос про противоположный случай.
Очень самокритично. Даже тупое сохранение одной строки заголовка и нескольких десятков строк деталей одним запросом потребует больше времени.
Ну не верите, не надо. Это измерения для простой CRUD-операции SELECT. В этом проекте у нас вообще нет действий, которые сохраняют несколько десятков строк в одной транзакции.
- Если у вас какая-то сложная обработка данных, то не проще ли ее распараллелить в коде приложения на 1000 потоков? ... - Какое отношение вычислительные задачи, от которых безусловно нужно разгружать СУБД, имеют отношение к "1000 соединений с СУБД" или к загрузке "десяток терабайт из БД в приложение"?
Потому что мое утверждение, для которого вы спрашивали примеры, было про такие задачи.
Ресайзинг изображений - запускаем 1000 процессов, они подключаются к базе, загружают каждый свою часть ссылок в память приложения, делают ресайзинг параллельно, ссылки на обработанные изображения сохраняют обратно в БД. Решение задачи коммивояжера - аналогично. Индексация для полнотекстового поиска - Делаем 100 воркеров, они читают по 20000 записей за раз из хранилища в память приложения, декодируют JSON, извлекают нужные поля, формируют XML, отдают в stdout, к которому подключен stdin движка sphinx, читают еще 20000. Записей было несколько миллиардов, количество терабайт сами оцените.
Но Вы это упорно игнорируете.
Это вы игнорируете то, что я вам повторил уже много раз - меня не интересуют многогигабайтные таблицы, утверждение в начальном комментарии было про обычные crud операции, поэтому и мой вопрос был про обычные crud операции. Зачем люди используют процедуры для многогигабайтных таблиц, я и так знаю.
Я привел пруф-линк на общепринятое определение, оно подтверждает мои слова. Вы пруф с вашим определением не привели, поэтому такое толкование этого выражения это ваши выдумки.
то извольте учесть в ней все возможные случаи
Вот если бы вы сказали "В общем случае запрос может содержать все операторы", то и вопросов бы не было. А вы сказали ""В общем случае запрос содержит". Нет, не содержит. Хотя и может.
"Общий случай" это то, что является общим для частных случаев. Характеристика "может содержать" является общей для разных конкретных запросов. Характеристика "содержит" не является.
Прежде чем указывать другим на знание семантики, надо бы сначала проверить самому.
Значение слова "в общем случае" "В общем случае" - это выражение, используемое для описания ситуации или утверждения, которое применимо в большинстве условий или контекстов, но может иметь исключения или требовать уточнений для конкретных случаев.
Синонимы «в общем случае»: в целом, как правило, обычно.
"В общем случае запрос содержит" это синоним "Обычно запрос содержит". Именно поэтому ваше утверждение ложно, обычно запрос не содержит все эти операторы сразу.
Вот именно что вариант с загрузкой рекордсета короче и нагляднее. Во-первых, по количеству символов. Во-вторых, в приложении есть либо автоподгрузка exampleEntityList при первом обращении без репозитория, либо уже существующий метод репозитория ExampleEntityRepository::findAllByEmpoyee(Employee employeeEntity). А с запросом "ORDER BY score DESC" надо делать в репозитории новый метод.
Так это ж не один селект, а два с подзапросом и копипастой условий в WHERE. Это далеко не "вместо [простого] select max()". Вполне логично, что разработчикам эта портянка показалась сложнее условного employeeEntity.exampleEntityList.sort((a, b) => b.score - a.score).first()
Другое дело, что это можно решить и запросом, только без select max().
SELECT * FROM example_table WHERE empl = 123 ORDER BY score DESC, id DESC LIMIT 1
ExampleEntity.find().where('empl', '=', 123).orderByDesc('score', id').limit(1).one()
Потому что вы высказываете критику этого подхода, а критика означает, что вы с этим не согласны, и считаете, что правильно делать по-другому.
В PHP-проектах отдельного DBA либо нет, и программисты всё делают сами, либо он просто утверждает запрос, который составил программист, а если что-то тормозит, то дает задачи программистам как переписать запрос. Программисты всегда сами ответственны за работу приложения, роль DBA консультационная, никто его не просит магически оптимизировать базу. На промышленной нагрузке всё работает нормально.
Я лично за то, чтобы бизнес-логика была вынесена из СУБД
То есть вы считаете, что правильно выбирать вариант, который по вашим словам не масштабируем, будет существенно дороже, и в котором в случае существенного роста объёмов и нагрузки будут проблемы? Непонятно, почему это правильно.
Я прямо написал, почему стоит сомневаться в существовании ШМ
Ну а я написал, что с обычной молнией было то же самое)
Тут очевидно что-то не сходится.
Ну как это не сходится, если вы сами говорите, что даже гипотетические условия ее возникновения неизвестны. Как можно воспроизвести в лаборатории что-то неизвестное? Только случайно. Судя по описаниям, для ее возникновения нужны большие напряжения, которые сложно воспроизвести в лаборатории.
Если говорить о вероятностях, то вероятность того, что все одинаково врут, на мой взгляд, сильно меньше вероятности того, что это пузырь сильно раскаленной материи.
Будь это действительно распространенное явление атмосферного электричества, его давно бы уже изучили под микроскопом, препарировали, воспроизвели
Да нет, необязательно. Интеллект это довольно распространенное явление, но воспроизвести его в компьютере пока не получилось. Торнадо тоже малоизучены, хотя случаются чаще ШМ.
https://habr.com/ru/articles/210620/ В журнале «Physical Review Letters» была опубликована статья китайских учёных, которым удалось летом 2012 года заснять шаровую молнию во время наблюдений за обычными молниями. (упоминается и в этой статье)
https://www.gazeta.ru/science/2006/06/09_a_660475.shtml Немецкие ученые из Института плазменной физики имени Макса Планка и университета Гумбольдта сумели с помощью подводных электрических зарядов породить в лабораторных условиях шаровую молнию диаметром 20 см.
https://zoom.cnews.ru/rnd/news/top/poluchena_samaya_dolgozhivushchaya_sharovaya_molniya Группе бразильских ученых удалось получить в лабораторных условиях шаровую молнию. Чтобы проверить верность этой теории, группа ученых поместила кремниевую пластину толщиной всего 350 мкм между двумя электродами. В результате образовывались светящиеся шары размером с шарик для игры в пинг-понг, время жизни которых составляло до 8 с.++
Так мы же говорим не про научное подтверждение существования ШМ, а про "причины всерьез допускать существование ШМ". Рассказы родственников, у которых нет причин врать или склонности так шутить, с одинаковым описанием у всех, это достаточная причина допускать существование.
Как я уже повторил много раз, в моем понимании это утверждение "Обычные crud операции можно реализовать как ХП". В моем крошечном мирке есть обычные crud операции. Значит это утверждение говорит, что в моем крошечном мирке их тоже можно реализовать как ХП. Поэтому у меня появился вопрос "Может и можно, но зачем в моем крошечном мирке это нужно?".
Не знаю, зачем вы показываете мне пример без select max(), когда мой вопрос был про select max(). Как сделать без select max() я и сам знаю.
Я спрашивал не про ваши способности в принципе, а про ваше предложение "Может вы попробуете на PHP?". Пишите свою версию на SQL, выкладывайте, попробую на PHP. Сможете?
В очередной раз повторяю, хотя не уверен, что вы способны это понять. Я как раз и спрашивал только про свой крошечный мирок. Потому что было утверждение, что я даже в своем крошечном мирке должен писать хранимые процедуры.
"Обработка одним запросом нескольких десятков многогигабайтных таблиц" это не обычная CRUD-операция. Обычная среднестатистическая CRUD-операция работает с одной таблицей. Я это уже говорил, но видимо вы с одного раза не понимаете.
Вы можете иметь свое понимание слова "обычная", но я не обязан им пользоваться. Что я понимаю под словом "обычная", я повторил уже несколько раз.
Понятия не имею, как это связано с моими словами. Вы просили примеры, я привел примеры. У нас это была HBase.
Нет, я вам ссылку на наш проект не давал. И никто другой не давал. И доступа вам к нашей базе мы не давали. То, что вы описываете, это не наш проект.
Понятно, вы не хотите слушать собеседника. Мне это не интересно.
Надеюсь, хотя бы код для тысяч документов сможете написать, как вы сами предложили ниже? Или тоже будете увиливать "Я говорил не про то, а про это, а вы не заметили"?
Это вам нужно читать внимательнее. Вы вырвали часть предложения из контекста и пытаетесь ей что-то доказывать. Можно еще буквы в словах переставить, чтобы получились другие слова.
Слово "исключения" подразумевает, что это исключение из "чего-то". Это указано в первой части, которую вы не процитировали: "ситуации или утверждения, которое применимо в большинстве условий или контекстов". Утверждение "Запрос содержит одновременно INSERT и DELETE" верно для большинства конкретных запросов? Нет.
В общем, я привел определение, по которому можно понимать так, как понял я. Может быть в вашем смысле оно тоже где-то употребляется, но это ничего не меняет. Это оффтоп, не вижу смысла об этом спорить.
В нашем MySQL нет такой конструкции. В ненашем MS SQL, говорят, тоже нет.
"select max()", насколько я понимаю, в таком запросе тоже не будет.
Мое предложение сделано для проверки утверждения "Хранимые процедуры не сложнее в поддержке, чем код в приложении". Ваше предложение его ни подтвердит, ни опровергнет, поэтому нельзя сказать, что это "наоборот". Видимо вы возражаете на какое-то другое утверждение, не очень понятно на какое.
Если хотите, можем и это проверить. Делайте скрипт для заполнения базы или дамп в архиве, описание задачи и процедуру с запросом. Попробую сделать такую же логику в приложении как будет время, проверим, насколько приложение будет медленнее.
Я их привел в одном из комментариев выше.
А я указывал выше, что это не имеет никакого отношения к теме необходимости процедур в БД конкретного проекта.
Я серьезно не понимаю, с какой целью вы повторяете одно и то же, игнорируя ответы.
Я не собирался доказывать, что "хранимые процедуры не нужны". Я задал вопрос "Зачем их писать для обычных crud операций?". Если вы не можете на него ответить, то просто не отвечайте, не надо флудить пожалуйста.
С моей точки зрения эти утверждения никак не связаны, и фраза про предприятия не является ответом на вопрос "почему".
Меня не интересуют мелкие предприятия, когда я принимаю решение, делать ли процедуры в БД для нового проекта.
Не вижу логики в этом утверждении. Хорошо, что я не работал с настолько плохими проектами.
Понятия не имею, зачем вы это указывали, я про это не спрашивал.
Я спрашивал, зачем надо усложнять код, чтобы делать оптимальные для СУБД запросы, для случаев когда даже неоптимальные занимают меньше секунды.
Так, вы похоже вообще не понимаете, о чем идет речь. Объясняю.
Пользователь N4N в этом комментарии сделал утверждение "Обычные crud операции можно реализовать как ХП, и вызывать их, просто передавая параметры в ХП".
Я спросил его "Зачем?"
Потом в ветку приперлись вы и начали рассказывать про кластеры на десятки миллионов путей в графе и количество пользователей 1С.
Этот вопрос я не придумал в прошлом комментарии, а он был изначально, и задавал я его не вам. Если не хотите на него отвечать, не отвечайте, никто вас не заставляет.
Это ложь, у нас есть пользователи, которые в "админке" сохраняют по одной записи, и именно про эти случаи я и спрашивал.
Более того, у нас некоторые сервисы даже в большинстве продакшн-действий сохраняют только одну запись в БД.
Ё-моё, еще раз повторяю - меня не интересуют такие случаи, я задавал вопрос про противоположный случай.
Ну не верите, не надо. Это измерения для простой CRUD-операции SELECT.
В этом проекте у нас вообще нет действий, которые сохраняют несколько десятков строк в одной транзакции.
Потому что мое утверждение, для которого вы спрашивали примеры, было про такие задачи.
Ресайзинг изображений - запускаем 1000 процессов, они подключаются к базе, загружают каждый свою часть ссылок в память приложения, делают ресайзинг параллельно, ссылки на обработанные изображения сохраняют обратно в БД.
Решение задачи коммивояжера - аналогично.
Индексация для полнотекстового поиска - Делаем 100 воркеров, они читают по 20000 записей за раз из хранилища в память приложения, декодируют JSON, извлекают нужные поля, формируют XML, отдают в stdout, к которому подключен stdin движка sphinx, читают еще 20000. Записей было несколько миллиардов, количество терабайт сами оцените.
Это вы игнорируете то, что я вам повторил уже много раз - меня не интересуют многогигабайтные таблицы, утверждение в начальном комментарии было про обычные crud операции, поэтому и мой вопрос был про обычные crud операции. Зачем люди используют процедуры для многогигабайтных таблиц, я и так знаю.
Я привел пруф-линк на общепринятое определение, оно подтверждает мои слова. Вы пруф с вашим определением не привели, поэтому такое толкование этого выражения это ваши выдумки.
Вот если бы вы сказали "В общем случае запрос может содержать все операторы", то и вопросов бы не было. А вы сказали ""В общем случае запрос содержит". Нет, не содержит. Хотя и может.
"Общий случай" это то, что является общим для частных случаев. Характеристика "может содержать" является общей для разных конкретных запросов. Характеристика "содержит" не является.
Прежде чем указывать другим на знание семантики, надо бы сначала проверить самому.
Значение слова "в общем случае"
"В общем случае" - это выражение, используемое для описания ситуации или утверждения, которое применимо в большинстве условий или контекстов, но может иметь исключения или требовать уточнений для конкретных случаев.
Синонимы «в общем случае»: в целом, как правило, обычно.
"В общем случае запрос содержит" это синоним "Обычно запрос содержит". Именно поэтому ваше утверждение ложно, обычно запрос не содержит все эти операторы сразу.
Вот именно что вариант с загрузкой рекордсета короче и нагляднее. Во-первых, по количеству символов. Во-вторых, в приложении есть либо автоподгрузка exampleEntityList при первом обращении без репозитория, либо уже существующий метод репозитория
ExampleEntityRepository::findAllByEmpoyee(Employee employeeEntity). А с запросом "ORDER BY score DESC" надо делать в репозитории новый метод.Так это ж не один селект, а два с подзапросом и копипастой условий в WHERE. Это далеко не "вместо [простого] select max()". Вполне логично, что разработчикам эта портянка показалась сложнее условного
employeeEntity.exampleEntityList.sort((a, b) => b.score - a.score).first()Другое дело, что это можно решить и запросом, только без select max().
Потому что вы высказываете критику этого подхода, а критика означает, что вы с этим не согласны, и считаете, что правильно делать по-другому.
В PHP-проектах отдельного DBA либо нет, и программисты всё делают сами, либо он просто утверждает запрос, который составил программист, а если что-то тормозит, то дает задачи программистам как переписать запрос. Программисты всегда сами ответственны за работу приложения, роль DBA консультационная, никто его не просит магически оптимизировать базу. На промышленной нагрузке всё работает нормально.
То есть вы считаете, что правильно выбирать вариант, который по вашим словам не масштабируем, будет существенно дороже, и в котором в случае существенного роста объёмов и нагрузки будут проблемы? Непонятно, почему это правильно.
Ну а я написал, что с обычной молнией было то же самое)
Ну как это не сходится, если вы сами говорите, что даже гипотетические условия ее возникновения неизвестны. Как можно воспроизвести в лаборатории что-то неизвестное? Только случайно. Судя по описаниям, для ее возникновения нужны большие напряжения, которые сложно воспроизвести в лаборатории.
Если говорить о вероятностях, то вероятность того, что все одинаково врут, на мой взгляд, сильно меньше вероятности того, что это пузырь сильно раскаленной материи.
Да нет, необязательно. Интеллект это довольно распространенное явление, но воспроизвести его в компьютере пока не получилось.
Торнадо тоже малоизучены, хотя случаются чаще ШМ.
https://habr.com/ru/articles/210620/
В журнале «Physical Review Letters» была опубликована статья китайских учёных, которым удалось летом 2012 года заснять шаровую молнию во время наблюдений за обычными молниями.
(упоминается и в этой статье)
https://www.gazeta.ru/science/2006/06/09_a_660475.shtml
Немецкие ученые из Института плазменной физики имени Макса Планка и университета Гумбольдта сумели с помощью подводных электрических зарядов породить в лабораторных условиях шаровую молнию диаметром 20 см.
https://zoom.cnews.ru/rnd/news/top/poluchena_samaya_dolgozhivushchaya_sharovaya_molniya
Группе бразильских ученых удалось получить в лабораторных условиях шаровую молнию.
Чтобы проверить верность этой теории, группа ученых поместила кремниевую пластину толщиной всего 350 мкм между двумя электродами. В результате образовывались светящиеся шары размером с шарик для игры в пинг-понг, время жизни которых составляло до 8 с.++
https://www.gazeta.ru/science/2024/04/02/18492409.shtml
Физики МГУ смогли получить миниатюрные шаровые молнии в лаборатории
То есть до того, как наука объяснила, что молния это электричество, надо было считать ее несуществующим явлением?
Так не расходятся же, наука не опровергает возможность существования шаровой молнии.
Но они менее вероятны, чем то, что была причина, по которой люди видят одновременно одно и то же.
Так мы же говорим не про научное подтверждение существования ШМ, а про "причины всерьез допускать существование ШМ". Рассказы родственников, у которых нет причин врать или склонности так шутить, с одинаковым описанием у всех, это достаточная причина допускать существование.