Реляционные базы данных и индексы

1. Храни в отдельной таблице эти блобы, в основной таблице ссылку
2. Да, например postgresql

хранились отдельно в уникальном виде (в самой базе данных), а в строках самой таблицы хранились например указатели на них

Это делается явно, т.е. ты сам должен так организовать хранение.

Есть ли РСУБД, которые позволяют выбирать между этими двумя опциями при создании индекса

Почти везде так можно.

хранить картинки в самой базе данных

Смотря что за картинки и в каком применении. Например иконки, или миниатюры может быть имеет смысл.

Допустим я в полях некоторого столбца храню большие данные, и допустим они часто повторяются. Есть ли в каких-нибудь РСУБД возможность сделать так, чтобы эти большие данные хранились отдельно в уникальном виде (в самой базе данных), а в строках самой таблицы хранились например указатели на них, или их хэши?

PostgreSQL хранит большие значения в отдельном хранилище. Не знаю, на счет уникальности. Нужно смотреть в документации, может и есть такое.

Допустим я в полях некоторого столбца храню большие данные, и допустим они часто повторяются.

Обычные реляционные СУБД таким не занимаются. Такая логика есть, например, в индексах Lucene (Elasticsearch, OpenSearch и др). Наверняка что-то подобное можно обнаружить в аналитических базах вроде Clickhouse, но не уверен.

Я знаю 2 способа быстрого поиска элемента в контейнере

СУБД не используют красно-черные деревья, потому что они плохо работают на дисковых хранилищах. Вместо этого используются другие сбалансированные деревья. В PostgreSQL есть возможность выбрать тип индекса – «btree» по-умолчанию и «hash» по выбору. Но я еще ниразу не видел, чтобы hash кто-то использовал.

1. почему бы не хранить в файлах, а в бд держать пути к ним?

Ну и вообще, есть ли случаи, когда целесообразно хранить картинки в самой базе данных,

Да.

особенно применительно к sqlite?

Нет.

https://en.wikipedia.org/wiki/Column-oriented_DBMS
https://habr.com/ru/articles/95181/ Колоночные СУБД — принцип действия, преимущества и область применения

Ну и вообще, есть ли случаи, когда целесообразно хранить картинки в самой базе данных, особенно применительно к sqlite?

Смотря что за картинки. Я так делал хранение факсимиле и печати компании, чтобы при изменении юр.лица, автоматически с определённой даты на документах менялась печать и подпись. Удобно было.

А если что-то большое и в большом количестве, то возможно и лучше будет ссылкой на ФС хранить. А ключ, ну тут уже как душа пожелает.

hash же вроде вообще сломан был до недавнего времени.

hash же вроде вообще сломан был до недавнего времени.

Его починили несколько лет назад.

1. Один из основных принципов баз это дедупликация. В том же Clickhouse можно сделать колонку LowCardinality(String), которая создаст дополнительный словарь для ускорения. В Postgresql наверное надо хэши хранить рядышком, а уж про встроенные решения с btree индексом уже написали.
2. Многие базы и файловые системы на B-tree, в том числе самые производительные вроде Clickhouse. Такая уж удачная структура у него.

Допустим я в полях некоторого столбца храню большие данные, и допустим они часто повторяются. Есть ли в каких-нибудь РСУБД возможность сделать так, чтобы эти большие данные хранились отдельно в уникальном виде (в самой базе данных), а в строках самой таблицы хранились например указатели на них, или их хэши?

А не рассматривал вариант самому считать хэш и не заниматься постоянно отправкой больших повторяющихся данных на сервер, а только при необходимости?

Привет. В дополнение к вариантам архитектурного выноса в отдельную таблицу, добавлю: в Oracle есть такая штука - BFILE. Это ссылка на blob, хранящийся как отдельный файл. Ну и держим в голове, что blob>4000 байт сам хранится в отдельном экстенте (не в таблице). Как-то раз делал небольшое приложение на хранимках, так там все картинки/иконки для вебинтерфейса хранились в блобах, файлов (кроме субд) вообще не было :)

большие данные хранились отдельно в уникальном виде (в самой базе данных), а в строках самой таблицы хранились например указатели на них, или их хэши?

В постгресе это называется large objects. У конкурентов что-то такое тоже должно быть.

Не рекомендую, бэкап/развёртывание базы превращается в ту ещё мазафаку.

Ну и вообще, есть ли случаи, когда целесообразно хранить картинки в самой базе данных, особенно применительно к sqlite?

На мой взгляд нет. Каждый раз попытка хранить в базе большие бинарные данные кончалась переделкой.

Да.

А можешь пример привести? Я сколько ни видел попыток, все заканчивались плохо.

1. В контент-провайдере мелодий-картинок в OracleBI картинки хранились как атрибуты - так их было сразу видно в BI . Естественно, бд была не в фс, а оракловый партишн, а в раздаче клиентам оно было в фс. И это было 20 лет назад.

2. На локальном flask+postgres под офтопиком для разработки и отладки MVP

Точно, так оно было, bfile, а не блоб.

в том числе самые производительные вроде Clickhouse.

Ой да ладно. В случаях, когда нужны все поля из записи колоночная организация данных будет всегда сливать по производительности.

там все картинки/иконки для вебинтерфейса хранились в блобах

Я тоже как-то так делал на psp , но внезапно выяснилось, что при такой организации картинки на клиенте не кешируются, а каждый раз тянутся из базы.

В общем, так лучше не делать.

1. В оракловый партишен я в принципе могу поверить, окей, там и бэкапы делает специально обученный сертифицированный человек.

2. Я всё же больше про запущенное в эжксплуатацию. Локалхост и не такое стерпит.

про запущенное в эжксплуатацию

Эксплуатация тоже разная бывает. У меня в одной конторе скоро 10 лет как крутится Postgres с картинками внутри. Там нагрузка/объемы позволяли так сделать, чтоб не связываться с правами доступа ещё и на уровне файловой системы.

Astra + мандатный доступ внутри ПГ + RowLevelSecurity = не надо думать про безопасность на уровне файлов отдельно.

Главное только не доводить до того, что закончится место на ФС. Потому что как это случится так наступит тупиковая ситуация, которую довольно сложно разрешить.

Ходил недавно к ним - один диск в зеркале сдох, меняли. Вроде всё нормально выглядит в остальном.