Да, я часто использую Нотацию "большого О", или скорее я использую мыслительные процессы позади нее, не саму нотацию. В основном, потому что так мало разработчиков в организации (организациях), которую я часто посещаю, понимает его. Я не означаю быть непочтительным к тем людям, но по моему опыту, знание этого материала является одной из тех вещей что "виды мужчины от мальчиков".
интересно, является ли это одним из тех вопросов, которые могут только получить "да" ответы? Это ударяет меня, что группа людей, которые понимают вычислительную сложность, примерно эквивалентна группе людей, которые думают, что это важно. Так, любой, который мог бы ответить не, возможно, не понимает вопроса и поэтому пропустил бы по следующему вопросу, а не паузе для ответа. Просто мысль;-)
По сути, когда вы используете хранилища ключей и значений, вы строите базу данных из тех же компонентов, что и реляционная база данных внутри. Причина в том, чтобы иметь больший контроль и гибкость при масштабировании и производительности или просто для простоты.
В этом случае вам нужно сохранить эквивалент строк таблицы и индекса как две отдельные вещи. Поэтому, если вы хотите индексировать по цвету, вам нужно сохранить
{'blue': {123456}}
в эквиваленте индексной таблицы.
Конечно, некоторые хранилища ключей и значений предоставляют вам механизмы индексации и поиска, поэтому нет общего правила, что подходит всем.
Вы хотели бы поддерживать отдельное хранилище ключей / значений, которое по сути является индексом. В качестве ключа должен быть «синий», а затем список всех идентификаторов из «основного» магазина автомобилей, которые являются синими.
Да, это дублирует функциональность индекса обычного rdbms.
Это хорошая статья о том, как команда FriendFeed подошла к этой проблеме и остановилась на этом решении, а также их обоснование (я знаю, это немного странно, поскольку они использовали СУБД в качестве хранилища ключей / значений, но темы для обсуждения остаются теория звука):
http://bret.appspot.com/entry/how-friendfeed-uses-mysql