Вот только этот «банальный вывод» противоречит тезису из «краткого резюме»
Как раз никакого противоречия нет. Планируйте трудоёмкость «правильно» и живите спокойно.
«Правильно» в данном случае — хорошее знание матчасти и умение её применять в деле.
Ну и, конечно, без простого везения не обойтись (у английских капитанов, в личном деле, даже была такая графа — везучесть).
Так вы сами раскрыли суть этой задачи «Ничего универсального тут быть не может».
Здесь есть, как минимум, несколько интересных мест, над которыми можно поработать.
Например, «поиск по ключу — O(1)». Предположим, что один проход по ассоциативному массиву в миллиард, равен одной секунде.
Миллиард проходов даст миллиард секунд. Грустно. Но, если к этой задаче подключить архитектуру (например разделить процесс),
то можно значительно улучшить время (интересен так же и вопрос цены на единицу улучшенного времени). И это вовсе не «микрооптимизации», а здравый архитектурный подход.
Обычно бывает именно так, как вы описываете. Но, довольно часто, именно в настоящее время, Заказчик контракт подписывает, но остаётся недовольным и продолжает поиск исполнителя. Вас при этом, он в известность не ставит. И, если поиск удаётся, все недоработки по проекту — это основания, чтобы контракт разорвать, а если выясняется (не без помощи нового исполнителя), что была завышена смета, то легко получить претензию по неустойке.
А к вам не могут зайти простые ребята с трёхдневной небритостью? «Ночной кошмар программиста». Мне известны примеры, когда так были потеряны большие проекты.
Вы легко списываете полгода потраченного времени, но несколько гигабайт памяти, которые экономят эти полгода, считаете «дорогими». Где здесь логика? Вы можете объяснить?
А как вы поступаете, если, например, расчитанная трудоёмкость полгода, а найденное решение уложилось в 2 недели и нашли это решение «в соседнем отделе»? Или такого быть не может?
Я расчитывал на то, что задача «Быстрый поиск в ассоциативном массиве» вас заинтересовала. Если нет, то зачем же тогда вы продолжили обсуждение этой задачи?
Я еще раз спрашиваю: поиск по ключу или по значению?
Я ещё раз обдумал и пришёл к выводу, что придётся делать поиск и по ключу и по значению. Это нужно для разных функциональных этапов. Смотрите, в задаче существует состояние, когда в списке связи известен GUID (значение), но неизвестен ключ. Здесь однозначно нужен поиск по значению. И есть состояние когда нужен поиск по ключу, чтобы быстро получить значение.
А разве вы закладываете в проекты только универсальные решения? Каждый проект имеет свои ресурсные ограничения. Поэтому лёгкие функциональные решения не редко ценятся выше трудоёмких универсальных. Тем более лишняя трудоёмкость вовсе не гарантирует лучшего качества.
Извините, я конечно погорячился с универсальностью. Вопрос — GUID это ключ или значение? Я буду считать его значением, хотя изначально он является идентификатором, то есть ключом (поправьте как вам удобней, это не принципиально). Значит ключ — целочисленное число.
Если я правильно понял замысел задачи, то всем GUID-ам надо сопоставить ключи, и производить все выборки по ключам. Следовательно надо делать поиск по ключу.
Ну, вы же понимаете, что у вас тогда расход памяти еще веселее становится?
Да, я понимаю. Мне повезло, условия проекта были такие. В память всё влезло и никто не парился. Уверен, что существенный процент задач могут быть решены подобным образом.
И нет, это не типовые условия, потому что, например, у меня в типовых проектах целочисленных идентификаторов не было лет пять-восемь.
Это странно, делают конечно распредлённые системы на GUID-ах, но делают и по-другому, например на составных целочисленных ключах, или выделяют диапазоны. Так, что я утверждаю — вполне типовые.
1. Не понимаю смысла формирования GUID-ов разного типа для муравьёв и для ячеек:
(муравьи)
2d9bd55609174c029abc69c6fc2d02c5
(ячейки)
00000000491c61c0d1043fc221c3bff4
2. При подготовке результата (area-071, area-153,… ) всегда присутствует только по одной записи в каждом файле. Это недоработка?
Для разных прикладных задач потребуются разные структуры.
Как раз никакого противоречия нет. Планируйте трудоёмкость «правильно» и живите спокойно.
«Правильно» в данном случае — хорошее знание матчасти и умение её применять в деле.
Ну и, конечно, без простого везения не обойтись (у английских капитанов, в личном деле, даже была такая графа — везучесть).
Рамки требований определяет прикладная задача. Фактически, надо быть готовым ко всему. Все перечисленные варианты придётся рассмотреть.
«Один проход» — это «лукап» по всему массиву (в миллиард).
Речь идёт об оптимизации миллиарда обращений.
Здесь есть, как минимум, несколько интересных мест, над которыми можно поработать.
Например, «поиск по ключу — O(1)». Предположим, что один проход по ассоциативному массиву в миллиард, равен одной секунде.
Миллиард проходов даст миллиард секунд. Грустно. Но, если к этой задаче подключить архитектуру (например разделить процесс),
то можно значительно улучшить время (интересен так же и вопрос цены на единицу улучшенного времени). И это вовсе не «микрооптимизации», а здравый архитектурный подход.
А надо-то было всего докупить два чипа памяти.
Я ещё раз обдумал и пришёл к выводу, что придётся делать поиск и по ключу и по значению. Это нужно для разных функциональных этапов. Смотрите, в задаче существует состояние, когда в списке связи известен GUID (значение), но неизвестен ключ. Здесь однозначно нужен поиск по значению. И есть состояние когда нужен поиск по ключу, чтобы быстро получить значение.
Если я правильно понял замысел задачи, то всем GUID-ам надо сопоставить ключи, и производить все выборки по ключам. Следовательно надо делать поиск по ключу.
Что мешает заложить универсальный
Да, я понимаю. Мне повезло, условия проекта были такие. В память всё влезло и никто не парился. Уверен, что существенный процент задач могут быть решены подобным образом.
Это странно, делают конечно распредлённые системы на GUID-ах, но делают и по-другому, например на составных целочисленных ключах, или выделяют диапазоны. Так, что я утверждаю — вполне типовые.