Pull to refresh

Comments 1

Проектируйте модель так, как выглядит ваш бизнес на самом деле + так, как вы можете себе вообразить его выглядывание в будущем. Модель данных — это фундамент вашего здания. Лучше вначале заложить в модель предполагаемый вектор развития, чем потом устраивать фавелы и шанхаи.

Касательно нормализации — сначала всегда нормализуйте. Денормализовать сможете потом, когда лукапы и агрегирование на лету будут слишком затратны в силу ограничений производительности

И еще — помните, что требования к производительности системы чаще всего пропорциональны числу в диапазоне N^2 — N^3, где N — количество основных запросообразующих сущностей в системе. Имея самый оптимистичный прогноз на развитие вашего бизнеса, можно оценить сверху годовую скорость роста их количества.

Дальше — вывод — все частые и/или затрагивающие большое количество данных операции должны идти за логарифмическое время — а это, в свою очередь, говорит о том, что все эти операции должны идти исключительно с использованием поля индексов. Тогда вы сможете парировать увеличение нагрузки по мере роста количества данных и частоты запросов этих данных простым апгрейдом железа (железо ускоряется вследствие закона Мура быстрее, чем логарифмически). Если модель этого не допускает — значит, рано или поздно будет DoS со стороны БД.
Sign up to leave a comment.