Отношение «один на один» - вредно ли сохранять отношение в обеих таблицах?

Question

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

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

Таблица пользователей: идентификатор_пользователя, имя, возраст, идентификатор_символа

Таблица символов: идентификатор_символа, форма, идентификатор_пользователя

Я должен сделать это для производительности, как вы об этом думаете?

Answer 1

В отношении 1: 1 должна оставаться запись, которая будет считаться «родительской».

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

Answer 2

Пара причин:

• Избыточные данные
• Необходимо постоянно обновлять обе таблицы с правильными ключами ...

Answer 3

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

В качестве примечания: Вы говорите, что делаете это по соображениям производительности? Какие преимущества вы видели в этом? Поскольку независимо от того, из какой таблицы вы получаете доступ к данным, вы должны обнаружить (с правильными индексами), что разница очень мала? Возможно, здесь вы решаете не ту проблему, и, возможно, сначала нужно рассмотреть другие вещи (например, индексы, улучшение запросов и т. Д.).

Редактировать: Выбор свободных символов должен быть достаточно легким, поскольку вы могли бы избавиться от character_id из таблицы пользователей и иметь только user_id в одном символе:

Users:  user_id, name, age
Characters:  character_id, shape, user_id

Тогда вы сможете выполнить несколько таких запросов:

//something like this to query for free characters.
SELECT * FROM characters WHERE user_id IS NULL;

// To access a list of a users characters, you could do something like this:
SELECT * FROM characters WHERE user_id = 42;

// More information about the user, while still grabbing character info.
SELECT * FROM characters AS c INNER JOIN users AS u ON u.user_id = c.user_id WHERE u.user_id = 42;

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

Answer 4

Разумеется, такие данные можно разделить по соображениям производительности, особенно если вы работаете с большим количеством данных в большом количестве столбцов: например, вы можете просто поместить «базовую» информацию о пользователе в одну таблицу и подробные сведения (например, с большими текстовыми полями) в другом, потому что они не доступны так часто, как основные вещи. Возможно, вам нужны полнотекстовые возможности для частей данных, поэтому вы используете таблицы с разными механизмами хранения. Если ebaghaki нужно сделать это по соображениям производительности, я бы сказал, что все в порядке - будьте уверены, что ваше приложение обеспечивает действительность ключей (или использует триггеры, чтобы поддерживать актуальность?).

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