История изменений
Исправление maxcom, (текущая версия) :
Допустим я в полях некоторого столбца храню большие данные, и допустим они часто повторяются.
Обычные реляционные СУБД таким не занимаются. Такая логика есть, например, в индексах Lucene (Elasticsearch, OpenSearch и др). Наверняка что-то подобное можно обнаружить в аналитических базах вроде Clickhouse, но не уверен.
Я знаю 2 способа быстрого поиска элемента в контейнере
СУБД не используют красно-черные деревья, потому что они плохо работают на дисковых хранилищах. Вместо этого используются другие сбалансированные деревья. В PostgreSQL есть возможность выбрать тип индекса – «btree» по-умолчанию и «hash» по выбору. Но я еще ниразу не видел, чтобы hash кто-то использовал.
Исходная версия maxcom, :
Допустим я в полях некоторого столбца храню большие данные, и допустим они часто повторяются.
Обычные реляционные СУБД таким не занимаются. Такая логика есть, например, в индексах Lucene (Elasticsearch, OpenSearch и др). Наверняка что-то подобное можно обнаружить в аналитических базах вроде Clickhouse, но не уверен.
Я знаю 2 способа быстрого поиска элемента в контейнере
СУБД не используют красно-черные деревья, потому что они плохо работают на дисковых хранилищах. Вместо этого используются другие сбалансированные деревья. В PostgreSQL есть возможность выбрать тип индекса – «btree» по-умолчанию и «hash» по выбору. Но я еще ниразу не видел чтобы hash кто-то использовал.