Когда вы говорите о «масштабировании», вы должны быть более точными в , какие операции вы хотите масштабировать? * Вам нужно оптимизировать чтение, запись, обе? дампы файлов? получить внешний контент?
Как только вы знаете что вы хотите масштабировать, часто вам также понадобится или вы захотите выяснить сколько вы хотите масштабировать до , если ваши настройки предложить любую выгоду на всех , путем сравнительного анализа и профилирования.
Это весело, в зависимости от контекста. Бенчмаркинг в субботу ночью не все в порядке.
Некоторые из известных мне методов оптимизации базы данных включают денормализацию и такие хитрости, которые вы не часто видите в обычных средах, поэтому использование этих «хаков» для повышения производительности иногда (часто) приводит к цене, например, за сопровождение кода. , В случае техники денормализации, о которой я упоминал выше, вы теряете часть целостности данных, которую ваша база данных предлагает , а затем вынуждены внедрять ее в код своего приложения .
Не так хорошо для разработчика, он должен копировать целостность данных в БД, просто чтобы ускорить запрос к базе данных. В свете вышесказанного, друг, по моему скромному мнению (будучи ленивым разработчиком), можно избежать многих проблем масштабирования , игнорируя проблемы масштабирования в первую очередь , пока они не возникнут.
Если вы хотите поговорить о стандартных, хороших методах построения БД, с общей точки зрения, я знаю только 2 основных способа: нормализованный и ненормализованный. У обоих есть подварианты, но я думаю, что они будут выглядеть как ваш A и ваш B. Оба являются допустимыми вариантами, и оба имеют свои плюсы и минусы, но если ваше приложение не будет затоплено тысячами обращений в минуту, я бы сказал, используйте А, может быть, что-то похожее на это:
Table votes - имеет первичный ключ vid,
Table questions - имеет первичный ключ
Table subscriptions - имеет первичный sid, внешний ключ vid, qid
Удачи, удачного кодирования!