Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
В процессе реализации код и документ могут разойтись.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
А может и не стать. Собственно, это и причина поголовного вранья. Если понимаешь, что не возьмут без вранья, а выгонят или нет - это ещё неизвестно, да и опыта можно дорисовать на испытательном - выбор очевиден.
Только тем, у кого есть реальный опыт стало тяжелее устраиваться. Приходишь на собеседования и к тебе относятся заведомо как к лжецу.
Транзакций это один из способов безопасных операций с данными, если говорить по сути, то в ядре своем транзакций содержат идею того, что мы в них можем поместить какое угодно
Кто такой транзакций?
Не пишу в личку, потому что слишком много этого товарища в статье. Это не опечатка, это безмерная неграмотность.
Вообще впечатление такое, что человек писавший это вообще не понимает смысл слов. Поверхностный набор штампов. Никто ни к чему не придерётся, потому что тут даже не знаешь, за что браться.
Не все разработки в этом мире - онлайн магазины. Есть b2b, где каждый заказ индивидуален. Там в принципе не может быть корзины. Термины документооборота тоже могут быть разные. Если у вас quotation, то у нас это называется Purchase Order. Термин я взял у бизнеса, а тот у клиентов, которые пользуются SAP/R3. Ваш вариант не является единственно правильным.
Теперь про НДС. Если вы посмотрите на его расшифровку, то увидите, что он про добавленную стоимость. Это в выставленных документах всё просто - 20% от стоимости. В статье считается прибыль. И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
Так можно и спросить. Вообще из всех комментариев по существу этот первый.
Всего используется около 150 таблиц, из них чуть больше 10 работают через linq. Именно эти таблицы и весят 95% объёма, а остальные 140 кэшируются. Инвалидация производится трекингом данных. На каждый ряд свой таймстемп, по нему делается выборка свежеизменённых строк. Есть метатаблица с данными по каждой таблице, её таймстемпом и версии. Там же информация для кодогенератора, как именно создавать класс под эту сущность.
На первом этапе клиент сверяет метаинформацию по всем репозиториям одним селектом из метатаблицы. Определяет, какие репозитории требуется синхронизировать, делает синхронизацию каждого, взводит эвенты. Знаю, это надо было делать аппликейшен-сервером, но программистов не хватало.
В итоге в памяти кэшируется 140 таблиц, объёмом примерно 250мб. Загрузка происходит в окне логина (позволяет логин/пароль вводить параллельно, чтобы время не терять) и длится 25-30 секунд.
У системы, которая находится в эксплуатации 13 лет, уже нет потенциала для взрывного роста. Да, сначала информация накапливалась быстрее (низкая база), стали видны проблемы с нагрузкой. Первый сервер вообще имел 256мб на борту и как-то справлялся.
Относительно недавно был курьёзный случай. Эксплуатация решила, что серверу хватит 16гб памяти, потому что для 1С 80гб стало маловато. И MySql начал тормозить. При том, что в ERP сидит 100-150 человек, а в 1С от силы 15.
Соответственно, в БД лежит накопленная информация за примерно полторы тысячи человеко-лет.
При таких же темпах заполнения лет через 10 просто надо будет выделить сервер с 64гб памяти. Ну и наверное 16 ядер. Не слишком пугающая проблема, согласитесь?
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
к моменту выполнения второго запроса данные могут стать неактуальными
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
некую универсальную процедуру для демаршалинга
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.
Прочитав текст, я сделал вывод, что под "естественным" ключом подразумевается ключ из чужой ИС. Собственно вывод предсказуем: не доверяй никому. Особенно так делать нельзя, если планируется держать данные из разных сторонних ИС.
Не тремя. Даже не десятью. Нужно создать временную таблицу, перенести все данные, убрать индексы, убрать констрейнты, убрать внешние ключи, убрать триггеры. Дропнуть таблицу, переименовать временную, вернуть индексы, вернуть констрейнты, внешние ключи, пересоздать триггеры.
Вот чтобы всё это сделать нужно заморочиться. А чтобы это сделать без ошибок и для общего случая, нужно заморочиться сильно, прям очень сильно.
Почему ваше представление должно быть единственно правильным
А и не должно быть. Это вообще-то подмена тезиса. Я говорю про ВОЗМОЖНОСТЬ упорядочивания колонок, а вы мне про эгоцентризм. Если работаешь с людьми - тогда учитывай интересы людей.
Я обычно работаю над проектом один, и в этом режиме мне абсолютно плевать на мнение коллег о структуре данных.
Да, классная фича, оценил. В своё время я отказался от DG из-за одной "фигни", которая критична для меня. Мне нужен список полей с комментариями внутри таблицы. Этого в DG нет или я не нашёл.
Мне понравилось, как именно перетаскиваются колонки. Прямо вместе с мясом. Я себе так же сделаю.
Это проблема БД, потому что она хранит структуру таблиц. Внешние инструменты будут вынуждены синхронизироваться с ней и хранить данные о порядке вне структуры.
В любом случае есть факт. MySql позволяет встроенным синтаксисом менять расположение колонок, а оракл/мс/постгрес - нет. Вот и всё. Не надо мне доказывать, что мне это не нужно. Не надо предлагать костылями подпереть. Не надо скидывать ответственность на другие инструменты.
Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
А может и не стать. Собственно, это и причина поголовного вранья. Если понимаешь, что не возьмут без вранья, а выгонят или нет - это ещё неизвестно, да и опыта можно дорисовать на испытательном - выбор очевиден.
Только тем, у кого есть реальный опыт стало тяжелее устраиваться. Приходишь на собеседования и к тебе относятся заведомо как к лжецу.
Транзакций
Кто такой транзакций?
Не пишу в личку, потому что слишком много этого товарища в статье. Это не опечатка, это безмерная неграмотность.
Вообще впечатление такое, что человек писавший это вообще не понимает смысл слов. Поверхностный набор штампов. Никто ни к чему не придерётся, потому что тут даже не знаешь, за что браться.
Не все разработки в этом мире - онлайн магазины. Есть b2b, где каждый заказ индивидуален. Там в принципе не может быть корзины. Термины документооборота тоже могут быть разные. Если у вас quotation, то у нас это называется Purchase Order. Термин я взял у бизнеса, а тот у клиентов, которые пользуются SAP/R3. Ваш вариант не является единственно правильным.
Теперь про НДС. Если вы посмотрите на его расшифровку, то увидите, что он про добавленную стоимость. Это в выставленных документах всё просто - 20% от стоимости. В статье считается прибыль. И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
Так что берегите своих панд.
Так можно и спросить. Вообще из всех комментариев по существу этот первый.
Всего используется около 150 таблиц, из них чуть больше 10 работают через linq. Именно эти таблицы и весят 95% объёма, а остальные 140 кэшируются. Инвалидация производится трекингом данных. На каждый ряд свой таймстемп, по нему делается выборка свежеизменённых строк. Есть метатаблица с данными по каждой таблице, её таймстемпом и версии. Там же информация для кодогенератора, как именно создавать класс под эту сущность.
На первом этапе клиент сверяет метаинформацию по всем репозиториям одним селектом из метатаблицы. Определяет, какие репозитории требуется синхронизировать, делает синхронизацию каждого, взводит эвенты. Знаю, это надо было делать аппликейшен-сервером, но программистов не хватало.
В итоге в памяти кэшируется 140 таблиц, объёмом примерно 250мб. Загрузка происходит в окне логина (позволяет логин/пароль вводить параллельно, чтобы время не терять) и длится 25-30 секунд.
У системы, которая находится в эксплуатации 13 лет, уже нет потенциала для взрывного роста. Да, сначала информация накапливалась быстрее (низкая база), стали видны проблемы с нагрузкой. Первый сервер вообще имел 256мб на борту и как-то справлялся.
Относительно недавно был курьёзный случай. Эксплуатация решила, что серверу хватит 16гб памяти, потому что для 1С 80гб стало маловато. И MySql начал тормозить. При том, что в ERP сидит 100-150 человек, а в 1С от силы 15.
Соответственно, в БД лежит накопленная информация за примерно полторы тысячи человеко-лет.
При таких же темпах заполнения лет через 10 просто надо будет выделить сервер с 64гб памяти. Ну и наверное 16 ядер. Не слишком пугающая проблема, согласитесь?
Вы действительно хотите бенчмарк закешенных в клиенте данных против sql запроса по сети?
Давайте я угадаю? Это Oracle.
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Ну давайте, расскажите, как сложно разобраться с запросом, в котором есть WHERE, ORDER BY и LIMIT. У вас же код QueryBuilder перед глазами.
И заодно расскажите, почему перенос на клиента бизнес-логики заставит закупить мощное оборудование для базы данных. Ведь об этом статья.
Или Вы просто не читали статью?
При order by не существует решения вменяемой пагинации вообще-то. Я про него не забыл, я его не учитываю.
При требовании "не пропускать строки" пагинация бесполезна. Тут нужно сортировать ПОСЛЕ получения данных. Причём всех.
При показе пользователю метод last_id не нужен. Всё равно пользователь видит устаревшие данные, что там пропущено - это его проблемы.
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.
При том, что номер паспорта - это ключ из чужой информационной системы, например. Он ни в одном месте не естественный )
Прочитав текст, я сделал вывод, что под "естественным" ключом подразумевается ключ из чужой ИС. Собственно вывод предсказуем: не доверяй никому. Особенно так делать нельзя, если планируется держать данные из разных сторонних ИС.
Не тремя. Даже не десятью. Нужно создать временную таблицу, перенести все данные, убрать индексы, убрать констрейнты, убрать внешние ключи, убрать триггеры. Дропнуть таблицу, переименовать временную, вернуть индексы, вернуть констрейнты, внешние ключи, пересоздать триггеры.
Вот чтобы всё это сделать нужно заморочиться. А чтобы это сделать без ошибок и для общего случая, нужно заморочиться сильно, прям очень сильно.
А и не должно быть. Это вообще-то подмена тезиса. Я говорю про ВОЗМОЖНОСТЬ упорядочивания колонок, а вы мне про эгоцентризм. Если работаешь с людьми - тогда учитывай интересы людей.
Я обычно работаю над проектом один, и в этом режиме мне абсолютно плевать на мнение коллег о структуре данных.
Да, классная фича, оценил. В своё время я отказался от DG из-за одной "фигни", которая критична для меня. Мне нужен список полей с комментариями внутри таблицы. Этого в DG нет или я не нашёл.
Мне понравилось, как именно перетаскиваются колонки. Прямо вместе с мясом. Я себе так же сделаю.
Это проблема БД, потому что она хранит структуру таблиц. Внешние инструменты будут вынуждены синхронизироваться с ней и хранить данные о порядке вне структуры.
В любом случае есть факт. MySql позволяет встроенным синтаксисом менять расположение колонок, а оракл/мс/постгрес - нет. Вот и всё. Не надо мне доказывать, что мне это не нужно. Не надо предлагать костылями подпереть. Не надо скидывать ответственность на другие инструменты.