Это плохо для не использования нормализованных таблиц в этой базе данных?
Я недавно узнал о нормализации в своем классе информатики, и я разрабатываю многопользовательскую игру с помощью SQLite в качестве базы данных бэкенда в данный момент.
Некоторая информация о нем:
Упрощенная структура немного походит на следующее:
player_id | level | exp | money | inventory
---------------------------------------------------------
1 | 3 | 120 | 400 | {item a; item b; item c}
Хорошо. Как Вы видите, я храню таблицу/массив в строковой форме в столбце "материально-технические ресурсы". Это против нормализации.
Но вещь: Создание дополнительной таблицы для материально-технических ресурсов плееров приносит только недостатки для меня!
- Единственные точки, где я получаю доступ к базе данных:
- Когда плеер присоединяется к игре, и его профиль загружается
- Когда профиль игрока сохраняется
Когда плеер присоединяется, я загружаю его данные из DB и храню его в памяти. Я только пишу в DB как каждые пять минут, когда плеер сохраняется. Таким образом, существует на самом деле очень немного SQL-запросов в моем сценарии.
Если бы я использовал дополнительную таблицу для материально-технических ресурсов, то я имел бы к после загрузки:
- Выполните производительность и вероятно более информационно емкий запрос для выборки всех объектов от таблицы материально-технических ресурсов, которые принадлежат плееру X
- Обход через результаты и преобразовывает их в таблицу для устройства хранения данных в памяти
И после сохранения:
- Удалите все объекты из таблицы материально-технических ресурсов, которые принадлежат плееру X (плеер, возможно, отбросил/продал некоторые объекты?)
- Обход через таблицу и выполняет запрос для каждого объекта, которым владеет плеер
Если я сохранил все данные плеера в одной таблице:
- У меня только был бы один запрос для сохранения и загрузки
- Все было бы в одном месте
- Я только имел бы к (de), сериализируют таблицы после загрузки и сохранения, в моем сценарии
Что я должен сделать теперь?
Мои аргументы и ситуация выравнивают по ширине работу против нормализации?
8 ответов
Есть много возможных ответов, но вы можете выбрать тот, который вам подходит. Имейте в виду, ваш выбор может со временем измениться .
Если объем данных, которые вам нужно сохранить, невелик (например, помещается в одну строку таблицы), и вам нужно обновлять эти данные нечасто, и у вас нет причин заботиться о подмножествах этих данных, тогда ваш подход имеет смысл. По прошествии времени, когда ваши игроки получат больше предметов, а вы добавите больше персонализации в игру, вы можете начать выходить за пределы возможностей SQLite, и вам нужно будет развивать свой дизайн.Если вы обнаружите, что вам нужно иметь возможность запрашивать список предметов, чтобы определить, у каких игроков какие предметы есть, вам нужно будет усовершенствовать свой дизайн.
Обычно считается хорошей идеей наладить архитектуру данных на раннем этапе, но нет смысла сидеть сегодня на собраниях, пытаясь угадать, как вы будете использовать свое программное обеспечение через 5-10 лет. Лучше получить дизайн, отвечающий потребностям этого года, а затем запланировать повторную оценку дизайна через год.
Еще один случай преждевременной оптимизации.
Вы пытаетесь оптимизировать то, что у вас нет показателей производительности. Какая целевая платформа? Даже самые дрянные компьютеры в наши дни могут выполнять как минимум сотни ваших операций чтения в секунду.Затем вы добавляете лучшее оборудование для большего количества пользователей, затем вы можете перейти в облако, и когда вы попадете в проблемную область, с которой имеют дело Google, Twitter и Facebook, вы можете рассмотреть возможность денормализации. Даже в этом случае лучшим решением будет какая-то база данных типа "ключ-значение".
Возможно, вам стоит проверить статью в Википедии о Нормализация базы данных , чтобы напомнить вам, почему нормализованная база данных - это хорошо.
Вы также должны подумать о предметах. Являются ли элементы уникальными для каждого пользователя или у пользователя user1 может быть item1, а у user2 - item1. Если вы теперь хотите изменить item1, вам нужно просмотреть всю таблицу и проверить, у кого из пользователей есть этот элемент. Если бы вы нормализовали свою таблицу, это было бы намного проще.
Но это конец, я думаю, ответ таков: это зависит
Обосновывают ли мои аргументы и ситуацию работает против нормализации?
Не на основании того, что я видел до сих пор.
Нормализованные проекты баз данных (соответствующим образом проиндексированные и с эффективным использованием базы данных с UPSERTS, транзакциями и т. Д.) В механизмах общего назначения обычно превосходят по производительности код, за исключением случаев, когда код очень сильно оптимизирован. Обычно в таком коде отказываются от некоторых функций механизма СУБД общего назначения, таких как одно из свойств ACID или ссылочная целостность.
Если вы хотите иметь очень простой доступ к данным (вы рекламируете одну таблицу, один запрос как преимущество), возможно, вам стоит взглянуть на базу данных, ориентированную на документы, такую как mongodb или couchdb.
Что произойдет, если у вас будет сто тысяч предметов в вашем инвентаре, и вы хотите вернуть только два?
Если это то, что вы бросаете вместе, чтобы получить один. class и который вы больше никогда не будете использовать, тогда да, быстрый и грязный маршрут может быть для вас более быстрым вариантом.
Однако, если вы собираетесь работать над этим в течение нескольких месяцев, вы столкнетесь с долгосрочными проблемами с этим дизайнерским решением.
Вы хотите сказать, что, по вашему мнению, анализ строки из «инвентаря» не требует времени или усилий? Потому что все, что вам нужно сделать для хранения / извлечения элементов инвентаря из подтаблицы, - это то, что вам нужно сделать с этой строкой, а со строкой у вас нет никаких инструментов базы данных, которые помогли бы вам это сделать.
Кроме того, если у вас была отдельная подтаблица для элементов инвентаря, вы могли добавлять и удалять элементы в реальном времени, что означает, что если приложение выйдет из строя или пользователь отключится, они ничего не потеряют.
Нет, ваши аргументы недействительны. По сути, они сводятся к следующему: «Я хочу выполнить всю эту обработку в своем клиентском коде, а не в SQL, а затем просто записать все это в одно поле», потому что вы все еще выполняете всю точно такую же обработку для создания строки. Делая это, вы удаляете возможность легко загружать небольшую часть списка и теряете связи с фактической таблицей item , которая могла бы содержать дополнительную информацию об элементах (я предполагаю, что вы жестко кодируете все это на основе по именам вместо использования внутренних идентификаторов элементов, что, по-моему, очень плохая идея).
Не делай этого. В долгосрочной перспективе подход, который вы хотите использовать, принесет вам гораздо больше работы по мере развития ваших потребностей.
Причина, по которой вы используете любую технологию, состоит в том, чтобы максимально использовать ее преимущества. У SQL есть много преимуществ, которые вы, похоже, не хотите использовать, и это нормально, если они вам не нужны. В «Зодиаке» Нила Стивенсона главный герой упоминает, что немногие вещи, купленные в хозяйственном магазине, используются по прямому назначению. Программное обеспечение тоже такое. Важно то, что он работает, и он работает почти 100% времени, и он работает достаточно быстро.
И все же, я не могу не думать, что когда-нибудь у вас будет выпущен какой-нибудь сверхмощный предмет, и вы захотите решить эту проблему на уровне базы данных. Допустим, вы случайно выдали несколько предметов из инвентаря superinstakillmegadeathsword, которые убивают все в радиусе 50 метров при использовании (включая владельца), и вы хотите удалить эти предметы из игры. В качестве извинения перед людьми, которые потеряли свои предметы superinstakillmegadeathsword, вы хотите дать им 100 денег за каждый superinstakillmegadeathsword, который вы забираете.
При правильно нормализованной структуре базы данных это тривиальная задача. С денормализованной структурой это намного сложнее и медленнее. Нормализованную базу данных также будет проще расширить в будущем.
Вы уверены, что не хотите нормализовать базу данных?