Конечно, сделать такую оптимизацию можно только плотно поработав над задачей. Но она и так поэтапная:
1. убираем класс
2. смотрим, что в словаре True и False, и нам нужны только True, следовательно убираем False
3. понимаем, что словарь только из True бессмысленен, заменяем на set.
В статье приводится контр пример: как куча классов и 660 строк кода сжимаются в 3 строки, и оно работает так же. Вполне себе оптимизация. Работа с таким инструментом проще.
Между прочим, над словами «англицизм-дефис-существительное» я бы ещё поработал. «business» по-английски — это в т.ч. «предприятие». Поэтому если есть фирма-заказчик и фирма-исполнитель, то словосочетание business requirements — это не «бизнес-требования», как у нас безграмотно переводят, а «требования предприятия».
Но профессиональные переводчики не переводят отдельные слова, поэтому не так важно, что именно значит слова business idea, сколько всё предложение. Поэтому, мне кажется, «бизнес-идея» можно заменить на «коммерческая идея» или вообще что-то вроде «идея о новой услуге».
Ну вот реальная ситуация: продажи в 10 оптовых магазинах создают 500 000 строк в неделю, 3000 продуктов. Мне надо пересчитать годовые итоги и по категориям продуктов, и по отдельным из них. Руководитель просит дать ему таблицу в Excel. Не веб-отчёт.
Да, я как-то тоже замышлял OLAP на коленке с автоматической свёрткой по всем возможным измерениям. Но в конторе надо было дёшево и сердито, поэтому решили, пусть клиенты скажут, что им нужно, и обошлись простыми отчётами.
duckduckgo «postgres materialized view выдаёт»: «Materialized Views are currently the #1 requested feature in a user survey for addition to PostgreSQL.»
Ок, тогда, скажите, пожалуйста, можно ли сделать триггер, который бы не запускал пересчёт суммы по всей колонке, а увеличивал бы её на значение из добавленной записи?
Я когда-то работал в торговой сети, где было 500 магазинов и по 2000 наименований в каждом. Там решили хранить остатки за каждый день. Получилось, что каждый день прибавлялось бы по 50-100 мегабайт. Их не надо было бы пересчитывать, но если бы понадобилось корректировать, это была бы беда. И самое главное, что эти данные не были точными. Инвентаризации постоянно находили значительные расхождения. То есть хранить неточные оценочные данные не было большого смысла. Они нужны были только ради построения прогнозов, которые делали далеко не по всем наименованиям.
А вы уверены, что мы в России работаем? Не угадали, не в России. И не стоит обсуждать личности людей. По отдельности такие вещи знают многие, а вместе у понятном виде разные знания просто так не лежат. Если бы я нашёл подобные оптимизации в поисковиках, не писал бы эту статью.
Да, верно, люди с Вашим высокоразвитым интеллектом догадались бы за секунду. Им эта статья ни к чему. Однако моему техническому директору не было известно, что средняя разность раскладывается как разность средних, и её можно исправлять, и что квадратичные величины тоже раскладываются на суммы.
Не только. Ещё дисперсия. :) Проблема в том, что в обычных БД этого нет, даже суммы пересчитываются полностью — попробовал на postgres, те же проблемы, только пошустрее работает. По сути я пишу то, что должен делать встроенный оптимизатор запросов.
Ещё теги ограничены, и что-то новое мапить там можно только тогда, когда админы включат твой тег. В ОСМ что нужно, можно рисовать и обозначать как удобно, потом, когда тэги устаканятся, принимаются стандарты, и боты исправляют старые ошибки. Так же, насколько я понял, у НЯКа нет открытого АПИ, то есть частных ботов быть пока не может. Выгрузить в редактор и залить потом пакетом тоже нельзя. Нет трэков GPS. Это ограничивает работу только до рамок рисования по подложке. Нельзя импортировать векторные карты или апроксимировать по трекам. Поправьте, если ошибаюсь.
1. убираем класс
2. смотрим, что в словаре True и False, и нам нужны только True, следовательно убираем False
3. понимаем, что словарь только из True бессмысленен, заменяем на set.
greeter('превед')('кросавчег')
Но профессиональные переводчики не переводят отдельные слова, поэтому не так важно, что именно значит слова business idea, сколько всё предложение. Поэтому, мне кажется, «бизнес-идея» можно заменить на «коммерческая идея» или вообще что-то вроде «идея о новой услуге».
Я когда-то работал в торговой сети, где было 500 магазинов и по 2000 наименований в каждом. Там решили хранить остатки за каждый день. Получилось, что каждый день прибавлялось бы по 50-100 мегабайт. Их не надо было бы пересчитывать, но если бы понадобилось корректировать, это была бы беда. И самое главное, что эти данные не были точными. Инвентаризации постоянно находили значительные расхождения. То есть хранить неточные оценочные данные не было большого смысла. Они нужны были только ради построения прогнозов, которые делали далеко не по всем наименованиям.