Комментарии 109
Просто закомитьте этот DDL, запустите сборку и наслаждайтесь обновленным объектом
И тут же отправляйтесь в путешествие по устранению ошибок компиляции в места, где использовалось старое имя поля (title), а также исправления названия поля в соответствующем dto объекте, если таковой есть. Вместо этого, можно было просто поменять название колонки в аннотации @Column(«book_title»). Наверное, это не совсем правильно, но иногда такое сильно проще и дешевле.
Вы так говорите как будто это плохо.
Лучше получить ошибку компиляции, чем "sql error" в рантайме.
А, кроме того, в них самих может запросто использоваться указанная выше кодогенерация. Почему нет, религия не против.
Не всё так однозначно. И нагрузка разная бывает, и данные, и требования к их целостности, актуальности, и куча ещё всего.
Т.е. я понимаю, что реляционные БД в принципе не способны на бесконечное горизонтальное масштабирование, но внезапно может оказаться, что бесконечно и не надо.
Чтобы не быть голословным, есть такой сайтик популярный — stackoverflow.com. Так вот у него в сердце MS SQL Server. Пруф: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition
SQL не серебряная пуля, также как и noSQL. Каждому гвоздю свой молоток.
Так в статье же речь про single source of truth. Вполне себе нормальная история основные данные держать в одной базе, а для полнотекстового поиска выгружать в другую, сильно более заточенную на, собственно, полнотекстовый поиск.
Как там у SO это сделано я не знаю, но вообще, при большом желании Elastic можно дропнуть и перестроить, и сервис скорее всего в это время испытает gracefull degradation — из гуглового поиска попасть можно будет (а это думаю большая часть их трафика), а из внутреннего, пока индекс не перестроится — нет. Ну, а учитывая, что это что-то вроде ЧП, то в общем-то и не страшно сильно.
А микросервисная архитектура наоборот позволяет использовать каждую СУБД на всю катушку в изолированных сервисах.
Статья (насколько я ее понимаю) немного о другом — изолировать использование конкретной СУБД в каком-нибудь изолированном слое или микросервисе и использовать все ее ништяки, которые она предоставляет.
А hype-driven development пусть идёт лесом.
Я считаю, что в нынешних реалиях идея БД, как чуть ли не центрального звена, вокруг которого строится остальное приложение, себя изрядно изжила.
Согласен, но статья вроде этого и не утверждает.
Идея в том, что объектная модель живет и развивается отдельно, а модель БД отдельно, и где-то они встречаются.
но статья вроде этого и не утверждает.
Учитывая заголовок про «истину в последней инстанции» я бы не был так уверен :D
Вместо «Java[любой другой язык] first» подхода, который выведет вас на длинную дорожку, полную боли и страданий, как только проект начнет расти.
До чего категорично-то… А как насчет длинной дорожки танцев «от базы», которая в итоге приведет к тому, что приложение зависит от БД чуть более чем полностью, потому что изрядная часть логики переползла именно туда? Я не раз и не два наблюдал, как функционал, который начинался, как «select с обработкой» постепенно превращался сначала в «сложные select с триггерами с последующей обработкой», а потом и в «сложные select с триггерами и прочими джобами, а так же кучей хранимых процедур с последующей обработкой или даже без оной». После чего приложения вырождались по сути дела до гейтов к базе, в которой была сосредоточена вся логика. Естественно никто уже толком не понимал, как это все работает, и уж точно не мог нормально наращивать функционал. Вот такая по моему опыту цена проектирования «от базы».
очень сложно танцуя «от схемы» не начать закладывать в эту схему логику
А как же архитектура, code review и все такое?
ну и еще нанимают ДБА или SQL разработчика, потому что <подставьте язык сами> разрабочики плохо знают тонкости используемой на проекте СУБД, а бывает что и вовсе разучились SQL запросы писать.
Так что учитывать интересы базы рано или поздно придется, от этого никуда не уйти, но тут важно найти разумный компромис.
но тут важно найти разумный компромис
Скорее речь идет об изоляции. То есть программируя на объектно-ориентированных языках мы почему-то свято чтим наследование-инкапсуляция-полиморфизм, и инкапсулируем сложность «под капот», всеми силами обеспечиваем слабую связность. Но когда дело доходит до баз данных это внезапно куда-то пропадает, и становится совершенно нормальным размазать одну логическую единицу тонким слоем от кода и до хранимок в БД, вместе с триггерами и джобами. Я к тому, что я не фанатик, и совершенно не против того, что бы использовать мощь БД на полную, но делать это так, как это делается en masse — значит закладывать под фундамент своего приложения жирнющую мину. И данная статья такой подход мало того, что пропагандирует, так еще и называет «единственно верным».
Скорее речь идет об изоляции. То есть программируя на объектно-ориентированных языках мы почему-то свято чтим наследование-инкапсуляция-полиморфизм, и инкапсулируем сложность «под капот», всеми силами обеспечиваем слабую связность. Но когда дело доходит до баз данных это внезапно куда-то пропадает, и становится совершенно нормальным размазать одну логическую единицу тонким слоем от кода и до хранимок в БД, вместе с триггерами и джобами.
рискну предположить (хотя случаи могут быть разными) — все это размазывание было проведено в ходе N-го количества оптимизаций со стороны базы данных. Дело в том, что я многократно наблюдал как при написании логики в базе данных пытались использовать часть принципов ООП — оно все хорошо, красиво, удобно, проще поддерживать… НО, рано или позно приходят они… тормоза…
То ли это какой-то отчет использующий очень навороченую вьюху на все случаи жизни, в которой есть все что нужно и не нужно париться и особо мудрить. Или же это какая-то аггрегация которая использует функции для каких-то вычислений, в которые упрятанна с глаз долой забористая логика. И все, приехали, вариант один — разворачивать функции-вьюхи, выкидывать все ненужное, а все нужное писать так что бы было максимально быстро. вот после таких оптимизаций логика реализованая в БД может быть весьма тяжело читаемой.
Впрочем, причины могут быть и более тривиальные — в целях экономии времени в процедуру\функцию\триггер вставляют if else с нужным кодом, вместо того что бы переписать процедуру под новые требования. И со временем почти вся процедура слеплена из таких кусков, и без вдумчивого дебага уже непонять что там происходит. Но почему такое происходит не загадка — лень и дедлайны, на то что бы сделать по нормальному, а потом еще и провести хорошее тестирование может потребоваться слишком много времени. Справделивости ради стоит сказать что такое характерно и для ООПшных языков программирования.
В общем, возвращаясь к исходной точке — для БД либо шашечки, либо ехать (либо принципы ООП, либо скорость выполнения)
З.Ы. это моя ИМХА за 13 лет собраная на своем и опыте коллег
Ну и поддерживается Oracle, MS SQL и Sybase
Т.е. поддерживается только какая-та общая функциональность всех этих СУБД? (Без специфичных опций каждой СУБД)
Я не понимаю как ситуация принципиально ухудшается при использовании ORM ведь всегда можно изменения внести в production и ручным способом (как в database first). У тебя же никто не забирает любимый мячик, а просто еще один подкидывают (сгенерированные миграции для простых случаев).
По кодогенерации сам пользуюсь php / symfony / doctrine. Очень удобно делать миграции. Т.к. сравнивается текущая структура базы данных и генерируется код который из текущей струткуры преобразует в нужноую структуру. Кстати был (и есть) у меня один проект который разработчики начали базу менять без автогенерируемых миграций и на тот момент кодга я это проект принял база уже в нескольких объектах разошлась с кодом. (В основном оставались лишние поля и таблицы) После этого првел все один раз в порядок и пользуюсь только автогенерируемыми миграциями.
Но например я не знаю аналогичной функциональности для node.js. Аналогично я как понял из статьи что аналогичного функционала нет и в java ORM-ках.
А если пойти путём доработки маппинга Doctrine (есть возможности расширения), то теряем возможность автогенерации
Все записит от того как дорабатывать маппинг. Например когда мне потребовались json документы то я заюзал github.com/dunglas/doctrine-json-odm Все ралидовант там так что автогенерация работет правильно (даже не могу понять почему т.к. код бандла очень лаконичный и не имеет прямого выхода на генерацию SQL видимо автор очень удачно использовал какие-то умолчания действующие в doctrine)
Аналогично я как понял из статьи что аналогичного функционала нет и в java ORM-ках.
Почему же, Hibernate умеет.
Еще есть всякие интересные штуки (https://github.com/perseas/Pyrseas и github.com/CourseOrchestra/2bass), которые позволяют выгрузить в какой либо формат, подправить там что нужно, а потом эта штука найдет изменения и сгенерит нужные alter'ы.
1. Вы изменяете программный код Entity
2. Вы запускаете консольную команду которая генерирует скрипт с двумя функциями up() и down() сравнивая вашу текущую реальную базу данных с Entity
3. Вы по желанию добавляете дополнительно свой код (например задаете значения для добавленных полей и т.п.)
4. Вы при деплое запускаете скрипт миграции
5. Скрипт запускает все текущие миграции в порядке их определения. И следит чтобы это сделано было ровно один раз.
6. Также можно откатить миграцию.
То есть вопрос не в том что механизм миграций есть, а в том что он надежный и удобный. Если бы я не был уверен в каком-то из шагов что он пройдет без проблем я бы не рискнул пользоваться встроенными средствами.
Я не утверждаю что этого нет нигде больше. Я просто хочу показать в каких случаях это действительно бывает удобно. Я например сейчас в процессе поиска чего-то подобного на Go и если кто-нибудь значет где модно найти подобный встроенный функционал то прошу подсказать.
WARNING: AutoMigrate will ONLY create tables, missing columns and missing indexes, and WON’T change existing column’s type or delete unused columns to protect your data.
Вот например доки к GORM. И в чем тут прикол? Что вам фреймверк перестроит схему ничего не гарантируя и н давая контролль над процессом
Ну и в целом при работе с Doctrine нельзя просто забыть, что под капотом СУБД. Нужно помнить и о СУБД, и о самой Doctrine. И о том, что Doctrine не позволяет описать точную схему целевой БД. А иногда настойчиво мешает, пытаясь удалять то, что она не видит в своем описании, но что нужно нам, и наоборот.
«Лишние» миграционные скрипты у меня тоже когда я принял проект были. Потом посмотрел почему этот код появлялся. В некоторых случаях просто добавил нужную аннотацию в Entity. В некоторых случаях рабобрался что та таблица которую предлоагали удалить дйствительно нигде не исползуется ( и к том же была пустая). Но если уже перезодить на «ручное управление» — то тогда все преимущества превращаются в недостатки. Т.к. где-то появилось напрмер очень важное но отсутсвующее в Entity поле и ничего не ведающий человек которому получили таск очередной раз забудет закомментировать удаление этого поля в миграции. Ничего зхорошего. Одни только траблы.
2) речь прежде всего не о полном ручном управлении, а о полноценном ревью сгенерированных миграций и создания своих миграций, тюнящих схему вне возможностей доктрины.
В остальных случаях это будет преждевременная оптимизация, преждевременное решение потенциальных проблем. Когда подобные проблемы появятся, тогда и надо будет думать о путях их решения, в том числе как один из вариантов переход на DB first подход для владельцев, переход на единого владельца схемы БД — не обязательно, кстати, владельцем базы должна быть сама база или отдельный проект, можно взять одного из существующих владельцев, сделав его авторитарным для остальных, заставляя N-1 клиентов СУБД синхронизироваться с 1 клиентом явно или через внесённые им изменения в схему, или вообще запретив им работать с базой, а только с API единственного владельца. Всяко лучше, чем синхронизация «всех-со-всеми», даже когда только 2-3 владельца появляются.
База обычно скейлиться дешевле? Весьма смелое утверждение.
Для кода практически всегда есть опция запустить несколько экземпляров, спрятать их за какой-нибудь фасад, вроде балансировщика и писать/читать в одну базу. А вот что делать, если вертикальный предел по железу достигнут, а производительности хранилища по-прежнему не хватает — это большой-большой вопрос.
И если в случае с какой-нибудь монгой еще остаётся пространство для манёвра, то что делать, если датасет из сильно реляционных данных не входит — не очень понятно.
что все так бояться скейлить базу я не пойму, ведь это должно быть заложено в архитектуре проекта, возможность расширяться и переезжать на другие технологии, а не затачивать весь проект под конкретное решение, разве нет?
Не поспоришь, но много БД были спроектированы и разработаны десятки лет назад, когда всех этих модных слов еще не было (а если были, то не так широко распространены как сейчас). А данные в таких БД составляют оргомную ценность. Вот и приходится работать с такими динозаврами.
Сильно зависит от предметной области, бизнес-задач и ограничений, а так же от уровня протечки абстракций над базой данных в слой модели предметной области. Скажем, есть много задач, где легко скейлить чтение путем простой асинхронной master-slave репликации.
Если заведомо не известно, что задача потребует очень больших скоростей записи и чтения данных, их поиска и агрегации, с которыми без БД не справиться за разумное время, и то каждый байт в схеме должен быть максимально оптимизирован, то начинать проектировать с БД очень похоже на попытку преждевременной оптимизации.
P.S. Что будут меняться бизнес-требования к разработке — это практически аксиома, что будут проблемы из за не того начала разработки, в частности от бизнес-задач, а не от базы данных — это ещё бабушка надвое сказала.
Если заведомо не известно, что задача потребует очень больших скоростей записи и чтения данных, их поиска и агрегации, с которыми без БД не справиться за разумное время, и то каждый байт в схеме должен быть максимально оптимизирован, то начинать проектировать с БД очень похоже на попытку преждевременной оптимизации.
Вот так и рождаются програмы с которими работать не возможно. Я обясню что я имею ввиду, говоря правильная програма: Откритие журналов -до 3 с, отркритие документа до 2 с, Отчети до 5с (в некоторих очень редких случаях до 40с иначе регулярние отчеты и OLAP). И неважно что у вас несколько лет в БД, в таблицах милиарды строк и размер в терабайтах.
Приступая к разработке задачи ви должни четко понимать какой обем может быть через год и через 5 лет с учотом роста компании. И здесь нет преждевременной оптимизации, Разници в скорости проектирования модели в БД или JAVA\C#\… нет в принципе. Ибо нужно проектировать структуру учитивая возможние изменения ТЗ, и разширение БЛ.
И как уже говорилось — сгенерировать клас на основании обекта БД проще-простого.
Здесь беда в другом сейчас слишком много разработчиков и груп разработчиков, которие вообще не хотят заморачиватся елементарними знаниями БД. И считают что програма должна бить БД независимая. И ето чуть ли не ее главная фича.
P.S. И да, я старовер. Я не люблю ORM, ибо не представляю что под капотом, и что он сгенерит, и я считаю что реализация бизнес логики на БД наиболее правильное место(самое ефективное). Приетом скорость разработки и скорость работи више.
Вот вам аргументи
1) Поддерка целосности на БД делается елементарно.
2) БД неплохо так паралелит задачи.
3) БД (Оракл) имет так званий result cache для запросов и функций, которий отслеживает изменения таблиц и всегда видает достоверний результат. При етом доступно всем пользователям. Я даже не представляю сколько нужно потратисть усилий чтоб достичь такого результата самостоятельно.
4) Ну и в Pl/sql есть возможнось компиляции в нативний код.
Из минусов только GUI для C#/JAVA покруче и тесты писать сложнее. Отладка кода на БД ничем не хуже/сложнее чем в VS.
Отладка кода на БД ничем не хуже/сложнее чем в VS.
А какой отладчик PL/SQL нормально показывает коллекции? plsqlDeveloper не умел, когда я держал его в последний раз.
Етому есть наверное логичное обеснение.
Согласен. отладка в VS намного удобнее и мощнее.
С етим пунктом я ввел в заблуждение. Можно сказать что отладка присутствует но ограничена.
Да целую колекцию не посмотриш. Только елемент
Ну, вот и закончился миф «Отладка кода на БД ничем не хуже/сложнее чем в VS» не успев начаться.
Можно сказать что отладка присутствует но ограничена.
Сразу вспомним, что в случае Оракла с его pl/sql мы еще на уровне БД имеем сплав двух языков — императивного pl/sql и декларативного sql, при этом худо-бедно дебажится только первый, дебага sql не предполагается. Все это мягко намекает, что утверждение
реализация бизнес логики на БД наиболее правильное место
несколько сомнительно.
декларативного sql
дебага sql не предполагается
У меня даже теоретической идеи нет как можно дебажить декларативний язык.
План запроса ето и есть, как по мне, его дебаг. И чуть ли не базис скорости работы.
реализация бизнес логики на БД наиболее правильное место
несколько сомнительно.
Я даже скажу больше очень немодно. :) и ета мысль часто жостко минусуется на хабре. Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C# значить проще тестится. Проще поддерживается, В случае простых изменений не требует переинстеляции на клиенских машинах. Значит изменения можно внедрять быстрее.
И как я уже писал ниже я не агетирую за БЛ на ХП я агитирую Что выбор Базы и знание нюансов не менне важен за выбор язика програмирования. А по большому счету даже важнее.
У меня даже теоретической идеи нет как можно дебажить декларативний язык.
План запроса ето и есть, как по мне, его дебаг. И чуть ли не базис скорости работы.
Речь шла про удобство и ограниченность дебага. Ну, вот оно, ограничение — прямо на дебаге понять почему тормозит запрос невозможно.
Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C# значить проще тестится
*глядит в портянки pl/sql, потом в свой уютненький java-код* Ээээ… Ладно, проехали :D
выбор Базы и знание нюансов не менне важен за выбор язика програмирования.
С этим никто спорить и не думал.
Речь шла про удобство и ограниченность дебага. Ну, вот оно, ограничение — прямо на дебаге понять почему тормозит запрос невозможно.
Никогда в таком русле не думал. Всегда смотрел план отдельно в Тоде там ето получше сделано. Согласен прям в дебагере — удобнее.
Я согласен — дебаг и GUI похуже Студии еклипса и тд.
*глядит в портянки pl/sql, потом в свой уютненький java-код* Ээээ… Ладно, проехали :D
В девелопере достаточно удобная навигация по коду. Ну а портянки ето уже стиль :) а не маст хев. Но ето уже кому что глазу мелее. Мне например не нравится в JAVA\C# многословие в описаниях класа (public, і тд.). Спасибо хотя б в JAVA var добавили :) Наследование, интерфейси итд часто отвлекают от сути, и получается что обертка становится важнее сути. Не подумайте что я не люблю ООП. Я очень любил с++, Сейчас пишу на c#. Но заглянув в grid(C#), я больше не задавался вопросом почему он такой тормознутый. Мне кажется что ето уже слишком. Я понимаю что там все красиво, канонически. Но работать бысто ето не может… Да Я не знаю как сделать так же уневерсально и быстро. Наверно ето и невозможно. Поетому и появлялись пачками самописние grid. Но ето уже другая история.
многословие в описаниях класа (public, і тд.).
То есть public — это многословно, а разделение pl/sql пакета на спеку и тело, в которых код практически дублируется — это не многословно? :D А куча begin'ов и end'ов вместо скобок? Код на pl/sql совсем не лаконичный. Кстати, с появлением в java'е стримов перебирать коллекции стало одно удовольствие.
Но тем неменее, в целом код написаний на ХП короче аналогичного JAVA\C#
А можно пример?) А лучше парочку.
Мы все ето вместе можем легко проверить. Вы предлагаете сценарий БЛ и реализацию JAVA\С#. Я код PL\sql. Желательно что то посложнее, ибо 90% логики можно реализовать оператором (select\merge\update\insert) или их групой. Но сразу оговорим, что задача должна включать многопользовательский режим, и возможность совмесной работы и контроль прав ограничения на даные.
checkRight();
result = getData();
habr.com/post/312134/#comment_9853420
И это всего лишь одно место. А так вся программа как комплекс может работать в десятки раз быстрее, если она реализована в БД, прекрасно масштабироваться и не требовать скалинга очень долгое время.
насколько код в БД работает быстрее
Что значит «быстрее»? В контексте всего приложения может запросто получиться так, что имея локальный максимум производительности в БД вы в итоге получите глобальный минимум, поскольку бутылочным горлом станет коннект к БД.
А так вся программа как комплекс может работать в десятки раз быстрее, если она реализована в БД
Это ровно до тех пор, пока вся задача программы замыкается на данных из БД. То есть пока это «вещь в себе», к которой изредка кто-то обращается снаружи и просит дать кусочек результата работы — да, будет быстро и не напряжно. Все сломается об колено, как только появится потребность взаимодействовать с внешним миром, забирая оттуда данные, и совершая над ними действия, которые плохо ложаться в термины БД. Как на хранимках написать логику: «пойди к менеджеру ресурсов, возьми у него адрес актуального на данный момент поставщика данных, сходи к поставщику, запроси по websocket соединение, подпишись на такое-то событие, и жди его наступления в течение пяти секунд, после чего обработай полученные данные и сообщи, что они получены. Если за 5 секунд событие не наступило, то тихо закрой коннект и… ну, и так далее». Я, конечно, представляю, что все это можно реализовать через Аляску, с маппингом всего и вся в таблички, но поддерживать и развивать ЭТО будет невозможно.
Как на хранимках написать логику: «пойди к менеджеру ресурсов, возьми у него адрес актуального на данный момент поставщика данных, сходи к поставщику, запроси по websocket соединение, подпишись на такое-то событие, и жди его наступления в течение пяти секунд, после чего обработай полученные данные и сообщи, что они получены. Если за 5 секунд событие не наступило, то тихо закрой коннект и… ну, и так далее».
В Оракле всякую экзотику, которой в приложении не более 5%, типа вебсокетов, можно написать на java, а обработку данных сам бог велел делать на SQL и PL/SQL
можно написать на java, а обработку данных сам бог велел делать на SQL и PL/SQL
А почему бы не пойти дальше, и не написать на той же java за пределами Оракла? Нагружать сервер базы данных еще и работой jvm? Зачем? И чем вы будете пользоваться в «java over oracle» для менеджмента соединений? Куда будете логгировать? Все туда же, на сервер базы данных? А зачем себя так не любить, если можно взять Spring Boot, который замечательно запустится на соседнем сервере и не будет нагружать БД? Сделав этот первый логический шаг совершенно внезапно оказывается, что в java есть стримы, которые замечательно реализуют перебор коллекций, то есть то, что до сих пор делал pl/sql. Вот и БЛ переехала из хранилища данных поближе к внешним запросам от пользователей, что логично. Ну, и так далее… Это эволюция, времена, когда сервера приложений были дорогим и сложным удовольствием, а pl/sql и иже с ним простым и дешевым, прошли и теперь можно вернуть БД изначальное значение — хранить данные, поскольку для их лобработки уже есть более удобные средства.
А в Оракле прекрасно кешируются данные RESULT_CACHE или MATERIALIZED VIEW в концепции которых нет места изменениям кода бизнес логики, а значит самым критичным будет сломанный кеш, а не сломанные данные.
Кеширование это лишние костыли которые, как я писал, могут привезти к ошибкам, которые даже юнит тестами не покроешь.
Кеширование — это не костыль, а потребность. Правильно выбранный кэш решает кучу проблем. К примеру hazelcast нам дает не просто кэш, но распределенный кэш. И это прекрасно!
А как в этой связке ACID?
Да так же, как везде — работает, пока не случается какой-нибудь вывернутый случай :D Если серьезно, то, к примеру, если мне нужно изменить какую-то сущность, то я вынимаю ее из hz, лочу, что б никто в параллельном потоке в это время мне не мог помешать, меняю все, что надо, укладываю обратно в hz. Разлочиваю. На всякий случай лок сам снимется через, к примеру, 500 миллисекунд, мало ли что-то встало колом. Как-то так. Нужно проапдейтить разом несколько сущностей — сначала лочу их все, потом все разлочиваю. try{}finally{} тут помогает. А редиска тут только для персистинга, на случай полного выключения сервера — где-то же данные нужно хранить долговременно…
А я так и вижу логику приложения на Java, написана функция для получения суммы проводок по счёту. Далее открываем цикл по счетам и получаем этой функцией сумму по счёту, потестировали, суммируем всё хорошо, кинули в продакшн. Потом показывают отчёт где баланс не сходится. Потому что в многопользовательской системе пока в цикле мы посчитали первый и второй счёт, а вторая сессия уменьшила сумму первого и увеличила сумму третьего. Изменения 3го счёта попадут в отчёт, а 1го не попадут. Приходим к выводу что на время выполнения отчёта надо блокировать всё и запрещать модификацию данных.
Приходим к выводу что на время выполнения отчёта надо блокировать всё и запрещать модификацию данных.
Нет, не так. В вашей логике вы строите отчет по тем же данным, которые кто-то меняет, а это не так. Вы атомарно получили данные, у вас есть датасет, и вы по нему строите отчет никому не мешая и вам никто не мешает.
В конце-концов речь идет о продакшн-реди инструменте, который показал себя на больших проектах, хотя бы у Яндекса: habr.com/company/yamoney/blog/332462
Нет, не так. В вашей логике вы строите отчет по тем же данным, которые кто-то меняет, а это не так. Вы атомарно получили данные, у вас есть датасет, и вы по нему строите отчет никому не мешая и вам никто не мешает.
Что-то я не понимаю… т.е. сначала заблокировать всю базу, извлечь ВСЕ данные из БД, т.к. я могу не знать какие данные мне понадобиться, разблокировать БД, а потом уже строить отчёт по извлечённым данным…
Я хочу сказать что, запрос
SELECT УИД
, CASE
WHEN GROUPING(НАИМЕНОВАНИЕ) = 1 THEN 'Итого:'
ELSE НАИМЕНОВАНИЕ
END НАИМЕНОВАНИЕ
, SUM(ОПР_СУММУ_БУХГАЛТЕСКОГО_СЧЁТА(УИД)) СУММА
FROM БУХ_СЧЕТА
GROUP BY ROLLUP ((УИД, НАИМЕНОВАНИЕ))
в Оракле всегда даст ожидаемый результат, а если функцию ОПР_СУММУ_БУХГАЛТЕСКОГО_СЧЁТА написать на java, которая может оперирует данными из 100 таблиц, то пока мы не заблокируем все эти таблицы на момент исполнения, то мы не добьёмся согласованных данных и в строчке «Итого:» мы можем получать неожиданные данные.
Что-то я не понимаю… т.е. сначала заблокировать всю базу, извлечь ВСЕ данные из БД, т.к. я могу не знать какие данные мне понадобиться, разблокировать БД, а потом уже строить отчёт по извлечённым данным…
Зачем что-то блокировать на чтение? За тебя все сделает хазелькаст ровно так же, как делает Оракл. Блокировать что-то нужно на изменение. В общем очевидно, что я могу только отправить к документации.
Кстати, ситуация когда «т.к. я могу не знать какие данные мне понадобиться» явно показывает, что что-то ты делаешь не так…
Кстати, ситуация когда «т.к. я могу не знать какие данные мне понадобиться» явно показывает, что что-то ты делаешь не так…
Нет, всё не так. Я же не знаю какие данные и таблицы под капотом у функции ОПР_СУММУ_БУХГАЛТЕСКОГО_СЧЁТА, да мне и не нужно этого знать
Зачем что-то блокировать на чтение? За тебя все сделает хазелькаст ровно так же, как делает Оракл. Блокировать что-то нужно на изменение. В общем очевидно, что я могу только отправить к документации.
Я вроде не говорил что на чтение, на запись конечно. И Оракл ничего не блокирует при чтении. Ну т.е. мы пришли к ситуации что для получения сводного согласованного отчёта по всем данным надо заблокировать за запись всю БД.
Нет, всё не так. Я же не знаю какие данные и таблицы под капотом у функции ОПР_СУММУ_БУХГАЛТЕСКОГО_СЧЁТА, да мне и не нужно этого знать
Я про ситуацию, когда «запрашиваю все, потому что не знаю, что из этого мне надо».
Ну т.е. мы пришли к ситуации что для получения сводного согласованного отчёта по всем данным надо заблокировать за запись всю БД.
Никуда мы не пришли, это вы упорно натягиваете сову на глобус. На запись что-то блокирует для себя программист, точно так же, как блокирует любые объекты в конкуррентном окружении — Lock, CountdownLatch, и прочие мютексы с семаформаи делают ровно это. Ровно в этой парадигме программист лочит объекты Хазелькаста, лочит заботясь о себе, а не о Хазелькасте и его внутренней согласованности данных. То есть лочить прогер должен когда хочет монопольно изменять объект ковыряя при этом пальцем в носу. Случай если кто-то что-то запросил на чтение, и в этот момент кто-то что пишет Хазелькаст разруливает самостоятельно точно так же, как Оракл, прозрачно для программиста.
Дело же не именно в кэшировании, а в управлении кодом. Да, результат запроса вы закешируете. А результат вызова Web-API уже нет.
Сломанные данные это ошибка в логике. И как раз логикой проще управлять на специализированных языках.
Логика в базе это лишние костыли которые могут привезти к ошибкам, которые даже юнит тестами не покроешь.
Утверждение которое ни имеет ничего общего с реальностью. В комментариях к своей статье я писал как элементарно написать юнит-тесты к логике в mysql
habr.com/post/312134/#comment_9849654
в Oracle использую utPLSQL
Сломанные данные это ошибка в логике. И как раз логикой проще управлять на специализированных языках.
Опять какое-то голословное утверждение. чем SQL не специализированный язык? Как раз специализированный язык для обработки данных
чем SQL не специализированный язык? Как раз специализированный язык для обработки данных
Ни в коем случае! Он, конечно, специализированный, но не для обработки — извлечение и обновление это не обработка. Это именно что подготовка data set для дальнейшей работы с ним. Pl/sql ведь так и возник — данные нужно было обрабатывать, а sql мог ими только манипулировать, да и то ограниченно.
- если можно, сделай это с помощью одного оператора SQL;
- если это нельзя сделать с помощью одного
оператора SQL, сделай это в PL/SQL;- если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
- если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
- если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...
Утверждение которое ни имеет ничего общего с реальностью.
Ага, я о том же. У вас тоже обобщенное необоснованное утверждение.
В комментариях к своей статье я писал как элементарно написать юнит-тесты к логике в mysql
Ага, только это не юнит-тесты, а интеграционные, и они точно также пишутся для логики в коде.
чем SQL не специализированный язык? Как раз специализированный язык для обработки данных
Тем, что специализирован он не для написания логики. Как там со структурированием и переиспользованием кода? Объекты, наследование, типизация, ассоциативные массивы произвольной структуры.
Ага, только это не юнит-тесты, а интеграционные, и они точно также пишутся для логики в коде.
Самые что не наесть юнит тесты
unit testing — процесс в программировании, позволяющий проверить на корректность единицы исходного кода
Единицей исходного кода в БД может являться функция или процедура.
Тем, что специализирован он не для написания логики.
А по мне так он прекрасно для этого подходит, я в своём примере это показал.
Самые что не наесть юнит тесты
Там дальше написано "Это ошибка, поскольку тест не должен выходить за границу класса". У вас работает вся система управления БД полностью.
В общем, то, что вы делаете (работа с тестовой БД), при логике в коде называется интеграционным тестированием, и абсолютно ничем не отличается.
я в своём примере это показал
Если вы про нашу беседу, то мы не сравнивали читаемость. Понятно, что на любом Тьюринг-полном языке можно написать логику обработки. Вопрос только в количестве и качестве написанного (поддерживаемости).
Если вы про нашу беседу, то мы не сравнивали читаемость. Понятно, что на любом Тьюринг-полном языке можно написать логику обработки. Вопрос только в количестве и качестве написанного (поддерживаемости).
Для меня язык SQL простой и лаконичный, его просто поддерживать, а что там и как нагорожено в ОРМ одному чёрту известно + надо учить синтаксис конкретной ОРМ + синтаксис меняется от ОРМ к ОРМ + ОРМ в конечном итоге всё-равно создаёт SQL в котором приходится разбираться в случае возникновения проблем
а что там и как нагорожено в ОРМ одному чёрту известно
Код ОРМ не является кодом, который надо писать и поддерживать. То есть его кто-то пишет, но это сторонний код, в отличие от бизнес-логики.
надо учить синтаксис конкретной ОРМ + синтаксис меняется от ОРМ к ОРМ
Зачем? Открываем код или доки, смотрим конкретное название и параметры. Ничем не отличается от работы с сотней других библиотек.
Для меня язык SQL простой и лаконичный
"Для вас простой" означает "специализирован для написания логики"?
Он для вас простой потому что вы постоянно с ним работаете. По лаконичности я приводил другие примеры в той статье, кода там гораздо меньше.
ОРМ в конечном итоге всё-равно создаёт SQL в котором приходится разбираться в случае возникновения проблем
Ну возникла проблема, разобрались. Зачем постоянно то на нем писать?
Я участвовал в разработках где вся БЛ на БД, и где на БД запрещены ХП (Слава богу хотя foreign key разрешили). Я скажу так, не важно какой путь вы вибрали. Всегда нужно помнить: Каждая БД имеет свой «характер» И то что на MSSQL\Oracle\MySQL\Postgresql\… работает на ура в другой БД может тупить, или вообще не работать. Если у вас OLTP система — не знание етих нюансов ето смерть в продакшине. Я не агетирую за БЛ на БД. Я агитирую за то что разработчик должен знать особенности БД которую будет использовать. И ето значительно важнее для качественного продукта чем знатие всех фич язика или нових фреймворков.
P.S. И да для меня для меня скорость и отзывчевость програмы ето один из главнейших критетеев програмы на равне с юзебилити.
И я видел людей, для которых отритие документа в 1 минуту уже не проблема, они смирились и считают ето нормой. Видя такой софт грусно становится…
«Истина в последней инстанции» или зачем нужен Database First Design