Таблица указатель предложения - PullRequest
Новая
       17

Таблица указатель предложения

1 голос
/ 21 марта 2012

Я работаю со связями «многие ко многим» и читаю документацию, в которой предлагается не использовать первичные ключи или индексы.

Мне интересно узнать, что вы думаете о моей базе данных.

В нем только 2 столбца, каждый из которых имеет значения без знака bigint (миллионы строк).

Пример: 

012934567865434            10923883093280921
012984902348202            10923812122220677
012930245820556            77777883093123124
984017133446720            76567883093098765
098523467527659            09876583093890456

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

value1
..value1 repeated 100 times
value2
..vlaue2 repeated 20 times
value3
value3 repeated 60 times

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

Любое предложение о том, как оптимизировать с точки зрения:

  • создание индекса?
  • с использованием первичных ключей?
  • переупорядочение столбцов в порядке возрастания?Если да, то как часто?
  • Любая другая идея, которая, как вы думаете, могла бы ускорить ее!
    и т.д ..

Ответы [ 3 ]

1 голос
/ 21 марта 2012

При наличии отношения «многие ко многим» обычным решением является реализация трех таблиц, в которых table1 (== column1 в вашем примере) и table2 (== column2) будут содержать уникальные значения . в отношениях (и их первичных ключах, если необходимо), а table3 связывает два набора ключей.Отношения table1 и table2 до table3 будут один-ко-многим

Например:

table1 id1 (PK)col1col2... (больше столбцов) table2 id2 (PK)COLAcolB... (больше столбцов) Таблица3 id1id2.. в таблице 3 пара (id1, id2) будет формировать уникальный ключВ вашем случае table1 будет содержать уникальные значения из column1 и table2, то же самое из column2, тогда как table3 будет содержать уникальные пары значений.

1 голос
/ 21 марта 2012

Без корректности, производительность не имеет значения. Так как вы говорите (в комментарии) ...

"Комбинация определенного значения в 1-м столбце + 2-м столбце НЕ МОЖЕТ существовать более одного раза в таблице."

... правильное состоит в том, чтобы поместить оба поля в составной ключ.

Чтобы эффективно принудительно применить этот ключ, однако вам нужен индекс. Итак, вам нужен по крайней мере один индекс прямо здесь. Вопрос в том, какой индекс? Это зависит от «направления», в котором вы хотите запросить данные:

  • Если вам нужно эффективно ответить на вопрос «для данного value1, с которым value2 s связаны с ним», то индекс должен быть {value1, value2}.
  • Если вам нужно эффективно ответить на вопрос «для данного value2, с которым value1 связаны с ним», то индекс должен быть {value2, value1}.
  • Если вам нужно эффективно ответить на оба вопроса, тогда вам нужно оба индекса (но остерегайтесь цены, которую вы платите за вторичный индекс в кластеризованной таблице - см. «Недостатки кластеризации» в этой статье ).

Кстати, InnoDB создаст скрытый PK, если вы явно не указали какое-либо ограничение PK или UNIQUE. Это необходимо для кластеризации.

В СУБД, поддерживающей сжатие индекса (например, Oracle), вы можете сэкономить место, когда в переднем фронте индекса много повторяющихся значений. Хранилище дешево, но не в этом суть - меньшие данные фактически означают «больший» кеш.

Увы, MySQL не такая СУБД.

На более философском замечании не существует такого понятия, как "порядок", если вы сами не укажете его.

  • В таблице на основе кучи (MyISAM) физический порядок строк в куче примерно соответствует порядку INSERTions, но его лучше рассматривать как случайный с точки зрения клиента.
  • Кластерная таблица (InnoDB) - это, по сути, дерево, которое упорядочивает свои листы в соответствии с ключом кластеризации (которым является PK). Однако порядок результатов запроса не гарантируется , если в не указано ORDER BY.
  • Индексы в некотором смысле «упорядочены», но вы не получите результат запроса в каком-либо конкретном порядке, даже если индекс используется, , если в не указано ORDER BY.

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

0 голосов
/ 21 марта 2012

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

Помимо производительности, другаяпричина установки индекса заключается в предотвращении дублирования.

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

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

...