Как видите, общее согласие по этому поводу состоит в том, что "это зависит". Оптимизация производительности / запросов легко приходит на ум - как уже упоминалось @Campbell и др.
Но я думаю, что для типа базы данных для конкретного приложения, которую вы создаете, лучше всего начать с рассмотрения общего дизайна приложения. Для баз данных для конкретных приложений (в отличие от баз данных, предназначенных для использования со многими приложениями или инструментами отчетности), «идеальная» модель данных, вероятно, лучше всего соответствует модели вашего домена, реализованной в коде вашего приложения.
Вы не можете называть свой дизайн MVC , и я не знаю, какой язык вы используете, но я ожидаю, что у вас есть некоторый код или классы, которые оборачивают доступ к данным логической моделью. Как вы оцениваете дизайн приложения на этом уровне, я думаю, что лучший показатель того, как ваша база данных должна быть в идеале , должна быть структурирована.
Как правило, это означает, что сопоставление доменных объектов с таблицами базы данных - это одно из лучших мест.
Я думаю, что лучше проиллюстрировать, что я имею в виду, на примере:
Случай 1: один класс / один стол
Вы думаете с точки зрения Player класса. Player.authenticate, Player.logged_in ?, Player.status, Player.hi_score, Player.gold_credits.
Пока все эти действия являются действиями для одного пользователя или представляют собой однозначные атрибуты пользователя, единственная таблица должна быть отправной точкой с точки зрения логического проектирования приложения. Один класс (игрок), один стол (игроки).
Случай 2: несколько классов / одна или несколько таблиц
Возможно, мне не нравится швейцарский армейский нож Игрок дизайн класса, но я предпочитаю думать с точки зрения Пользователь , Инвентарь , Табло и Счет . User.authenticate, User.logged_in ?, Пользователь-> account.status, Scoreboard.hi_score (Пользователь), Пользователь-> account.gold_credits.
Я, вероятно, делаю это, потому что думаю, что разделение этих понятий в модели предметной области сделает мой код более понятным и простым для написания. В этом случае наилучшей отправной точкой является прямое сопоставление классов домена с отдельными таблицами: пользователи, инвентарь, результаты, счета и т. Д.
Практическое воплощение идеала
Я добавил несколько слов выше, чтобы указать, что однозначное отображение объектов домена в таблицы - это идеальный, логичный дизайн.
Это моя предпочтительная отправная точка. Попытка быть слишком умной с самого начала - как сопоставление нескольких классов обратно в одну таблицу - имеет тенденцию просто вызывать проблемы, которых я предпочел бы избежать (особенно тупиков и проблем параллелизма).
Но это не всегда конец истории. Существуют практические соображения, которые могут означать, что для оптимизации физической модели данных может потребоваться отдельное действие, например, проблемы параллелизма / блокировки? размер строки становится слишком большим? издержки индексации? производительность запросов и т. д.
Будьте осторожны, думая о производительности: просто потому, что это может быть одна строка в одной таблице, вероятно, не означает, что ее запрашивают только один раз, чтобы получить всю строку. Я полагаю, что сценарий многопользовательской игры может включать в себя целый ряд вызовов для получения различной информации об игроке в разное время, и игрок всегда хочет получить «текущую стоимость», которая может быть довольно динамичной. Это может привести ко многим вызовам только для нескольких столбцов в таблице каждый раз (в этом случае дизайн с несколькими таблицами может быть быстрее, чем дизайн с одной таблицей).