Советы по проектированию базы данных в веб-приложении [закрыто]

Question

Есть ли у кого-нибудь какие-нибудь советы/советы по проектированию базы данных для веб-приложения?Такие вещи могут сэкономить мне много времени/усилий в будущем, когда/если приложение, над которым я работаю, вылетит и начнет активно использоваться.

Если быть немного более конкретным, приложение представляет собой стратегическую игру (на основе браузера, просто текстовая), в которой игроки в основном отдают «приказы», ​​которые будут сохранены в базе данных и обработаны позже, причем результаты также сохраняются там (история «заказов» и соответствующие результаты, вероятно, станут довольно большими).

Отредактировано, чтобы добавить больше деталей (как просили):

Платформа:Джанго

механизм базы данных:Я думал об использовании MySQL (если нет большого преимущества в использовании другого)

схема:все, что у меня сейчас есть, это несколько моделей Django, и это слишком много подробностей, чтобы публиковать их здесь.А если я начну выкладывать схемы, то это станет слишком конкретным, и я искал общие советы.Например, представьте, что я выдаю «заказы», ​​которые позже будут обработаны и возвращаю результат, который мне нужно сохранить, чтобы отобразить некую «историю».В этом случае лучше иметь отдельную таблицу для «истории» или только такую, которая агрегирует и «заказы», ​​и результат?Думаю, я мог бы кэшировать таблицу «истории», но это заняло бы больше места в базе данных, а также больше операций с базой данных, поскольку мне пришлось бы постоянно создавать новые строки, а не просто изменять их в сводной таблице.

Answer 1

Вероятно, вы затронули гораздо более широкую проблему проектирования с учетом высокой масштабируемости и производительности в целом.

По сути, при проектировании вашей базы данных я бы следовал передовым методам, таким как добавление внешних ключей и индексов к данным, которые, как вы ожидаете, будут часто использоваться, нормализовать ваши данные, разбив их на более мелкие таблицы, и определить, какие данные следует читать часто, а какие следует. пишут часто и оптимизируют.

Гораздо более важным, чем проект вашей базы данных для высокопроизводительных веб-приложений, является эффективное использование кэширования как на уровне клиента посредством кэширования HTML-страниц, так и на уровне сервера посредством кэширования данных или обслуживания статических файлов вместо динамических файлов.

Самое замечательное в кэшировании то, что его можно добавлять по мере необходимости, так что, когда ваше приложение начнет работать, вы сможете развиваться соответствующим образом.

Что касается ваших исторических данных, их удобно кэшировать, поскольку вы не ожидаете, что они будут часто меняться.Если вы хотите создавать регулярные и довольно интенсивные отчеты на основе ваших данных, рекомендуется поместить эти данные в другую базу данных, чтобы не останавливать ваше веб-приложение во время его работы.

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

Answer 2

Нормализация базы данных, и хорошее размышление об индексах — это две вещи, которые вы просто не можете пропустить.Особенно если учесть игру, в которой SELECTS происходит гораздо чаще, чем UPDATEs.

В долгосрочной перспективе вам также следует обратить внимание на кэширование памяти, поскольку запросы к базе данных могут стать узким местом, если у вас больше нескольких пользователей.

Answer 3

Почему бы вам не опубликовать схему, которая у вас есть сейчас?Это слишком широкий вопрос, чтобы на него можно было дать полезный ответ без подробностей о том, какую платформу и базу данных вы собираетесь использовать, а также структуру таблицы, которую вы предлагаете...

Answer 4

Вам следует денормализовать ваши таблицы, если вы обнаружите, что объединяете более 6 таблиц в одном запросе для получения данных для веб-страницы типа отчета, которая будет часто использоваться.Кроме того, если вы используете библиотеки ORM, такие как Hibernate или ActiveRecord, обязательно потратьте некоторое время на сопоставления по умолчанию, которые они генерируют, и на sql, который в конечном итоге генерируется.Они, как правило, очень болтливы с базой данных, хотя вы могли бы добиться тех же результатов, обратившись к базе данных за один раз.