Много ли таблиц - эффективный дизайн базы данных для моих целей?

Question

Мне нужно создать базу данных для хранения информации о том, в каких регионах были игровые персонажи и как они туда попали.Я планирую сохранить символьный UUID в виде двоичного индекса (16), имя региона как varchar (25), а время Unix - как int;другие поля еще не полностью определены.

Мне также нужно хранить всю историю каждого региона, в котором когда-либо был пользователь, вместе с теми же данными.

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

Большинство запросов будет хотеть узнать только о вещах, связанных с персонажем, но некоторые захотят узнать о последних агентах, загруженных дляданный регион.Я намерен хранить эту информацию в отдельной таблице (таблицах).

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

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

Answer 1

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

Answer 2

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

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

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