Один к Одному отношению базы данных?

Работа реляционных баз данных над наборами, запрос базы данных там для поставки ни одного ("не найденный") или больше результатов. Реляционная база данных не предназначается для поставки всегда точно одного результата путем выполнения запроса (на отношениях).

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

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

Edith говорит: Комментарий нормализации: Ну, я никогда не видел базу данных, нормализованную к, он макс., и никто действительно не рекомендует что как опция. Так или иначе, если Вы точно не знаете, будут ли какие-либо столбцы нормализованы (т.е. вставьте другие таблицы), позже, то также легче сделать это с одной таблицей вместо "таблицы"-one-to-one-"другая таблица"

Отношения 1-1 являются просто вертикальным разделением. Ничто иное. сделайте это, если Вы по некоторым причинам, Вы не будете хранить все данные в той же таблице (говорят для разделения через несколько серверов и т.д.),

Материально-технические ресурсы являются many-one отношениями так или иначе, так вероятно, заслуживает его собственной таблицы (индексированный на его внешнем ключе, по крайней мере).

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

Сохранить ли

данные для входа плеера [отдельные] от другого в информации об игре (материально-технические ресурсы, статистика и состояние)

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

• имя пользователя: уникальное имя, которое позволяет пользователю входить в систему
• пароль: пароль: связанный с именем пользователя, которое гарантирует, пользователь уникален
• электронная почта: адрес электронной почты для пользователя; таким образом, игра может "ввести пользователя по абсолютному адресу", когда они недавно не играли
• символ: возможно разделите название ingame символа
• состояние: плеер и/или в настоящее время активный символ
• hitpoints: статистика в качестве примера для символа

Мы могли сохранить это как единственную таблицу или как несколько таблиц.

Единственный пример таблицы

Если у плееров есть отдельный символ в этом игровом мире, то единственная таблица может быть соответствующей. Например,

CREATE TABLE players(
  id         INTEGER NOT NULL,
  username   VARCHAR2(32) NOT NULL,
  password   VARCHAR2(32) NOT NULL,
  email      VARCHAR2(160),
  character  VARCHAR2(32) NOT NULL,
  status     VARCHAR2(32),
  hitpoints  INTEGER,

  CONSTRAINT pk_players PRIMARY KEY (uid)
);

Это позволило бы Вам находить всю уместную информацию о плеере с единым запросом на таблице плееров.

Несколько представляют пример в виде таблицы

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

-- track information on the player
CREATE TABLE players(
  id         INTEGER NOT NULL,
  username   VARCHAR2(32) NOT NULL,
  password   VARCHAR2(32) NOT NULL,
  email      VARCHAR2(160),

  CONSTRAINT pk_players PRIMARY KEY (id)
);

-- track information on the character
CREATE TABLE characters(
  id         INTEGER NOT NULL,
  player_id  INTEGER NOT NULL,
  character  VARCHAR2(32) NOT NULL,
  status     VARCHAR2(32),
  hitpoints  INTEGER,

  CONSTRAINT pk_characters PRIMARY KEY (id)
);
-- foreign key reference
ALTER TABLE characters
  ADD CONSTRAINT characters__players
  FOREIGN KEY (player_id) REFERENCES players (id);

Этот формат действительно требует соединений при рассмотрении информации и для плеера и для символа; однако, это делает записи обновления менее вероятно для приведения к несоответствию. Этот последний аргумент обычно используется при защите для нескольких таблиц. Например, если бы у Вас был плеер (LotRFan) с двумя символами (gollum, то frodo) в единственном формате таблицы у Вас были бы имя пользователя, пароль, почтовые поля дублированный. Если бы игрок хотел изменить свою электронную почту/пароль, то необходимо было бы изменить обе записи. Если только одна запись была изменена, таблица станет непоследовательной. Однако, если LotRFan хотел изменить его пароль в нескольких формат таблицы, одна строка в таблице обновляется.

Другие соображения

Использовать ли единственную таблицу, или несколько таблиц зависит от базовых данных. То, что не было описано здесь, но было отмечено в других ответах, - то, что оптимизация часто будет брать две таблицы и комбинировать их в единственную таблицу.

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

Как Вы видите, общее согласие на этом состоит в том, что "это зависит". Производительность/оптимизация запросов легко приходит на ум - как упомянуто @Campbell и другими.

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

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

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

Я думаю лучше всего для иллюстрирования то, что я подразумеваю под примером:

Случай 1: Один Класс / Одна Таблица

Вы думаете с точки зрения класса Плеера. Player.authenticate, Плеер logged_in?, Player.status, Плеер hi_score, Плеер gold_credits. Пока все они - действия с отдельным пользователем или представляют атрибуты единственного значения пользователя, затем единственная таблица должна быть Вашей начальной точкой с логической точки зрения проектирования приложений. Единый класс (Плеер), единственная таблица (плееры).

Случай 2: Несколько Классифицируют / Одна или несколько таблиц

Возможно, я не люблю дизайн класса Плеера швейцарского ножа, но предпочитаю думать с точки зрения Пользователя, Материально-технических ресурсов, Табло и Учетной записи. User.authenticate, Пользователь logged_in?, Пользователь-> account.status, Табло hi_score (Пользователь), Пользователь-> учетная запись gold_credits.

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

Создание практичного 'идеала'

Я вставил некоторые слова выше, чтобы указать, что взаимно-однозначное отображение объектов области к таблицам является идеалом, логической структурой.

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

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

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

Я рекомендую разделить их. Не по любым причинам базы данных, а по причинам разработки.

При кодировании модуля входа в систему плеера Вы не хотите думать о любой информации об игре. И виза-versa. Будет легче поддержать разделение проблем, если таблицы будут отличны.

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

я соглашаюсь с ответом Thomas Padron-McCarthy:

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

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

Люди смогли вывести дизайн, используемый Снежной бурей для World of Warcraft. Кажется, что поиски, плеер работает, снабжены символом. например:

CREATE TABLE Players (
   PlayerID int,
   PlayerName varchar(50),
   ...
   Quest1ID int,
   Quest2ID int,
   Quest3ID int,
   ...
   Quest10ID int,
   ...
)

Первоначально Вы могли идти самое большее 10 поисков, позже это было расширено до 25, например:

CREATE TABLE Players (
   PlayerID int,
   PlayerName varchar(50),
   ...
   Quest1ID int,
   Quest2ID int,
   Quest3ID int,
   ...
   Quest25ID int,
   ...
)

Это в отличие от дизайна разделения:

CREATE TABLE Players (
   PlayerID int,
   PlayerName varchar(50),
   ...
)

CREATE TABLE PlayerQuests (
   PlayerID int,
   QuestID int
)

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

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

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

Я предложил бы, чтобы Вы сохранили каждый тип записи в его собственной таблице.

Логины плеера являются одним типом записи. Материально-технические ресурсы - другой. Они не должны сидеть за одним столом, поскольку большей частью информации не делятся. Сохраните свои таблицы простыми путем выделения несвязанной информации.