Итерирование будет происходить по тому результату, который вернула вам операция чтения. Если изменение произошло после этого, то вы его увидите только перечитав данные. Что, как мне кажется, логично.
У Кайта, уж прости, Оракл головного мозга, профессиональный перекос, да и говорил он это все уже давно. В текущих реалиях совет писать хранимку на джаве, а внешку на С, выглядит минимум странно — Spring со своим jdbcTemplate настолько упростил работу с БД, что даже странно смотреть куда-то еще :)
чем SQL не специализированный язык? Как раз специализированный язык для обработки данных
Ни в коем случае! Он, конечно, специализированный, но не для обработки — извлечение и обновление это не обработка. Это именно что подготовка data set для дальнейшей работы с ним. Pl/sql ведь так и возник — данные нужно было обрабатывать, а sql мог ими только манипулировать, да и то ограниченно.
Да так же, как везде — работает, пока не случается какой-нибудь вывернутый случай :D Если серьезно, то, к примеру, если мне нужно изменить какую-то сущность, то я вынимаю ее из hz, лочу, что б никто в параллельном потоке в это время мне не мог помешать, меняю все, что надо, укладываю обратно в hz. Разлочиваю. На всякий случай лок сам снимется через, к примеру, 500 миллисекунд, мало ли что-то встало колом. Как-то так. Нужно проапдейтить разом несколько сущностей — сначала лочу их все, потом все разлочиваю. try{}finally{} тут помогает. А редиска тут только для персистинга, на случай полного выключения сервера — где-то же данные нужно хранить долговременно…
Скажу честно, на поддержание работы хазелькаста у меня уходит ресурсов в разы меньше, чем уходило на поддержание схемы БД. Собственно когда окончательно достало, то OracleXE, который мы чисто по привычке вклячили в приложение, был выкинут нахрен, данные переведены в json и складированы в редиску, откуда забираются в хазелькаст, откуда уже заходят в код. С тех пор в моей душе мир и покой, поскольку хранение данных стало для меня прозрачным, понятным, а главное не требующим внимания. Понимаю, что мой случай не показатель, все же данных у меня, как таковых, не много — тысячи и десятки тысяч записей, а не миллионы и миллиарды, но, сдается мне, почти все приложения именно таковы…
Кеширование это лишние костыли которые, как я писал, могут привезти к ошибкам, которые даже юнит тестами не покроешь.
Кеширование — это не костыль, а потребность. Правильно выбранный кэш решает кучу проблем. К примеру hazelcast нам дает не просто кэш, но распределенный кэш. И это прекрасно!
Почему оно должно тормозить? БД сама по себе нагружает сервер, в то время, как голое Spring Boot приложение жрет около 15 мегабайт оперативки и 0 процессора. Запущенное на железе сопоставимом с сервером БД тормозить оно начнет весьма и весьма не скоро. Гораздо чаще мне попадались случаи, когда запросы вставали в очередь к БД и ждали, пока там раскочегарится pl/sql, поворочает данными, и таки уже вернет пару значений.
Откуда данные про 5%? Это выдавание желаемого за действительное — вся эта «экзотика» может занимать изрядную долю приложения.
можно написать на java, а обработку данных сам бог велел делать на SQL и PL/SQL
А почему бы не пойти дальше, и не написать на той же java за пределами Оракла? Нагружать сервер базы данных еще и работой jvm? Зачем? И чем вы будете пользоваться в «java over oracle» для менеджмента соединений? Куда будете логгировать? Все туда же, на сервер базы данных? А зачем себя так не любить, если можно взять Spring Boot, который замечательно запустится на соседнем сервере и не будет нагружать БД? Сделав этот первый логический шаг совершенно внезапно оказывается, что в java есть стримы, которые замечательно реализуют перебор коллекций, то есть то, что до сих пор делал pl/sql. Вот и БЛ переехала из хранилища данных поближе к внешним запросам от пользователей, что логично. Ну, и так далее… Это эволюция, времена, когда сервера приложений были дорогим и сложным удовольствием, а pl/sql и иже с ним простым и дешевым, прошли и теперь можно вернуть БД изначальное значение — хранить данные, поскольку для их лобработки уже есть более удобные средства.
Что значит «быстрее»? В контексте всего приложения может запросто получиться так, что имея локальный максимум производительности в БД вы в итоге получите глобальный минимум, поскольку бутылочным горлом станет коннект к БД.
А так вся программа как комплекс может работать в десятки раз быстрее, если она реализована в БД
Это ровно до тех пор, пока вся задача программы замыкается на данных из БД. То есть пока это «вещь в себе», к которой изредка кто-то обращается снаружи и просит дать кусочек результата работы — да, будет быстро и не напряжно. Все сломается об колено, как только появится потребность взаимодействовать с внешним миром, забирая оттуда данные, и совершая над ними действия, которые плохо ложаться в термины БД. Как на хранимках написать логику: «пойди к менеджеру ресурсов, возьми у него адрес актуального на данный момент поставщика данных, сходи к поставщику, запроси по websocket соединение, подпишись на такое-то событие, и жди его наступления в течение пяти секунд, после чего обработай полученные данные и сообщи, что они получены. Если за 5 секунд событие не наступило, то тихо закрой коннект и… ну, и так далее». Я, конечно, представляю, что все это можно реализовать через Аляску, с маппингом всего и вся в таблички, но поддерживать и развивать ЭТО будет невозможно.
Я правильно понял, что данный кусок кода должен включать И работу с данными, И «многопользовательский режим», что бы это ни значило, И контроль прав? Эту шутка такая? Три совершенно разные обязанности в одном куске кода могут встретиться только в виде обращений к трем нижележащим подсистемам реализующим эти обязанности, то есть в виде:
То есть public — это многословно, а разделение pl/sql пакета на спеку и тело, в которых код практически дублируется — это не многословно? :D А куча begin'ов и end'ов вместо скобок? Код на pl/sql совсем не лаконичный. Кстати, с появлением в java'е стримов перебирать коллекции стало одно удовольствие.
У меня даже теоретической идеи нет как можно дебажить декларативний язык.
План запроса ето и есть, как по мне, его дебаг. И чуть ли не базис скорости работы.
Речь шла про удобство и ограниченность дебага. Ну, вот оно, ограничение — прямо на дебаге понять почему тормозит запрос невозможно.
Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C# значить проще тестится
*глядит в портянки pl/sql, потом в свой уютненький java-код* Ээээ… Ладно, проехали :D
выбор Базы и знание нюансов не менне важен за выбор язика програмирования.
Ну, вот и закончился миф «Отладка кода на БД ничем не хуже/сложнее чем в VS» не успев начаться.
Можно сказать что отладка присутствует но ограничена.
Сразу вспомним, что в случае Оракла с его pl/sql мы еще на уровне БД имеем сплав двух языков — императивного pl/sql и декларативного sql, при этом худо-бедно дебажится только первый, дебага sql не предполагается. Все это мягко намекает, что утверждение
реализация бизнес логики на БД наиболее правильное место
«Устарел» в моем понимании значит «воспринимается практически, как догмат, хотя его давно пора переосмыслить». Я считаю, что в нынешних реалиях идея БД, как чуть ли не центрального звена, вокруг которого строится остальное приложение, себя изрядно изжила.
Все верно, только добавлю, что параллельно может происходить еще и наращивание функционала в коде сервера, примерно по тем же причинам. В итоге имеем ктулху-код в, например, java, ктулху-код а БД, и все это как бы один непрерывный кусок логики, разбираться в котором ну никак не из мечты.
Скорее речь идет об изоляции. То есть программируя на объектно-ориентированных языках мы почему-то свято чтим наследование-инкапсуляция-полиморфизм, и инкапсулируем сложность «под капот», всеми силами обеспечиваем слабую связность. Но когда дело доходит до баз данных это внезапно куда-то пропадает, и становится совершенно нормальным размазать одну логическую единицу тонким слоем от кода и до хранимок в БД, вместе с триггерами и джобами. Я к тому, что я не фанатик, и совершенно не против того, что бы использовать мощь БД на полную, но делать это так, как это делается en masse — значит закладывать под фундамент своего приложения жирнющую мину. И данная статья такой подход мало того, что пропагандирует, так еще и называет «единственно верным».
А что архитектура? В реальности «продумать логику еще на этапе создания схемы БД» большинству разработчиков и архитекторов покажется хорошей идеей, и не поможет пяток предыдущих проектов. Привычка — страшная сила, а «Oracle головного мозга» тем более.
Ни в коем случае! Он, конечно, специализированный, но не для обработки — извлечение и обновление это не обработка. Это именно что подготовка data set для дальнейшей работы с ним. Pl/sql ведь так и возник — данные нужно было обрабатывать, а sql мог ими только манипулировать, да и то ограниченно.
Да так же, как везде — работает, пока не случается какой-нибудь вывернутый случай :D Если серьезно, то, к примеру, если мне нужно изменить какую-то сущность, то я вынимаю ее из hz, лочу, что б никто в параллельном потоке в это время мне не мог помешать, меняю все, что надо, укладываю обратно в hz. Разлочиваю. На всякий случай лок сам снимется через, к примеру, 500 миллисекунд, мало ли что-то встало колом. Как-то так. Нужно проапдейтить разом несколько сущностей — сначала лочу их все, потом все разлочиваю. try{}finally{} тут помогает. А редиска тут только для персистинга, на случай полного выключения сервера — где-то же данные нужно хранить долговременно…
Кеширование — это не костыль, а потребность. Правильно выбранный кэш решает кучу проблем. К примеру hazelcast нам дает не просто кэш, но распределенный кэш. И это прекрасно!
А почему бы не пойти дальше, и не написать на той же java за пределами Оракла? Нагружать сервер базы данных еще и работой jvm? Зачем? И чем вы будете пользоваться в «java over oracle» для менеджмента соединений? Куда будете логгировать? Все туда же, на сервер базы данных? А зачем себя так не любить, если можно взять Spring Boot, который замечательно запустится на соседнем сервере и не будет нагружать БД? Сделав этот первый логический шаг совершенно внезапно оказывается, что в java есть стримы, которые замечательно реализуют перебор коллекций, то есть то, что до сих пор делал pl/sql. Вот и БЛ переехала из хранилища данных поближе к внешним запросам от пользователей, что логично. Ну, и так далее… Это эволюция, времена, когда сервера приложений были дорогим и сложным удовольствием, а pl/sql и иже с ним простым и дешевым, прошли и теперь можно вернуть БД изначальное значение — хранить данные, поскольку для их лобработки уже есть более удобные средства.
Что значит «быстрее»? В контексте всего приложения может запросто получиться так, что имея локальный максимум производительности в БД вы в итоге получите глобальный минимум, поскольку бутылочным горлом станет коннект к БД.
Это ровно до тех пор, пока вся задача программы замыкается на данных из БД. То есть пока это «вещь в себе», к которой изредка кто-то обращается снаружи и просит дать кусочек результата работы — да, будет быстро и не напряжно. Все сломается об колено, как только появится потребность взаимодействовать с внешним миром, забирая оттуда данные, и совершая над ними действия, которые плохо ложаться в термины БД. Как на хранимках написать логику: «пойди к менеджеру ресурсов, возьми у него адрес актуального на данный момент поставщика данных, сходи к поставщику, запроси по websocket соединение, подпишись на такое-то событие, и жди его наступления в течение пяти секунд, после чего обработай полученные данные и сообщи, что они получены. Если за 5 секунд событие не наступило, то тихо закрой коннект и… ну, и так далее». Я, конечно, представляю, что все это можно реализовать через Аляску, с маппингом всего и вся в таблички, но поддерживать и развивать ЭТО будет невозможно.
То есть public — это многословно, а разделение pl/sql пакета на спеку и тело, в которых код практически дублируется — это не многословно? :D А куча begin'ов и end'ов вместо скобок? Код на pl/sql совсем не лаконичный. Кстати, с появлением в java'е стримов перебирать коллекции стало одно удовольствие.
Речь шла про удобство и ограниченность дебага. Ну, вот оно, ограничение — прямо на дебаге понять почему тормозит запрос невозможно.
*глядит в портянки pl/sql, потом в свой уютненький java-код* Ээээ… Ладно, проехали :D
С этим никто спорить и не думал.
Ну, вот и закончился миф «Отладка кода на БД ничем не хуже/сложнее чем в VS» не успев начаться.
Сразу вспомним, что в случае Оракла с его pl/sql мы еще на уровне БД имеем сплав двух языков — императивного pl/sql и декларативного sql, при этом худо-бедно дебажится только первый, дебага sql не предполагается. Все это мягко намекает, что утверждение
несколько сомнительно.
Учитывая заголовок про «истину в последней инстанции» я бы не был так уверен :D
А какой отладчик PL/SQL нормально показывает коллекции? plsqlDeveloper не умел, когда я держал его в последний раз.
Скорее речь идет об изоляции. То есть программируя на объектно-ориентированных языках мы почему-то свято чтим наследование-инкапсуляция-полиморфизм, и инкапсулируем сложность «под капот», всеми силами обеспечиваем слабую связность. Но когда дело доходит до баз данных это внезапно куда-то пропадает, и становится совершенно нормальным размазать одну логическую единицу тонким слоем от кода и до хранимок в БД, вместе с триггерами и джобами. Я к тому, что я не фанатик, и совершенно не против того, что бы использовать мощь БД на полную, но делать это так, как это делается en masse — значит закладывать под фундамент своего приложения жирнющую мину. И данная статья такой подход мало того, что пропагандирует, так еще и называет «единственно верным».