<sarcasm> потому что это перенос бизнес логики в базу, код ревью не пройдет </sarcasm> Вообще жесть какая-то, что для простейшей в общем-то задачи надо разбираться в кишках hibernate.
Хм, посчитал приблизительно. Если к данным из википедии добавить данные о мини-гидтроэлектростанциях (около 4000 в австрии, по одной на каждых 2000 человек, около 40% от всей гидроэнергии ) то получается 75%. Как аналогия - по одной мини - гидроэлектростанции электростанции на среднюю московскую многоэтажку. Их реально много. Они реально их почти на каждом ручье строят.
В Австрии и Швейцарии как раз все понятно - там горы , куча мелких и средних гидроэлектостанций в каждой второй деревне. Перекрывают ручеек, а 500-1000 метров ниже ставят в сарае турбину. Вода по трубе. Напор там бешеный. Поучают с расхода 60 л в сек мощность 260 kW, или 9,3 GwH в год. Неплохо для деревни. Заодно получают защиту от оползней/лавин в русле ручья. Большие реки тоже все в гидроэлекростанциях, за счет рельефа площадь затопления минимальна.
Опять таблицы! Вообще хорошим тоном считается обращаться к базе только через view! Делать селект из таблицы напрямую это как использовать GOTO для реализации цикла.
Соответственно, при связи 1 к 1 надо просто создать VIEW эмулирующий одну таблицу и работать только с ним . Что там под капотом и почему CRUD логику интересовать не должно.
Все таки таблица это очень низкоуровневый объект. По хорошему надо знать на каком физическом носителе она находится, параметры файловой системы. Тогда, просто подгоняя параметры, можно увеличить производительность в 2-3 раза. Посмотрите на все параметры создания таблицы в MySQL https://dev.mysql.com/doc/refman/8.0/en/create-table.html или ORACLE https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-TABLE.html. Реально JAVA- Сениор не должен определять какой нибудь DEFERRED SEGMENT CREATION. Дальше VIEW он ходить не должен, это не его зона ответственности.
Консультанты. То есть те программисты, которым приходится общаться с клиентом. У них шансы решить проблему ГОРАЗДО больше. И Их типично программистские проблемы 0.1 + 0.2 === 0.3 не интересуют, им надо получить результат за минимальное время. 1С и Oracle APEX для меня лучший пример баланса между Low и Code, дальше упрощать - потеряется гибкость.
Фронтенд, бэкенд... Не будет этого разделения. Будет связка ИТ-Консультант -> GPT8+ -> RAD. Пользователю проще описать бизнес правила с помощью описаний интерфейса - "Если лимит превышен - показывать сообщение и не разрешать операцию". Бакенд и прочий JSON его не интересует. RAD на этом принципе уже сейчас живет и в эту сторону развивается, его цель - автоматически делать бэкенд на основании описания ползовательского интерфейса. Когда какой нибудь open.ai скрестит ChatGPT и RAD - тогда все переквалифицируются в консультанты.
Ну, иногда это единственный вариант получить обратную связь. Стадный инстинкт работает даже для интовёртов, в личном разговоре он закроется, а на этом несерьезном совещании может и рассказать что нибудь полезное. То же для юниоров, они часто боятся рассказывать о проблемах один на один. А тут - все говорят, значит и я скажу. Рассматривайте ретроспективу как вариант тим билдинга, возможность узнать немного больше о команде, а не как единственное место для улучшения рабочих процессов.
LOW -Code - идеально подходит для миграции из экселя в классическое внутреннее бизнес WEB-приложение, такое с тысячью полей и сотней формочек. Здесь все преимущества раскрываются во всей красе и все довольны. Разработчик, он же аналитик решает бизнес задачи не не думает о сортировке пузырьком. Заказчик получает релизы через день и может без задержек дать обратную связь. Если концепция изменилась, и переделать с нуля можно относительно быстро. Оснавную ценность в этом случае представляет не само приложение а знания бизнес процессов и деталей, то есть документация и опыт. И масштабировать удобно вертикально - это же не рождественская распродажа, даже в международных корпорациях редко бывает больше 10000 пользователей одновременно. Проще пару процессоров прикупить.Бэкап опять же, это для бизнеса важно.
Желание руководить людьми упало до рекордного минимума. Это следствие "если хочешь сделать хорошо - сделай сам". Вот когда подчиненные под твоим руководством сдадут крутую фичу, которую в одиночку не осилить - вот тогда прочувствуешь эмоциональный подъем.
Лучше использовать дату удаления, а не статус. Проще реализовать в УИ просмотр/исправление неактивных объектов (Например, при формировании годового отчета нашли ошибку в наименовании уже неактивного контрагента ).
Тем, что приходится объяснять пользователям разницу между исправлением ошибки (опечатка при занесении фамилии оператором ) и изменением данных (смена фамилии) и постоянно контролировать корректоность использования.
В этом скучае флаг удаления не имеет смысл без поддержки версионных данных. В накладных есть адрес, улицу переименовали. Без версионности старые накладные будут отображаться неверно. Но версионность это лютый оверхед. Проще хранить в базе только актуальные данные а всю историю экспортировать в какое -нибудь хранилище в виде денормализованного json документа.
А здесь не понял. Что мешает отбрасывать их на уровне запроса? Заодно и план запроса улучшится, возможно, получится задействовать индексы и т.д.
Для тех, кто удалил аккаунт с госуслуг: что может случится, если мошенники зарегистрируют новый аккаунт с украденными паспортными данными /СНИЛС?
1C или SAP или APEX - это low code или еще нет?
<sarcasm> потому что это перенос бизнес логики в базу, код ревью не пройдет </sarcasm>
Вообще жесть какая-то, что для простейшей в общем-то задачи надо разбираться в кишках hibernate.
Не смог найти там не агрегированных, исходных данных. А на графиках можно нарисовать что угодно.
Хм, посчитал приблизительно. Если к данным из википедии добавить данные о мини-гидтроэлектростанциях (около 4000 в австрии, по одной на каждых 2000 человек, около 40% от всей гидроэнергии ) то получается 75%. Как аналогия - по одной мини - гидроэлектростанции электростанции на среднюю московскую многоэтажку. Их реально много. Они реально их почти на каждом ручье строят.
https://www.wasserkraft-soelden.at/fileadmin/userdaten/bilder/kraftwerk_rettenbach/wasserkraft_soelden_kraftwerk_rettenbach_04.jpg
Электростанции на газе используются в основном в комбинации с центральным горячим водоснабжением в крупных городах, всего 17 на всю страну.
В Австрии и Швейцарии как раз все понятно - там горы , куча мелких и средних гидроэлектостанций в каждой второй деревне. Перекрывают ручеек, а 500-1000 метров ниже ставят в сарае турбину. Вода по трубе. Напор там бешеный. Поучают с расхода 60 л в сек мощность 260 kW, или 9,3 GwH в год. Неплохо для деревни. Заодно получают защиту от оползней/лавин в русле ручья.
Большие реки тоже все в гидроэлекростанциях, за счет рельефа площадь затопления минимальна.
Когда приходит пора усложнять логику, делается рефакторинг. После, не раньше.
Опять таблицы! Вообще хорошим тоном считается обращаться к базе только через view! Делать селект из таблицы напрямую это как использовать GOTO для реализации цикла.
Соответственно, при связи 1 к 1 надо просто создать VIEW эмулирующий одну таблицу и работать только с ним . Что там под капотом и почему CRUD логику интересовать не должно.
Все таки таблица это очень низкоуровневый объект. По хорошему надо знать на каком физическом носителе она находится, параметры файловой системы. Тогда, просто подгоняя параметры, можно увеличить производительность в 2-3 раза. Посмотрите на все параметры создания таблицы в MySQL https://dev.mysql.com/doc/refman/8.0/en/create-table.html или ORACLE https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-TABLE.html. Реально JAVA- Сениор не должен определять какой нибудь DEFERRED SEGMENT CREATION. Дальше VIEW он ходить не должен, это не его зона ответственности.
Консультанты. То есть те программисты, которым приходится общаться с клиентом. У них шансы решить проблему ГОРАЗДО больше. И Их типично программистские проблемы 0.1 + 0.2 === 0.3 не интересуют, им надо получить результат за минимальное время.
1С и Oracle APEX для меня лучший пример баланса между Low и Code, дальше упрощать - потеряется гибкость.
А если военника нету, но есть приписное? Офзап, военная кафедра. Достаточно ли будет копии паспорта и справки о консульском учете?
Фронтенд, бэкенд... Не будет этого разделения. Будет связка ИТ-Консультант -> GPT8+ -> RAD.
Пользователю проще описать бизнес правила с помощью описаний интерфейса - "Если лимит превышен - показывать сообщение и не разрешать операцию". Бакенд и прочий JSON его не интересует. RAD на этом принципе уже сейчас живет и в эту сторону развивается, его цель - автоматически делать бэкенд на основании описания ползовательского интерфейса.
Когда какой нибудь open.ai скрестит ChatGPT и RAD - тогда все переквалифицируются в консультанты.
Ну, иногда это единственный вариант получить обратную связь. Стадный инстинкт работает даже для интовёртов, в личном разговоре он закроется, а на этом несерьезном совещании может и рассказать что нибудь полезное. То же для юниоров, они часто боятся рассказывать о проблемах один на один. А тут - все говорят, значит и я скажу.
Рассматривайте ретроспективу как вариант тим билдинга, возможность узнать немного больше о команде, а не как единственное место для улучшения рабочих процессов.
Бассейны, надувные конструкции? Может в эту область смотреть? Там крой бывает очень сложный и размеры деталей большие.
LOW -Code - идеально подходит для миграции из экселя в классическое внутреннее бизнес WEB-приложение, такое с тысячью полей и сотней формочек. Здесь все преимущества раскрываются во всей красе и все довольны. Разработчик, он же аналитик решает бизнес задачи не не думает о сортировке пузырьком. Заказчик получает релизы через день и может без задержек дать обратную связь. Если концепция изменилась, и переделать с нуля можно относительно быстро. Оснавную ценность в этом случае представляет не само приложение а знания бизнес процессов и деталей, то есть документация и опыт.
И масштабировать удобно вертикально - это же не рождественская распродажа, даже в международных корпорациях редко бывает больше 10000 пользователей одновременно. Проще пару процессоров прикупить.Бэкап опять же, это для бизнеса важно.
Да ну? Давно у нас лыжи гнуться перестали?
Я вместо этого утверждения ожидал анализа вроде такого, с добавлением упругости лыжи...
https://www.yourski.ru/article/zavisimost-mezhdu-uglom-zakantovki-i-radiusom-povorota-lyzhi-glavnye-vkladki
https://www.ski.ru/az/blogs/post/kak-dostich-bolshikh-uglov-zakantovki-lyzh-dinamika-angulyacii-vrezanie-lyzhi-i-effekt-vesla/
Лучше использовать дату удаления, а не статус. Проще реализовать в УИ просмотр/исправление неактивных объектов (Например, при формировании годового отчета нашли ошибку в наименовании уже неактивного контрагента ).
Тем, что приходится объяснять пользователям разницу между исправлением ошибки (опечатка при занесении фамилии оператором ) и изменением данных (смена фамилии) и постоянно контролировать корректоность использования.
В этом скучае флаг удаления не имеет смысл без поддержки версионных данных. В накладных есть адрес, улицу переименовали. Без версионности старые накладные будут отображаться неверно.
Но версионность это лютый оверхед. Проще хранить в базе только актуальные данные а всю историю экспортировать в какое -нибудь хранилище в виде денормализованного json документа.