Но сегрегация официально существовала чуть не до конца прошлого века. А первый условно черный президент появился только в 2009. Наверное должны сменится еще несколько поколений.
Проблема в том что многим черным не нужна ваша хорошая работа, им бы соц. пакет пожирнее.
Их можно понять: привезли на континент против воли, держали в рабстве сотни лет, а какое-то подобие равноправия начало появлятся только в самом конце прошлого века. У многих обида за это остается и сейчас. Ничего удивительного, что они не считают себя членами этого общества, не считают себя обязанными исполнять чужие для них законы, и т.п. Отсюда и высокая преступность, и ощущение что им все должны. Отцы-основатели британской империи явно не смогли предвидеть, что баланс сил может поменяться, и что за сделанное возможно прийдется расплачиваться их потомкам.
Пушеров видел, поэтому и избегаю. Их проблема в том, что они озабочены только лишь текущей сделкой, их обычно не волнует, что по прошествии времени человек в более спокойной обстановке может опять сложить все за и против, и прийти к выводу что его вообще-то поимели. Самый лучший риэлтор, которого я знал, больше отговаривал клиента, чем пытался продать. Он понимал, что его хлеб — referrals, и получит он их только если клиент останется все еще доволен спустя месяцы-годы после сделки. Соответственно и строил свою стратегию так, что лучше продать позже или вообще не продать, лишь бы клиент про него сказал потом кому-то что вот этот вообще-то честный риелтор.
Можно конечно и рекламные бюджеты и воронки использовать, каждый решает сам что ему больше подходит.
Ну не знаю, у автора какая-то своя реальность, возможно где-то с кем-то эти трюки и прокатывают. За себя скажу, что если мной пытаются манипулировать коробками конфет, дешевыми подарками, тратят на меня слишком много времени, всячески подчеркивают, что я у них эксклюзивный, в чем-то меня горячо убеждают, и т.п. то я это воспринимаю как попытку заставить меня почувствовать обязанным, и этим склонить к невыгодной покупке. От таких обычно ухожу. Или если продажник приезжает на новой красивой успешной машине, то тоже скорее вызвывает настороженность. А вообще на мой взгляд самое главное в таких продажах — referrals. Но вы их не получите если свою продажу людям втюхали.
Как заметили выше, если микросервисы обращаются к единой БД, то это не кошерный микросервис, а скорее, просто веб сервис. В этом случае теряется смысл их разбивать, так как велико количество внутренних связей. Но это все вопросы терминологии.
Теперь было бы интересно услышать как изменилась стоимость владения и поддержки: расследование бага в микросервисной среде требует обычно в разы больше времени. Также сама философия разбиения на микросервисы предполагает создание множества отдельных БД, а значит кучу процессов синхронизации между ними, а значит кучу дополнительных тикетов в поддержку, которых в случае монолита бы не было.
В общем ждем статью "От монолита к микросервисам — месяц (или год) спустя"
Информация о влиятельных предках Билла и связях его матери с IBM есть в вики, и вообще никто из этого тайны никогда не делал. Но самих по себе этих связей недостаточно чтобы так взлететь. Иначе все дети наших губернаторов, да и не только наших, конкурировали бы с Биллом — все они занимаются каким-то бизнесом, но до Билла им как до луны. Даже если Билл реально умный ботаник — тоже было бы недостаточно. Видимо была и удача, и скорее всего куча других случайных и не очень факторов.
Как-то в начале 2000х у меня патрульный мент на казанском вокзале вымогал деньги. Я прилетел из Франкфурта и ждал поезда чтобы ехать дальше в свой город. Он меня остановил для проверки документов, увидел в ЗП штамп, что я проживаю за границей, сказал что в паспорте не поставили какую-то отметку, и что надо пройти в участок для выяснения. Ну или чтобы я дал ему на бутылку хорошего коньяка, прямым текстом. Я мысленно попрощался с поездом и сказал, что пойду в участок, и что если что-то нарушено, то я хочу чтобы разобрались и все исправили, составили протокол если требуется, а про себя подумал, что иначе ко мне выстроятся все менты казанкого вокзала.
Это я к тому, что прежде чем сетовать, что менты берут взятки, надо перестать их давать. Я например, даже не знаю как предложить. Кто-то поумнее дает постоянно, но потом жалуются что менты коррумпированные. Где логика?
Мент тот, когда понял, что коньяка не будет, меня отпустил, ну а я для себя вывод что все правильно сделал.
Год назад собрал батарею 4S10P для вела (видео). Прошлое лето вел отъездил отлично, после чего зимовал в неотапливаемом гараже. А этой весной обнаружил, что одна из банок разряжена в ноль, а на другой 1.2 вольта. Остальные банки были ОК. Я при покупке замерял вольтаж всех 40 аккумов, и у пары из них вольтаж был процентов на 15 ниже, чем у остальных. Так вот просели как раз те банки, где стояли эти отличающиеся аккумы.
Но вроде удалось вылечить путем подавания на проблемные банки напряжения с маломощного блока питания 3-4 вольт, с тем чтобы на аккуме появилось хоть какое-то напряжение, чтобы включился БМС.
Выводы:
1) покупать аккумы лучше с запасом, так как скорее всего придется что-то отбраковать.
2) все аккумы надо перемерять и отбраковать отличающиеся. Что именно мерять — вольтаж, ток утечки или внутреннее сопротивление — тут дебатов много. В моем случае вольтажа было достаточно, так как за время доставки все утечки которые происходили в аккумах отразились именно на вольтаже. Измерять надо сразу после доставки, не пытаться их заряжать/разряжать перед этим.
Есть пословица: чем круче джип, тем дальше бежать за трактором
В данном случае — чем навороченнее BPM, тем труднее найти программиста, который в ней разберется в случае когда мышкокликальнебильных скилов недостаточно.
Много видел таких ВРМ, работая в разработке/поддержке разнообразных скриптов, доп. модулей костылей и интерфейсов, которые вокруг них обычно понавешаны.
Разрабы лучше бы просто записали бы номера в текстовый файл без хешей и паролей — как прокомментировали выше, обезличенные номера паспорта персональными данными не являются, их можно нагенерировать миллионы, алгоритм у всех таких идентификаторов одинаковый: префикс + последовательность + контрольная сумма. Тогда бы у Медузы не было повода на этом похайпить. А так, кто-то проявил инициативу зашифровать, а теперь все изберкомы огребают.
Я похудел с 75 до 68 при росте 170 сам того не желая. А дело было так. В возрасте 40 лет пошел к первый раз к врачу для проверки всего включая холистерин. Так как я бегал по 6 км, кушал тазиками салаты чтобы занять место (фу, гадость), а уж потом шашлыки и шоколадки, и пр., то я думал что холистерин уж у меня то точно не то что у всех остальных. В общем, сделали анализ, а там оказалась верхняя граница нормы. Это было как обухом по голове. Засел в интернеты и стал копать, что я делаю не так. Оказалось, что холистерин нарпямую из пищи практически не усваивается (привет чипсы и прочие шкворки, на которых пишут зеро-холистерин), а вырабатываются самим организмом из saturated и trans жиров. Стал читать на продуктах, сколько в них этих самых жиров, и узнал много интересного. Например, что количество этих плохих жиров в черном и молочном шоколаде одинаковое и очень высокое (десятки процентов рекомендованного дневного максимума). В стакане молока — 11%, в сосисках 30-60%. Их также очень дофига в говядине, сырах, кокосе, майонезе, сметане, (внезапно) китайской быстрорастворимой лапше, любых мясных субпродуктах, большинстве печений и плюшек, и много в чем другом. Все эти продукты я из рациона исключил, и стал ждать следующих ежегодных анализов. И вот они уже оказались нижняя граница нормы, что меня даже врач похвалил. Но бонусом обнаружилось что вес упал на 7 кг, и я нова влез и могу комфортно носить свои 20-летние костюмы.
Поэтому автору я бы порекомендовал попробовать слегка модифицировать меню:
Завтрак: стакан молока убрать, оставить 30 грам для кофе
Обед: сосиски заменить куриной грудкой, масло заменить томатной пастой, майонез поискать минимально жирный
Ужин: йогурт проверить на количество жира, так как они бывают очень разные
Ну и судя по никнейму автору уже пора следить за холистерином, то можно бы замерить до и после и сравнить.
Не очень понятно к какому действию побуждает статья...
Но последнее время тоже задумываюсь над общими моментами в работе программистов и законотворцев. И тут и там идет управление сущностями, в одном случае даными и их иерархиями в IT-системах, в другом — людьми и их иерархиями в реальной жизни. В одном случае программист придумывает правила, чем универсальнее тем лучше, и по ним данные создаются, перемещаются, обновляются. В другом случае законотворцы тоже придумываются правила, по которым между людьми и прочими юрлицами создаются, перемещаются и обновляются некие атрибуты, как виртуальные (права, обязанности, гражданство, претензии и пр.), так и материальные (дом, гараж, пенсия и т.п.).
Проблема в том, что у законотворцев нет своего языка программирования, и они вынуждены всю бизнес-логику описывать на обычном человечьем, что приводит к тому что их код невозможно читать если ты не юрист.
Поэтому думаю назрела необходимость создать ЯП ориентированный на описание законодательства. Тексты законов можно было бы тогда продублировать на этом языке, и тогда количество ориентирующихся в законах граждан выросло бы во много раз, так многие проходили в школе информатику.
Пример текста закона
ФЕДЕРАЛЬНЫЙ ЗАКОН О ГРАЖДАНСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ
Статья 6. Двойное гражданство
Часть 4.
Абзац 2.
Законный представитель гражданина Российской Федерации, указанный в абзаце первом настоящей части или в части 2 статьи 6 Федерального закона «О внесении изменений в статьи 6 и 30 Федерального закона „О гражданстве Российской Федерации“ и отдельные законодательные акты Российской Федерации», в связи с нахождением за пределами Российской Федерации не подавший уведомление, указанное в абзаце первом настоящей части, в сроки, установленные соответственно абзацем первым настоящей части и частью 2 статьи 6 Федерального закона «О внесении изменений в статьи 6 и 30 Федерального закона „О гражданстве Российской Федерации“ и отдельные законодательные акты Российской Федерации», обязан подать такое уведомление не позднее тридцати дней со дня въезда в Российскую Федерацию.
Вариант в коде короче и лучше, так как легче прописать последовательность действий в случае нештатных ситуаций.
Опаснсть возникновения лапши в таком коде конечно тоже существует, но хуже чем что есть сейчас в текстах законов вряд ли будет.
Ну и бонусом, если будет доступен код законов в компьютерном виде, то можно было бы и автоматизировать их исполнение.
Почему-то в статьях всегда обсуждают крайности, микросервисы против монолита. Почему не разбивать приложения на естественные куски с минимальным числом связей, назвать их сервисами, и иметь только плюсы обоих подходов?
Перешел на ДДГ уж несколько лет как. В 90% результаты поиска удовлетворяют. Оставшиеся 10% ищу на Яндексе, затем на Гугле, так что в гугль от меня попадает уж совсем неанализируемый треш.
Осталось еще отвязаться от ютуба, но альтернатив ему пока нет.
Когда-то давно реализовывал календарь в виде вьюхи, которая путем картезианского джойна 3-х виртуальных таблиц (день 1..31, месяц 1..12, год +-5 лет) генерировала все возможные сочетания день/месяц/год, отсеивала 30-31 февраля и прочие некорректные данные в WHERE-clause, и таким образом генерировала диапазон дат. Ну а праздники, карантины, перенесенные дни и прочие исключения были в отдельной OVERRIDE-таблице, которую вели вручную.
Результирующий календарь получался объединением этих 2х таблиц.
Остальные советы тоже хороши в ограниченном количестве случаев. Например, если работаете с финансами так лучше не делать :)
«Остальные советы» реализовывались как раз в финансах в телеком-биллинге. Там вообще это стандартная практика — копить транзакции за разные месяцы в отдельных таблицах. Там же пробовали и записи-плейсхолдеры. Они во много раз увеличивали скорость формирования стейтментов в конце месяца, так как данные каждого клиента были уже сгруппированы на диске, но естественно пришлось заплатить цену: загрузка системы при записи возрасла в разы, ну и какое-то количество плейсхолдеров оставалось неиспользованными, и БД слегка увеличилась.
Поэтому да, надо смотреть весь цикл жизни данных, в каком порядке ожидается поступление данных, когда, как часто и по каким критериям будет происходить чтение, насколько каждая из этих операций критична по времени, по целостности, какое есть железо, какая нужна надежность, требуемое время восстановления, и т.д. и т.п. И тогда уж принимать решение.
Вставка в таблицу без индексов обычно мгновенна и не зависит от размеров таблицы. Построение индекса на миллионах записей всегда быстрее, чем миллионы вставок в упорядоченную структуру. Я когда-то давно делал эти замеры на MySQL с количеством записей порядка миллионов, точных цифр у меня сейчас нет, но помню что разница по времени была в разы.
Но тут могут повлиять внешние факторы. Например этих нескольких минут на построение индекса может просто не быть, так как блокировка недопустима. В этих случаях может помочь
— разбиение на подтаблицы,
— hot swap таблиц путем переименования,
— доступ к данным через VIEW, который тоже можно переопределить мгновенно в зависимости от того, в каких таблицах в данный момент данные и индексы актуальны.
Еще можно предварительно создавать записи-placeholder-ы в индексировнной таблице, задав тем самым значения индексов для непоступивших еще данных, а при поступлении уже апдейтить какие-надо неиндексированные поля. Такой прием позволяет физически группировать записи в тот же самый блоке на диске, и потом прочитать их горздо быстрее, чем если бы записи были созданы в разное время и в разных блоках.
В общем поле извращений тут большое.
Из всего перечисленного единственная реальная проблема на мой взгляд — переработки. Все остальное в целом стандартно и ожидаемо.
А для решения проблемы переработок обычно достаточно вменяемого тимлида. У нас например тимлид ведет на каждого эксельную табличку с переработками/отглами (чтобы не портить корпоративный таймщит), и все довольны.
Странно, почему даже не попытались использовать Prepared statements для изначального INSERT-а, что было бы стандартным приемом для такого типа задач? В итоге все выродилось объединение/разбиение SQL-в в более длинные/короткие формы, и проблему так и не устранили…
Ожидал увидеть что-нибудь похардкорнее, типа разбиение на партиции/подтаблицы, выключение индексов на время инсерта, анализ физического расположения записываемых данных с целью их максимального эффективного группирования, прединсертные сортировки и т.п.
В общем странная статья, зачем ее было переводить…
Но сегрегация официально существовала чуть не до конца прошлого века. А первый условно черный президент появился только в 2009. Наверное должны сменится еще несколько поколений.
Их можно понять: привезли на континент против воли, держали в рабстве сотни лет, а какое-то подобие равноправия начало появлятся только в самом конце прошлого века. У многих обида за это остается и сейчас. Ничего удивительного, что они не считают себя членами этого общества, не считают себя обязанными исполнять чужие для них законы, и т.п. Отсюда и высокая преступность, и ощущение что им все должны. Отцы-основатели британской империи явно не смогли предвидеть, что баланс сил может поменяться, и что за сделанное возможно прийдется расплачиваться их потомкам.
Пушеров видел, поэтому и избегаю. Их проблема в том, что они озабочены только лишь текущей сделкой, их обычно не волнует, что по прошествии времени человек в более спокойной обстановке может опять сложить все за и против, и прийти к выводу что его вообще-то поимели. Самый лучший риэлтор, которого я знал, больше отговаривал клиента, чем пытался продать. Он понимал, что его хлеб — referrals, и получит он их только если клиент останется все еще доволен спустя месяцы-годы после сделки. Соответственно и строил свою стратегию так, что лучше продать позже или вообще не продать, лишь бы клиент про него сказал потом кому-то что вот этот вообще-то честный риелтор.
Можно конечно и рекламные бюджеты и воронки использовать, каждый решает сам что ему больше подходит.
Ну не знаю, у автора какая-то своя реальность, возможно где-то с кем-то эти трюки и прокатывают. За себя скажу, что если мной пытаются манипулировать коробками конфет, дешевыми подарками, тратят на меня слишком много времени, всячески подчеркивают, что я у них эксклюзивный, в чем-то меня горячо убеждают, и т.п. то я это воспринимаю как попытку заставить меня почувствовать обязанным, и этим склонить к невыгодной покупке. От таких обычно ухожу. Или если продажник приезжает на новой красивой успешной машине, то тоже скорее вызвывает настороженность. А вообще на мой взгляд самое главное в таких продажах — referrals. Но вы их не получите если свою продажу людям втюхали.
Как заметили выше, если микросервисы обращаются к единой БД, то это не кошерный микросервис, а скорее, просто веб сервис. В этом случае теряется смысл их разбивать, так как велико количество внутренних связей. Но это все вопросы терминологии.
Теперь было бы интересно услышать как изменилась стоимость владения и поддержки: расследование бага в микросервисной среде требует обычно в разы больше времени. Также сама философия разбиения на микросервисы предполагает создание множества отдельных БД, а значит кучу процессов синхронизации между ними, а значит кучу дополнительных тикетов в поддержку, которых в случае монолита бы не было.
В общем ждем статью "От монолита к микросервисам — месяц (или год) спустя"
Информация о влиятельных предках Билла и связях его матери с IBM есть в вики, и вообще никто из этого тайны никогда не делал. Но самих по себе этих связей недостаточно чтобы так взлететь. Иначе все дети наших губернаторов, да и не только наших, конкурировали бы с Биллом — все они занимаются каким-то бизнесом, но до Билла им как до луны. Даже если Билл реально умный ботаник — тоже было бы недостаточно. Видимо была и удача, и скорее всего куча других случайных и не очень факторов.
Как-то в начале 2000х у меня патрульный мент на казанском вокзале вымогал деньги. Я прилетел из Франкфурта и ждал поезда чтобы ехать дальше в свой город. Он меня остановил для проверки документов, увидел в ЗП штамп, что я проживаю за границей, сказал что в паспорте не поставили какую-то отметку, и что надо пройти в участок для выяснения. Ну или чтобы я дал ему на бутылку хорошего коньяка, прямым текстом. Я мысленно попрощался с поездом и сказал, что пойду в участок, и что если что-то нарушено, то я хочу чтобы разобрались и все исправили, составили протокол если требуется, а про себя подумал, что иначе ко мне выстроятся все менты казанкого вокзала.
Это я к тому, что прежде чем сетовать, что менты берут взятки, надо перестать их давать. Я например, даже не знаю как предложить. Кто-то поумнее дает постоянно, но потом жалуются что менты коррумпированные. Где логика?
Мент тот, когда понял, что коньяка не будет, меня отпустил, ну а я для себя вывод что все правильно сделал.
Год назад собрал батарею 4S10P для вела (видео). Прошлое лето вел отъездил отлично, после чего зимовал в неотапливаемом гараже. А этой весной обнаружил, что одна из банок разряжена в ноль, а на другой 1.2 вольта. Остальные банки были ОК. Я при покупке замерял вольтаж всех 40 аккумов, и у пары из них вольтаж был процентов на 15 ниже, чем у остальных. Так вот просели как раз те банки, где стояли эти отличающиеся аккумы.
Но вроде удалось вылечить путем подавания на проблемные банки напряжения с маломощного блока питания 3-4 вольт, с тем чтобы на аккуме появилось хоть какое-то напряжение, чтобы включился БМС.
Выводы:
1) покупать аккумы лучше с запасом, так как скорее всего придется что-то отбраковать.
2) все аккумы надо перемерять и отбраковать отличающиеся. Что именно мерять — вольтаж, ток утечки или внутреннее сопротивление — тут дебатов много. В моем случае вольтажа было достаточно, так как за время доставки все утечки которые происходили в аккумах отразились именно на вольтаже. Измерять надо сразу после доставки, не пытаться их заряжать/разряжать перед этим.
Есть пословица: чем круче джип, тем дальше бежать за трактором
В данном случае — чем навороченнее BPM, тем труднее найти программиста, который в ней разберется в случае когда мышкокликальнебильных скилов недостаточно.
Много видел таких ВРМ, работая в разработке/поддержке разнообразных скриптов, доп. модулей костылей и интерфейсов, которые вокруг них обычно понавешаны.
Разрабы лучше бы просто записали бы номера в текстовый файл без хешей и паролей — как прокомментировали выше, обезличенные номера паспорта персональными данными не являются, их можно нагенерировать миллионы, алгоритм у всех таких идентификаторов одинаковый: префикс + последовательность + контрольная сумма. Тогда бы у Медузы не было повода на этом похайпить. А так, кто-то проявил инициативу зашифровать, а теперь все изберкомы огребают.
Я похудел с 75 до 68 при росте 170 сам того не желая. А дело было так. В возрасте 40 лет пошел к первый раз к врачу для проверки всего включая холистерин. Так как я бегал по 6 км, кушал тазиками салаты чтобы занять место (фу, гадость), а уж потом шашлыки и шоколадки, и пр., то я думал что холистерин уж у меня то точно не то что у всех остальных. В общем, сделали анализ, а там оказалась верхняя граница нормы. Это было как обухом по голове. Засел в интернеты и стал копать, что я делаю не так. Оказалось, что холистерин нарпямую из пищи практически не усваивается (привет чипсы и прочие шкворки, на которых пишут зеро-холистерин), а вырабатываются самим организмом из saturated и trans жиров. Стал читать на продуктах, сколько в них этих самых жиров, и узнал много интересного. Например, что количество этих плохих жиров в черном и молочном шоколаде одинаковое и очень высокое (десятки процентов рекомендованного дневного максимума). В стакане молока — 11%, в сосисках 30-60%. Их также очень дофига в говядине, сырах, кокосе, майонезе, сметане, (внезапно) китайской быстрорастворимой лапше, любых мясных субпродуктах, большинстве печений и плюшек, и много в чем другом. Все эти продукты я из рациона исключил, и стал ждать следующих ежегодных анализов. И вот они уже оказались нижняя граница нормы, что меня даже врач похвалил. Но бонусом обнаружилось что вес упал на 7 кг, и я нова влез и могу комфортно носить свои 20-летние костюмы.
Поэтому автору я бы порекомендовал попробовать слегка модифицировать меню:
Завтрак: стакан молока убрать, оставить 30 грам для кофе
Обед: сосиски заменить куриной грудкой, масло заменить томатной пастой, майонез поискать минимально жирный
Ужин: йогурт проверить на количество жира, так как они бывают очень разные
Ну и судя по никнейму автору уже пора следить за холистерином, то можно бы замерить до и после и сравнить.
Не очень понятно к какому действию побуждает статья...
Но последнее время тоже задумываюсь над общими моментами в работе программистов и законотворцев. И тут и там идет управление сущностями, в одном случае даными и их иерархиями в IT-системах, в другом — людьми и их иерархиями в реальной жизни. В одном случае программист придумывает правила, чем универсальнее тем лучше, и по ним данные создаются, перемещаются, обновляются. В другом случае законотворцы тоже придумываются правила, по которым между людьми и прочими юрлицами создаются, перемещаются и обновляются некие атрибуты, как виртуальные (права, обязанности, гражданство, претензии и пр.), так и материальные (дом, гараж, пенсия и т.п.).
Проблема в том, что у законотворцев нет своего языка программирования, и они вынуждены всю бизнес-логику описывать на обычном человечьем, что приводит к тому что их код невозможно читать если ты не юрист.
Поэтому думаю назрела необходимость создать ЯП ориентированный на описание законодательства. Тексты законов можно было бы тогда продублировать на этом языке, и тогда количество ориентирующихся в законах граждан выросло бы во много раз, так многие проходили в школе информатику.
Пример текста закона
и эквивалентного кода
Вариант в коде короче и лучше, так как легче прописать последовательность действий в случае нештатных ситуаций.
Опаснсть возникновения лапши в таком коде конечно тоже существует, но хуже чем что есть сейчас в текстах законов вряд ли будет.
Ну и бонусом, если будет доступен код законов в компьютерном виде, то можно было бы и автоматизировать их исполнение.
Осталось еще отвязаться от ютуба, но альтернатив ему пока нет.
Результирующий календарь получался объединением этих 2х таблиц.
Поэтому да, надо смотреть весь цикл жизни данных, в каком порядке ожидается поступление данных, когда, как часто и по каким критериям будет происходить чтение, насколько каждая из этих операций критична по времени, по целостности, какое есть железо, какая нужна надежность, требуемое время восстановления, и т.д. и т.п. И тогда уж принимать решение.
Но тут могут повлиять внешние факторы. Например этих нескольких минут на построение индекса может просто не быть, так как блокировка недопустима. В этих случаях может помочь
— разбиение на подтаблицы,
— hot swap таблиц путем переименования,
— доступ к данным через VIEW, который тоже можно переопределить мгновенно в зависимости от того, в каких таблицах в данный момент данные и индексы актуальны.
Еще можно предварительно создавать записи-placeholder-ы в индексировнной таблице, задав тем самым значения индексов для непоступивших еще данных, а при поступлении уже апдейтить какие-надо неиндексированные поля. Такой прием позволяет физически группировать записи в тот же самый блоке на диске, и потом прочитать их горздо быстрее, чем если бы записи были созданы в разное время и в разных блоках.
В общем поле извращений тут большое.
А для решения проблемы переработок обычно достаточно вменяемого тимлида. У нас например тимлид ведет на каждого эксельную табличку с переработками/отглами (чтобы не портить корпоративный таймщит), и все довольны.
Ожидал увидеть что-нибудь похардкорнее, типа разбиение на партиции/подтаблицы, выключение индексов на время инсерта, анализ физического расположения записываемых данных с целью их максимального эффективного группирования, прединсертные сортировки и т.п.
В общем странная статья, зачем ее было переводить…