На данный момент у меня есть несколько таблиц различного типа ресурсов, например Company, Worker, Resume, Vacancy. У каждой сущности свои поля и соответственно колонки в таблицах этих сущностей. Часть полей общие для нескольких сущностей, например, address - общие поля для сущностей Company и Worker.
Кроме описанных выше сущностей (назовем их ресурсы) есть сущности, имеющие привязку к одному из ресурсов. Например, Discussion и Note. У меня они хранятся в таблицах, имеющих колонки resource_type и resource_id, которые содержат тип и id ресурса, к которому привязана дискуссия или заметка.
Я хочу свести все типы ресурсов в одну таблицу resource, в которой будут все колонки всех типов ресурсов, я просто поставлю префиксы для типов в названиях колонок. Общие для сущностей колонки будут или без префикса или с каким-то, например common_.
В связанных таблицах соответственно уйдет колонка resource_type и останется только ссылка по resource_id.
Вопрос - Какие недостатки такого решения с разреженной таблицей с большим количеством пустых полей в записях с точки зрения потребления оперативной памяти, места на диске и скорости выполнения SELECT запросов к такой таблице, по сравнению с имеющимся решением? При условии наличия индексов по всем полям, по которым будет фильтрация и сортировка.
Спрашиваю потому, что слабо знаком с тем, как postgresql хранит данные, как затаскивает в оперативную память, как кеширует запросы в памяти, как на это все влияют индексы.. Как говорится, в целом то понятно, но что конкретно там происходит.. Надеюсь на ответ более опытных товарищей.
Колонок в таблице resources будет около 70 в сумме, в основном все типа text, bigint (для связей с другими таблицами) и boolean.
Как PostgreSQL хранит данные
Как PostgreSQL хранит данные и затаскивает их в оперативную память вам в общем-то должно быть всё-равно.
Советую почитать материалы про нормализацию данных в ряляционных БД, про НФБК, 3-ю нормальную форму и прочее. Там и про недостатки в общем-то всё написано.
А по вашему решению, очень рекомендую ознакомится с разделом про поддержку НАСЛЕДОВАНИЯ в таблицах. Мне кажется это для вас будет более удачным решением.
Наследование уже смотрел
Наследование могло бы решить проблему наименования колонок в общей таблице (не нужны префиксы), но оно не решает мою задачу, которая заключается в том, чтобы избавиться от колонки entity_type в связанных таблицах, таких как notes и discussions.
Про нормализацию знаю. И да, можно избавиться от entity_type колонок сделав по связанной таблице для каждого типа ресурсов, аля company_notes, worker_notes, resume_notes, vacancy_notes, company_discussions, worker_discussions, resume_discussions, vacancy_discussions, но меня интересовало увеличится ли потребление памяти и просядет ли производительность при использовании того подхода, который я указал..
Тогда ответьте себе на
Тогда ответьте себе на вопрос. Как изменяется потребление памяти и производительность от изменения структуры файла который ЛЕЖИТ НА ДИСКЕ? Ответ очевиден - никак! На потребление памяти и производительность влияют ЗАПРОСЫ. Как раз искусство работы с SQL-сервером (любым, не только PostgreSQL) и состоит в грамотном составлении запросов. А чтобы грамотно составлять запросы, часто бывает необходимо корректировать структуру таблиц. Но никто и никогда вам не скажет как из-за этого изменится потребление памяти и производительность, ведь кроме вас никто не знает какие запросы вы пишете.
Да, файл то лежит на диске,
Да, файл то лежит на диске, но как раз для того, чтобы обработать запрос данные из файла должны ж как-то загрузиться в память, так вот меня интересовало будут ли излишки потребления памяти и снижение производительности одних и тех же запросов, если сравнить два случая:
1) есть одна таблица entity, которая сильно разряжена и содержит кроме колонок entity_id и entity_type колонки для нескольких видов сущностей (есть btree индексы по всем колонкам, по которым идет фильтрация и сортировка, можно также частичные индексы по каждому типу сущности сделать)
2) Есть общая таблица entity с 2 колонками entity_id и entity_type и несколько связанных таблиц, по одной на каждый тип сущностей (также есть все индексы по колонкам, которые присутствуют в where и order by частях запросов).