Тесты нужно проводить на тех областях, которые актуальны. Да, возможно, ИИ напишет похоже на слабоумного графомана короткую заметку. И это сложно будет отличить.
А давайте теперь проведём эксперимент на статьях хабра? Сколько процентов целевой аудитории отличит бессмысленную графоманию ИИ от статьи, где человек вложил скрытую мысль, а может и не одну.
И привести всё в один вид, где нет длинных тире и так любимых аишкой пунктов.
Зачем ты вообще пытаешься починить систему, которая почти два года не актуальна?
Ты хочешь сказать, что я плохие варианты выбирал и есть лучше? Но прости, ты не в курсе тысячи нюансов. Ты не в курсе, что я не пишу веб. Потому что не читал статью, где я про это говорил. Ты не в курсе, что бесконечный скролл хорош для просмотра постов на пикабу, но он категорически не подходит для работы аналитика. Ты не в курсе, что бэкенд под это дело тоже надо писать на сервере, хотя должен же быть, правда?
Менеджмент сам хотел вменяемую и быструю систему. Он сам подписался под графиком работ, о чём я в статье писал. Более того, менеджмент сам пообещал премию, если успеем к НГ. Никто их за язык не тянул. Но проект закрыли в октябре, хотя я шёл по графику, несмотря на три дополнительные задачи. Это стоило мне отпуска.
В подозрительных местах останавливаются, рассматривают детальнее. В каких-то местах идут медленнее, где-то проматывают.
Это натренированная годами на продажах нейросеть. Там используются такие параметры, о которых вы даже не подозревали, как погода на прошлой неделе в Воронеже. Только не спрашивайте, как это влияет на продажу плащей и зонтиков. Я не знаю.
Вот сидит манагер с большой таблицей. Ему нужно разобраться с аномалией, почему не складывается прибыль. Он группирует по товарной категории, сортирует по продажам и глазами пробегает, зажимая PgDown. Иногда меняет колонки местами, иногда подкручивает параметры вспомогательные. Он ищет места, где происходят аномальные скачки. Потом сверяет с датами, потом с другими категориями. Потом с остатками. Когда ему кажется, что он вроде нашёл - меняет группировку, сортировку и начинает выискивать, уже зная, где искать.
Манагер находит проблему и описывает её в бизнес терминах. Он хороший манагер, он за три часа делает то, на что отделу разработки понадобится два месяца. С написанием ТЗ, согласованиями, уточнениями, тестированием и приёмкой.
Идите и скажите ему, что он некомпетентный и не знает элементарные базовые вещи.
Зачем Вы это всё сейчас рассказываете? Выбор был актуален 3 года назад. Всё, что не работает с ораклом мы отмели сразу. Ода работает с ораклом? Ну а зачем её советовать? Кто будет многоэкранные pl/sql переписывать под него? Зачем вообще этот геморрой?
Вы сейчас примеряете общей гребёнкой весь бизнес. Не надо так. Есть действительно необходимость работать с большими данными из-за специфики. Когда у тебя десятки магазинов по всей стране, в 25 строчек ты не влезешь тупо списком магазинов. А есть категории, поставки, остатки и ещё много чего другого.
Не надо называть людей некомпетентными, когда вы просто не понимаете, в чём их работа состоит.
Мускуль никто не брал. Я его подключил в качестве развлечения к 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 нужно было понять, что вот этот левый объект уже заполнен и его можно отправлять на клиента.
Тесты нужно проводить на тех областях, которые актуальны. Да, возможно, ИИ напишет похоже на слабоумного графомана короткую заметку. И это сложно будет отличить.
А давайте теперь проведём эксперимент на статьях хабра? Сколько процентов целевой аудитории отличит бессмысленную графоманию ИИ от статьи, где человек вложил скрытую мысль, а может и не одну.
И привести всё в один вид, где нет длинных тире и так любимых аишкой пунктов.
Дружище. Ну вот зачем ты это говно советуешь?
Зачем ты вообще пытаешься починить систему, которая почти два года не актуальна?
Ты хочешь сказать, что я плохие варианты выбирал и есть лучше? Но прости, ты не в курсе тысячи нюансов. Ты не в курсе, что я не пишу веб. Потому что не читал статью, где я про это говорил. Ты не в курсе, что бесконечный скролл хорош для просмотра постов на пикабу, но он категорически не подходит для работы аналитика. Ты не в курсе, что бэкенд под это дело тоже надо писать на сервере, хотя должен же быть, правда?
Ну вот зачем?
Менеджмент сам хотел вменяемую и быструю систему. Он сам подписался под графиком работ, о чём я в статье писал. Более того, менеджмент сам пообещал премию, если успеем к НГ. Никто их за язык не тянул. Но проект закрыли в октябре, хотя я шёл по графику, несмотря на три дополнительные задачи. Это стоило мне отпуска.
Гораздо быстрее. Я сам видел, как они работают.
В подозрительных местах останавливаются, рассматривают детальнее. В каких-то местах идут медленнее, где-то проматывают.
Это натренированная годами на продажах нейросеть. Там используются такие параметры, о которых вы даже не подозревали, как погода на прошлой неделе в Воронеже. Только не спрашивайте, как это влияет на продажу плащей и зонтиков. Я не знаю.
Вот сидит манагер с большой таблицей. Ему нужно разобраться с аномалией, почему не складывается прибыль. Он группирует по товарной категории, сортирует по продажам и глазами пробегает, зажимая PgDown. Иногда меняет колонки местами, иногда подкручивает параметры вспомогательные. Он ищет места, где происходят аномальные скачки. Потом сверяет с датами, потом с другими категориями. Потом с остатками. Когда ему кажется, что он вроде нашёл - меняет группировку, сортировку и начинает выискивать, уже зная, где искать.
Манагер находит проблему и описывает её в бизнес терминах. Он хороший манагер, он за три часа делает то, на что отделу разработки понадобится два месяца. С написанием ТЗ, согласованиями, уточнениями, тестированием и приёмкой.
Идите и скажите ему, что он некомпетентный и не знает элементарные базовые вещи.
https://ru.wikipedia.org/wiki/Pentium_Pro#P6
Зачем Вы это всё сейчас рассказываете? Выбор был актуален 3 года назад. Всё, что не работает с ораклом мы отмели сразу. Ода работает с ораклом? Ну а зачем её советовать? Кто будет многоэкранные pl/sql переписывать под него? Зачем вообще этот геморрой?
Вы сейчас примеряете общей гребёнкой весь бизнес. Не надо так. Есть действительно необходимость работать с большими данными из-за специфики. Когда у тебя десятки магазинов по всей стране, в 25 строчек ты не влезешь тупо списком магазинов. А есть категории, поставки, остатки и ещё много чего другого.
Не надо называть людей некомпетентными, когда вы просто не понимаете, в чём их работа состоит.
Мускуль никто не брал. Я его подключил в качестве развлечения к 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 нужно было понять, что вот этот левый объект уже заполнен и его можно отправлять на клиента.