Схемы и индексы и первичные ключи: различия в производительности поиска?

Question

У меня есть база данных (точно запущенная на postgres) со следующей структурой:

user1 (schema)
|
 - cars (table)
 - airplanes (table, again)
 ...
user2
|
 - cars
 - airplanes
 ...

Она явно не структурирована так, как должны быть классические реляционные данные, но она "просто работает" как естьсейчас.Как видите, схемы похожи на первичные ключи, используемые для идентификации записей.

С точки зрения производительности - и ничего больше - стоит ли его перестраивать, чтобы он имел традиционные первичные ключи(это тип varchar) и кластерные индексы вместо схем?

Answer 1

С точки зрения производительности, на самом деле с любой точки зрения, безусловно, это НОЧЬ, РЕБИЛЬД!

Не зная больше о вашей ситуации, я думаю, что ответом будет ДА, это повлияет на производительность. Обычные простые запросы не только будут намного сложнее в написании и обслуживании, но и в БД будут создавать планы запросов, выполнение которых будет значительно более затратным.

Редактировать: Я работал и разрабатывал БД для обработки большого количества данных в средах с высокой рабочей нагрузкой (банковской и медицинской), и я никогда не видел ничего подобного; ну не в современном мире!

Answer 2

Так, похоже, у каждого пользователя просто есть своя схема?Часто большие, большие наборы данных разделяются близко к этому (чаще всего клиент во многих бизнес-сценариях).Это часто преждевременная оптимизация, потому что она вносит дополнительную сложность в ваше приложение, и одна таблица с пользовательским столбцом будет масштабироваться до разумного количества строк.

Однако то, действительно ли вы достигнете какой-либо производительности от объединения в единую схему, действительно зависит от того, выполняете ли вы много межпользовательских запросов (другими словами, запросы, которые должны пересекать схемы / таблицы).) и являются ли данные в каждом наборе таблиц эксклюзивными для этого пользователя.Если вы реплицируете данные из таблицы другого пользователя в другую, то вам необходимо как минимум преобразовать эти таблицы в общую схему.

Лично я стараюсь избегать подхода к схеме в обычных условиях (из-за дополнительных затрат на обслуживание и сложности приложения), но он имеет свое место.И вряд ли я бы назвал это «кошмаром», если я не понимаю что-то правильно.