Postgresql. Проектирование
Нужна помощь в проектировании базы-данных для избежания дальнейших проблем в разработке. Имеются объекты с 15 полями (+- 2 поля). Около 10 полей у всех объектов одинаковые. Но остальные поля могут сильно отличаться в зависимости от объекта. Эти отличающиеся поля также могут сильно влиять на функционал. Привести их к единому виду не представляется возможным. На данный момент есть 3 вариации этих доп. полей, в будущем будет больше. Как хранить доп. поля в базе-данных?
Например:
Одинаковые поля: id, name, desctipton и т.д.
1 вариация полей: val1, val2, val3
2 вариация полей: val4, val5, val6, val7
3 вариация полей: val8, val9
PS. Есть вариант, создать отдельную таблицу для этих полей, но не превратится ли это все в сложную неконтролируемую махину
Ответы (2 шт):
На самом деле все зависит от того сколько данных предполагается иметь в таблицах.
- Если данных не много порядка нескольких тысяч то не проблема держать все данные в одной таблице и работать с ней как со справочником в котором хранятся различные данные которых не много.
- Данных много - то ваши поля которые якобы повторяются, а на деле они различные (id, name, createdOn, status .... это стандартный набор полей) то в систему намеренно добавляют излишние данные (уходят от 3 нормальной формы) во избежание лишних соединений с большими таблицами.
Вывод. С точки зрения расширяемости системы удобно когда все разделено и вы по отдельности можете добавлять необходимые поля в таблицы. Как говорится по принципу Open Closed.
Называть поля val1, val2, ... считаю плохой затей, если уж так хочется записать туда что нибудь этакое используйте не структурированные данные. А лучше уж держать в структурированной базе нормальные наименования что бы не возникало проблем в будущем.
ПО сути задача сводится к выбору из трех вариантов:
Я бы предложил подготовить примеры запросов который надо будет выполнять согласно бизнес логике и сделать бенчмарки. Чисто интуитивно я бы склонялся к single table но это только догадка, так как из описания проблемы плохо понятно что мы будем делать с данными. Как писать и как читать и есть ли хоть какая то логика вокруг общих полей. Так как для полей только таких как -> id, name, desctipton я бы вообще не думал об общей таблице если природа этих сушностей не иерархична. Кстати постгрес имеет поддержку наследование
Одно только пердостережение не использовать json для хранения строго структурированных данных, хоть у постргресса и хорошая поддержка этого типа. Но зачастую работать со структурированными данными проще и быстрее так как различные индексы можно подвязать к отдельным колонкам.