Приветствую.
Не добившись от монго вменяемого поведения, было принято решение все-таки мигрировать на постгре.
Суть проекта - сбор информации с разных источников, частично парсинг, частично сами пользователи, частично с помощью человеческих ресурсов. Объем "записей" на начальном уровне ожидается ~50млн. В каждой группе данных от 5 до 10 полей.
Отсюда вопрос, как лучше выстроить структуру хранения данных, пока в голове только два варианта.
1. Все хранить в одной большой таблице вида:
ID / уникальное_поле / группа_полей_1 / группа_полей_2 / группа_полей_3
Соответственно все выборки делать по конкретным значениям полей, все данные в "исходном виде" и получаются проходом только по одной таблице, но большой (количество полей более 30) и с большой частью NULL-данных.
2. Разбить на 4 таблицы. главная из которых по сути только как полный список + доп.поля для наиболее активных выборок, остальные данные по группам:
- ID / уникальное_поле / данные_для_выборок
- ID / уникальное_поле / группа_полей_1
- ID / уникальное_поле / группа_полей_2
- ID / уникальное_поле / группа_полей_3
С учетом того, что для построения конечной картины каждой записи все-равно требуется получить все три группы и исходя из их значений получать конечное, но каждая таблица хранит только имеющиеся данные, а не все пустышки, и количество полей в каждой таблице не более 15. Большая по количеству только "главная таблица" с полями для выборок.
Например для:
- уникальное_поле = aaaa
- группа_1_поле_A = xxx
- группа_2_поле_A = yyy
- группа_3 - нет записи вообще
и по итогу выдать результат нужно по значению
- уникальное_поле = aaa, группа_2_поле_A = yyy
3. Мутированный вариант из №2, когда в главной таблице вести "итоговые рассчитанные поля", которые изменять при изменении данных в "дочерних таблицах":
- ID / уникальное_поле / итоговая_группа_полей
- ID / уникальное_поле / группа_полей_1
- ID / уникальное_поле / группа_полей_2
- ID / уникальное_поле / группа_полей_3
Большая получается "главная таблица" с полями с итоговыми данными, но их будет опять же не больше 15 против более 30 в первом варианте. И для обычных выборок не требуется обращаться к другим таблицам и производить склейку/выбор.
ЗЫ. Уточнение ID - это поле идентификатора записи для первичного ключа. Уникальный индекс по сути сквозной единый, он же ключ связи - строка, в число не переделать
Средний
