Сохраняет ли MYSQL его оптимальным образом, если одна и та же строка хранится в нескольких строках? - PullRequest
0 голосов
/ 10 августа 2009

У меня есть таблица, в которой один из столбцов является своего рода строкой идентификатора, используемой для группировки нескольких строк в таблице. Допустим, имя столбца - «карта», а одно из значений для карты, например, "Walmart". Столбец имеет индекс, потому что я использую его для фильтрации тех строк, которые принадлежат определенной карте.

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

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

Ответы [ 3 ]

4 голосов
/ 10 августа 2009

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

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

0 голосов
/ 11 августа 2009

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

Предположим, у вас есть таблица магазинов, в которую входит столбец StoreName. Среди значений в StoreName «WalMart» встречается 300 раз, а затем появляется «BalMart». Это просто опечатка для "WalMart" или это другой магазин?

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

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

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

0 голосов
/ 10 августа 2009

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

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

Другим решением будет использование типа данных ENUM , по крайней мере, если вы заранее знаете, какая строка будет в вашей таблице, и их всего несколько.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...