Мускуль никто не брал. Я его подключил в качестве развлечения к ORM просто потому что могу. Когда всё пошло по бороде.
Базу данных я не выбирал. Когда я пришёл, там уже был оракл. А в оракле было 5тб данных. Про орм я писал, почему свой. Потому что на три звена нет ни одного орм. Odoo - это не ORM. Это готовая ERP/CRM. Нам такое не надо было, потому что мы посчитали, что для нашей специфики дешевле делать своё, чем костылить чужое универсальное.
Раундтрип и ORM - это вещи взаимно перпендикулярные. Особенно на системах со смешанной парадигмой, вроде той, что тут описана. А там как раз ORM работал и для сервера, и для клиента. В одном синтаксисе. Работать с логикой в клиенте удобнее, когда не хватает разрабов. Потому что на каждое действие создавать апи - дело, конечно, нехитрое, но очень уж утомительное. А у клиента интерфейс вот тут вот. Рядом. Если что, можно и юзера переспросить, не кидаясь джсончиками в сервер.
Тот кейс, который вы описываете, не требует передачи информации между клиентом и сервером. Но у нас тут была своя атмосфера. Номер платёжки передать? Хех. А давайте лучше впихнём юзеру результат анализа по позициям. Строк так сто тысяч. А он там разберётся как-нибудь, сгруппирует, отсортирует, отфильтрует что ему надо. И колонок ему ещё добавим штук десять, а то 50 - мало. И половина будет ссылками на другие сущности, суть, джоинами. А другая - результатами расчёта по какой-нибудь хитрой статистике. И чтобы там куча параметров была, желательно через интерфейс.
И чтобы всё это гуано менялось каждую неделю, потому что "а мы вот подумали".
Запускаем select all, из таблицы в которой 3000 записей. Время выполнения 2.96 sec. Если запустить count (*) то результат будет около 500-800 мсек - т.е фактически время пинга.
Три секунды для 3к записей - это прямо много. Очень много.
51к записей из MySql за секунду
У вас разница между пингом и фетчем всего получается больше двух секунд. Неужели сами не видите?
Давайте я сделаю тот же фетч через впн.
те же 51к записей
То есть у меня время меньше, чем у вас, но записей на порядок больше. Вопросы?
Как вам ООП, события, ORM помогут не тащить 40 млн записей с сервера на клиента?
Я спрашивал про управление сложностью. Не надо подменять тезисы. Пожалуйста.
вы не круче людей которые писали движок Оракла
Почему не круче? Там какие-то особенные супер-люди, до которых нам не дотянуться? Так какие-то волшебные знания, отличающиеся от привычной компьютер саенс?
Почему-то Мерседес может все свои производственные данные за кучу лет держать в оракловской БД, а вы не можете.
И пусть держат. В чём вообще проблема? Или в том, что я усомнился в Божественности Его Величия Оракла?
Тут вы, споря с виртуальным собеседником, приводите аргумент, что типы не всё решают. И делаете вывод, что они не спасают от багов. Это манипуляция.
Типы гарантируют, что в этой переменной может быть значение только такого типа. Не больше и не меньше.
И вот, наконец, мой любимый пример: транзакции в СУБД. Якобы они предоставляют гарантии консистентности.
Вообще ни разу. Транзакция даёт гарантию, что она либо выполнится целиком, либо не выполнится никак. Не больше и не меньше. Это инструмент, а обеспечить с помощью этого инструмента консистентность - это твоя задача, программист. Данные же твои. Схема данных твоя. Это ты определяешь, что является консистентностью, а что нет.
БД Оракл- в головном офисе , который может быть за Х000 км это нормальная практика.
Я выложил исходники, описал методику. Почему бы вам самим не проверить?
Логика в БД - радуйтесь у вас есть view, stored procedures
У меня в языке программирования общего назначения есть классы, наследование, полиморфизм, интерфейсы, свойства, события, отладка, тесты, рефлекшен, куча библиотек, ORM, гит и ещё много чего другого.
Что-то меня не радует наличие хранимых процедур в БД. Что там ещё есть для управления сложностью больших проектов?
Сравнивать оракл и MYSQL - это вообще за гранью.
Почему?
Автору можно было выкинуть формы и использовать Excel как фронт-енд
Так я же всю статью об этом говорил. Там даже отдельная глава есть "Тормоза", ещё есть "Почему ORM". В статье описано, почему трёхзвенка. Я описывал задачи. Ну прочитайте хотя бы заголовок, а дальше перейдём к более тонким материям.
Я тоже думаю, что не живые. Но по другим причинам. Внутри вируса не происходит никаких химических процессов, там нет нервной системы, там ничего не может умереть. Только сломаться.
Ха. В той системе инклюды 1:М упаковывались в объекты перед передачей. Если классический селект повторил бы левую таблицу N раз, то в протобуфе был типизированный объект, где левая сущность была в одном экземпляре, а правая (множество) в своём списке в поле левой сущности.
То есть от БД до сервера трафик был в сто раз больше, а при передаче в клиент как положено, без оверхеда.
Там была единственная проблема - нужен был OrderBy по полю для джойна для асинхронной передачи таких объектов. Просто потому что ORM нужно было понять, что вот этот левый объект уже заполнен и его можно отправлять на клиента.
Согласен. Сложности добавилось. Это если говорить про трёхзвенку.
Но у нас была задача сделать одновременное редактирование большого документа целым отделом. Это без серверной части не делается ну никак. Можно, конечно, обмазать всё триггерами и ходить каждым клиентом проверять, что там изменилось, но вы же понимаете, что это так себе решение.
Трёхзвенка сложнее в разработке, но при сложной логике она проще. Вот такой парадокс. Мы знали, на что шли, это всё было учтено при принятии решения.
А ORM на этой трёхзвенке уже практически не привносил сложностей. Зато вот сильно упрощал написание, а главное чтение бизнес-логики. Он нужен был на начальном этапе, когда я один пилю. Если бы набрали команду, то потихоньку перенесли бы логику на сервер.
Ваша аналогия похожа на котёнка с дверцей. MySql появился уже потом, когда уволили людей, бравших меня на работу и принимавших решение про трёхзвенку. Я оставался один и проект мой хотели закрыть.
В этом проекте всё уже было. И джоины (1:M и M:1) и трекинг и всё, что перечислено в последнем списке. Это просто проект для этой статьи такой урезанный.
Да и чем MySql плох? За что его так сравнивать с мотором от инвалидки? Разве не умеет хранить данные? Умеет. А в чём дело?
Кривая структура БД может причинять такие тормоза, что даже Oracle не не тащит
В статье показаны тормоза на практически пустой базе после свежей установки. Исходники есть в гитхабе, репозиторий тоже, методику я расписал, можете сами проверить. Речь не идёт о кривой структуре.
Улучшить быстродействие при увеличении пинга можно было увеличив FetchSize
Крутили. Насколько я помню, там максимум в 36кб. Могу ошибаться. Но я точно помню, что не помогло.
не брать MySQL, а организовать в новой БД рядышком
А зачем? Я немного не понял смысл. MySql я расписал, чем был лучше. Он тупо быстрее работает во всех инструментах со своим стандартным протоколом из коробки. А зачем новый инстанс оракла ставить рядом? Чисто для тестов? Так прод всё равно будет в облаке, потому что начальство наотрез против переноса данных в офис.
Именно поэтому я и эксперементировал с фетч сайзом. Я вообще крутил всё, до чего мог дотянуться. А дотянуться я не мог разве что до настроек самого инстанса оракла.
А сейчас мне это не интересно. Я не работаю в этой компании полтора года как. Ну узнаю я, как это можно было починить, а что дальше? Статья вообще не об этом.
Да, смотрел. Изначально как раз хотел взять его в паре с EF core. Клиент им сериализует запрос, а сервер нахлобучивает его на репозиторий EF. Не срослось, и я взял только идею оттуда.
Спасибо. Include это не совсем join. Да, он транслируется в left join, но может работать только по внешнему ключу (в случае с OrmFactory ещё и по виртуальному внешнему ключу). То есть его условие вшито в модель.
Про причину тормозов я так и не узнал. Тогда я крутил всё, что крутилось на клиенте, а сейчас мне уже не актуально.
То, что смена протокола (добавление gRPC на участке с задержкой) увеличила скорость - я этот эксперимент буквально вчера повторил. Да, похоже на то, что протокол оракла ждёт подтверждения (или запроса) со стороны клиента. Но как действительно это работает - я не знаю.
Если работаете с WPF, то почему бы не попробовать? Синтаксис оттуда переносится чуть ли не 1:1. Всё же зависит от того, чего вы хотите. Если странного, как я - то это боль и страдание. Если всё стандартное подходит - то даже не заметите проблем. Мне миллионы строк надо скроллить в гриде, у меня своя атмосфера. Может у вас совсем не так. Мне критично было сделать поддержку для макбуков arm64. Линукс у меня чисто как бонус. В линуксе, кстати, не работает размытие фона с прозрачностью, но оно тоже далеко не всем надо.
Авалония довольно глючная штука. То одно отвалится, то другое. Странно очень потроха сделаны, по мне так перемудрили со архитектурой. Захочешь заоверрайдить что-то в контроле - не сможешь. Я сталкивался с тем, что вот потроха - напиши свой контрол, но нет. Нужные компоненты internal или вообще protected. Зачем?
Для бизнес-разработки нужны продвинутые контролы, их просто нет под авалонией. Вроде еремекс что-то пилит, но я не помню у них демо-контролы в паблике.
Иногда свой контрол в разы проще написать, чем победить все баги родного. У меня так с датагридом было.
Они ещё хотели сделать TreeDataGrid платным зачем-то. А аналогов ему нет. Это тоже смущает. Хотя та ещё забагованная и тормозная штучка. Никак не мог заставить его стоять и не дёргаться при обновлении вьюмодели. Плюнул, написал свой.
С другой стороны Авалония уникальна. Она сама рисует контролы на всех платформах и не зависит от багов UI-прокладки. Если работает на одной платформе - работает на всех. И выглядит одинаково. Это позволяет не отлаживаться и подгонять контролы под каждую платформу.
Альтернатив особо нет. Есть Uno Platform, он стабильнее, но это прокладка к родным контролам. Есть MAUI, с ним также, да ещё он мобильно-ориентирован. Грусть и печаль.
Мускуль никто не брал. Я его подключил в качестве развлечения к ORM просто потому что могу. Когда всё пошло по бороде.
Базу данных я не выбирал. Когда я пришёл, там уже был оракл. А в оракле было 5тб данных. Про орм я писал, почему свой. Потому что на три звена нет ни одного орм. Odoo - это не ORM. Это готовая ERP/CRM. Нам такое не надо было, потому что мы посчитали, что для нашей специфики дешевле делать своё, чем костылить чужое универсальное.
Я не буду здесь приводить ответ манагеров на предложение сделать пагинацию. Иначе меня за сквернословие забанят.
Работа у них такая. Такие массивы данных. Им вот НАДО. Понимаете?
К слову, мой ORM вполне себе умел в пагинацию. В статье есть реализация трансляции Take/Skip.
Я специально выбирал табличку, чтобы получить объём данных. Зачем мне его смотреть?
Какой план запроса может быть у
select * from table where rownum <= 8000?Каналы пробовали все доступные.
А вы там работали? Таблицу на сто тысяч строк и 50 колонок не хотите? А заполнение комбобокса на 6000 подсказок?
Раундтрип и ORM - это вещи взаимно перпендикулярные. Особенно на системах со смешанной парадигмой, вроде той, что тут описана. А там как раз ORM работал и для сервера, и для клиента. В одном синтаксисе. Работать с логикой в клиенте удобнее, когда не хватает разрабов. Потому что на каждое действие создавать апи - дело, конечно, нехитрое, но очень уж утомительное. А у клиента интерфейс вот тут вот. Рядом. Если что, можно и юзера переспросить, не кидаясь джсончиками в сервер.
Тот кейс, который вы описываете, не требует передачи информации между клиентом и сервером. Но у нас тут была своя атмосфера. Номер платёжки передать? Хех. А давайте лучше впихнём юзеру результат анализа по позициям. Строк так сто тысяч. А он там разберётся как-нибудь, сгруппирует, отсортирует, отфильтрует что ему надо. И колонок ему ещё добавим штук десять, а то 50 - мало. И половина будет ссылками на другие сущности, суть, джоинами. А другая - результатами расчёта по какой-нибудь хитрой статистике. И чтобы там куча параметров была, желательно через интерфейс.
И чтобы всё это гуано менялось каждую неделю, потому что "а мы вот подумали".
Три секунды для 3к записей - это прямо много. Очень много.
У вас разница между пингом и фетчем всего получается больше двух секунд. Неужели сами не видите?
Давайте я сделаю тот же фетч через впн.
То есть у меня время меньше, чем у вас, но записей на порядок больше. Вопросы?
Я спрашивал про управление сложностью. Не надо подменять тезисы. Пожалуйста.
Почему не круче? Там какие-то особенные супер-люди, до которых нам не дотянуться? Так какие-то волшебные знания, отличающиеся от привычной компьютер саенс?
И пусть держат. В чём вообще проблема? Или в том, что я усомнился в Божественности Его Величия Оракла?
Сервер у меня находится на локальной машине в виртуалке
Ещё раз перейдёте на личности - получите минус в карму. Я предупредил.
Я вам только что сказал - есть исходники, есть методика. Проверяйте. Если есть сомнения - оформите мысль так, чтобы это можно было протестировать.
Тут вы, споря с виртуальным собеседником, приводите аргумент, что типы не всё решают. И делаете вывод, что они не спасают от багов. Это манипуляция.
Типы гарантируют, что в этой переменной может быть значение только такого типа. Не больше и не меньше.
Вообще ни разу. Транзакция даёт гарантию, что она либо выполнится целиком, либо не выполнится никак. Не больше и не меньше. Это инструмент, а обеспечить с помощью этого инструмента консистентность - это твоя задача, программист. Данные же твои. Схема данных твоя. Это ты определяешь, что является консистентностью, а что нет.
Я выложил исходники, описал методику. Почему бы вам самим не проверить?
У меня в языке программирования общего назначения есть классы, наследование, полиморфизм, интерфейсы, свойства, события, отладка, тесты, рефлекшен, куча библиотек, ORM, гит и ещё много чего другого.
Что-то меня не радует наличие хранимых процедур в БД. Что там ещё есть для управления сложностью больших проектов?
Почему?
Спасибо, не хочу.
Так я же всю статью об этом говорил. Там даже отдельная глава есть "Тормоза", ещё есть "Почему ORM". В статье описано, почему трёхзвенка. Я описывал задачи. Ну прочитайте хотя бы заголовок, а дальше перейдём к более тонким материям.
Я тоже думаю, что не живые. Но по другим причинам. Внутри вируса не происходит никаких химических процессов, там нет нервной системы, там ничего не может умереть. Только сломаться.
Какая же это жизнь, если ты не можешь умереть?
Ха. В той системе инклюды 1:М упаковывались в объекты перед передачей. Если классический селект повторил бы левую таблицу N раз, то в протобуфе был типизированный объект, где левая сущность была в одном экземпляре, а правая (множество) в своём списке в поле левой сущности.
То есть от БД до сервера трафик был в сто раз больше, а при передаче в клиент как положено, без оверхеда.
Там была единственная проблема - нужен был OrderBy по полю для джойна для асинхронной передачи таких объектов. Просто потому что ORM нужно было понять, что вот этот левый объект уже заполнен и его можно отправлять на клиента.
Согласен. Сложности добавилось. Это если говорить про трёхзвенку.
Но у нас была задача сделать одновременное редактирование большого документа целым отделом. Это без серверной части не делается ну никак. Можно, конечно, обмазать всё триггерами и ходить каждым клиентом проверять, что там изменилось, но вы же понимаете, что это так себе решение.
Трёхзвенка сложнее в разработке, но при сложной логике она проще. Вот такой парадокс. Мы знали, на что шли, это всё было учтено при принятии решения.
А ORM на этой трёхзвенке уже практически не привносил сложностей. Зато вот сильно упрощал написание, а главное чтение бизнес-логики. Он нужен был на начальном этапе, когда я один пилю. Если бы набрали команду, то потихоньку перенесли бы логику на сервер.
Ваша аналогия похожа на котёнка с дверцей. MySql появился уже потом, когда уволили людей, бравших меня на работу и принимавших решение про трёхзвенку. Я оставался один и проект мой хотели закрыть.
В этом проекте всё уже было. И джоины (1:M и M:1) и трекинг и всё, что перечислено в последнем списке. Это просто проект для этой статьи такой урезанный.
Да и чем MySql плох? За что его так сравнивать с мотором от инвалидки? Разве не умеет хранить данные? Умеет. А в чём дело?
В статье показаны тормоза на практически пустой базе после свежей установки. Исходники есть в гитхабе, репозиторий тоже, методику я расписал, можете сами проверить. Речь не идёт о кривой структуре.
Крутили. Насколько я помню, там максимум в 36кб. Могу ошибаться. Но я точно помню, что не помогло.
А зачем? Я немного не понял смысл. MySql я расписал, чем был лучше. Он тупо быстрее работает во всех инструментах со своим стандартным протоколом из коробки. А зачем новый инстанс оракла ставить рядом? Чисто для тестов? Так прод всё равно будет в облаке, потому что начальство наотрез против переноса данных в офис.
Я тоже полностью поддерживаю! Стоило!
Именно поэтому я и эксперементировал с фетч сайзом. Я вообще крутил всё, до чего мог дотянуться. А дотянуться я не мог разве что до настроек самого инстанса оракла.
А сейчас мне это не интересно. Я не работаю в этой компании полтора года как. Ну узнаю я, как это можно было починить, а что дальше? Статья вообще не об этом.
Да, смотрел. Изначально как раз хотел взять его в паре с EF core. Клиент им сериализует запрос, а сервер нахлобучивает его на репозиторий EF. Не срослось, и я взял только идею оттуда.
Спасибо. Include это не совсем join. Да, он транслируется в left join, но может работать только по внешнему ключу (в случае с OrmFactory ещё и по виртуальному внешнему ключу). То есть его условие вшито в модель.
Про причину тормозов я так и не узнал. Тогда я крутил всё, что крутилось на клиенте, а сейчас мне уже не актуально.
То, что смена протокола (добавление gRPC на участке с задержкой) увеличила скорость - я этот эксперимент буквально вчера повторил. Да, похоже на то, что протокол оракла ждёт подтверждения (или запроса) со стороны клиента. Но как действительно это работает - я не знаю.
Если работаете с WPF, то почему бы не попробовать? Синтаксис оттуда переносится чуть ли не 1:1. Всё же зависит от того, чего вы хотите. Если странного, как я - то это боль и страдание. Если всё стандартное подходит - то даже не заметите проблем. Мне миллионы строк надо скроллить в гриде, у меня своя атмосфера. Может у вас совсем не так. Мне критично было сделать поддержку для макбуков arm64. Линукс у меня чисто как бонус. В линуксе, кстати, не работает размытие фона с прозрачностью, но оно тоже далеко не всем надо.
Авалония довольно глючная штука. То одно отвалится, то другое. Странно очень потроха сделаны, по мне так перемудрили со архитектурой. Захочешь заоверрайдить что-то в контроле - не сможешь. Я сталкивался с тем, что вот потроха - напиши свой контрол, но нет. Нужные компоненты internal или вообще protected. Зачем?
Для бизнес-разработки нужны продвинутые контролы, их просто нет под авалонией. Вроде еремекс что-то пилит, но я не помню у них демо-контролы в паблике.
Иногда свой контрол в разы проще написать, чем победить все баги родного. У меня так с датагридом было.
Они ещё хотели сделать TreeDataGrid платным зачем-то. А аналогов ему нет. Это тоже смущает. Хотя та ещё забагованная и тормозная штучка. Никак не мог заставить его стоять и не дёргаться при обновлении вьюмодели. Плюнул, написал свой.
С другой стороны Авалония уникальна. Она сама рисует контролы на всех платформах и не зависит от багов UI-прокладки. Если работает на одной платформе - работает на всех. И выглядит одинаково. Это позволяет не отлаживаться и подгонять контролы под каждую платформу.
Альтернатив особо нет. Есть Uno Platform, он стабильнее, но это прокладка к родным контролам. Есть MAUI, с ним также, да ещё он мобильно-ориентирован. Грусть и печаль.
Пойду доедать свой кактус.