SQL: что точно делают Первичные ключи и Индексы?
Nah - я не полностью соглашаюсь с правилами. Они - хорошие инструкции для рассмотрения с производительностью и стандартизацией, но не в свете возможностей.
, Как Вы видите в ответах, существует много творческих способов использовать их. Так, эти инструкции должны просто быть то, что, всегда ради производительности и эффективности.
В этом случае, я использую классы для представления объектов реального мира в их большей форме, я использую структуры для представления меньших объектов, которые имеют более точное использование. Путем Вы сказали это, "более связное целое". Причем ключевое слово связно. Классы будут более объектно-ориентированными элементами, в то время как структуры могут иметь некоторые из тех характеристик, хотя в меньшем масштабе. IMO.
я использую их много в тегах Treeview и Listview, где к общим статическим атрибутам можно получить доступ очень быстро. Я всегда изо всех сил пытался получить эту информацию иначе. Например, в моих приложениях базы данных, я использую Treeview, где у меня есть Таблицы, SPS, Функции или любые другие объекты. Я создаю и заполняю свою структуру, помещаю ее в тег, вытаскиваю ее, получаю данные выбора и т.д. Я не сделал бы этого с классом!
я действительно пытаюсь сохранить их маленькими, использовать их в единственных ситуациях с экземпляром и помешать им изменяться. Благоразумно знать о памяти, выделении и производительности. И тестирование так необходимо.
4 ответа
Первичный ключ обычно используется для создания числового идентификатора для ваших записей, и этот столбец идентификатора автоматически увеличивается.
Например, если у вас есть книги с полем id , где id является первичным ключом и также имеет значение auto_increment (в разделе «Дополнительно в phpmyadmin»), затем при первом добавьте книгу в таблицу, id для нее станет 1 '. Идентификатор следующей книги автоматически будет «2» и так далее. Обычно каждая таблица должна иметь хотя бы один первичный ключ, чтобы облегчить идентификацию и поиск записей.
Индексы используются, когда вам необходимо регулярно получать определенную информацию из таблицы. Например, если у вас есть таблица пользователей , и вам нужно будет часто обращаться к столбцу электронной почты , тогда вы можете добавить индекс электронной почты, и это приведет к тому, что запросы к электронной почте будут выполняться быстрее.
Однако у добавления ненужных индексов есть и недостатки, поэтому добавляйте их только в те столбцы, которые действительно нуждаются в доступе больше, чем другие. Например, запросы UPDATE , DELETE и INSERT будут немного медленнее, чем больше у вас индексов, так как MySQL должен хранить дополнительную информацию для каждого индексированного столбца. Более подробную информацию можно найти на этой странице .
Изменить: Да, столбцы, которые необходимо использовать в ORDER BY , должны иметь индексы, а также те, которые используются в ГДЕ .
Однако у добавления ненужных индексов есть и недостатки, поэтому добавляйте их только в те столбцы, которые действительно нуждаются в доступе больше, чем другие. Например, запросы UPDATE , DELETE и INSERT будут немного медленнее, чем больше у вас индексов, так как MySQL должен хранить дополнительную информацию для каждого индексированного столбца. Более подробную информацию можно найти на этой странице .
Изменить: Да, столбцы, которые необходимо использовать в ORDER BY , должны иметь индексы, а также те, которые используются в ГДЕ .
Однако у добавления ненужных индексов есть и недостатки, поэтому добавляйте их только в те столбцы, которые действительно нуждаются в доступе больше, чем другие. Например, запросы UPDATE , DELETE и INSERT будут немного медленнее, чем больше у вас индексов, так как MySQL должен хранить дополнительную информацию для каждого индексированного столбца. Более подробную информацию можно найти на этой странице .
Изменить: Да, столбцы, которые необходимо использовать в ORDER BY , должны иметь индексы, а также те, которые используются в ГДЕ .
UPDATE , DELETE и INSERT будут немного медленнее, чем больше у вас индексов, поскольку MySQL должен хранить дополнительную информацию для каждого индексированного столбца. Более подробную информацию можно найти на этой странице .
Изменить: Да, столбцы, которые необходимо использовать в ORDER BY , должны иметь индексы, а также те, которые используются в ГДЕ .
UPDATE , DELETE и INSERT будут немного медленнее, чем больше у вас индексов, поскольку MySQL должен хранить дополнительную информацию для каждого индексированного столбца. Более подробную информацию можно найти на этой странице .
Изменить: Да, столбцы, которые необходимо использовать в ORDER BY , должны иметь индексы, а также те, которые используются в ГДЕ .
Первичный ключ - это в основном уникальный индексированный столбец, который действует как «официальный» идентификатор строк в этой таблице. Что наиболее важно, он обычно используется для отношений внешнего ключа, т.е. если другая таблица ссылается на строку в первой, она будет содержать копию первичного ключа этой строки.
Обратите внимание, что возможно иметь составной первичный ключ, т. Е. тот, который состоит из более чем одного столбца.
Индексы сокращают время поиска. Обычно они основаны на дереве, так что поиск определенной строки по индексу занимает время O (log (n)), а не сканирование всей таблицы.
Как правило, любой столбец в большой таблице, который часто используется в WHERE , ORDER BY или (особенно) JOIN пункты должны иметь индекс. Так как индекс необходимо обновить для evey INSERT , UPDATE или DELETE , это замедляет эти операции. Если у вас мало записей и много операций чтения, то индексируйте содержание вашего слушания. Если у вас есть и много операций записи, и множество запросов, требующих индексов по многим столбцам, то у вас большая проблема.
Различие между первичным ключом и уникальным ключом лучше всего пояснить на примере.
У нас есть таблица пользователей:
USER_ID number
NAME varchar(30)
EMAIL varchar(50)
В этой таблице USER_ID является первичным ключом. НАЗВАНИЕ не уникально - в мире много Джонов Смитов и Мухаммедов. EMAIL обязательно уникален, иначе всемирная система электронной почты не будет работать. Итак, мы наложили уникальное ограничение на EMAIL.
Зачем тогда нам нужен отдельный первичный ключ? Три причины:
- числовая клавиша более эффективна. при использовании во внешнем ключе отношения, поскольку занимает меньше места
- , электронное письмо может измениться (например, подкачки провайдера), но пользователь все такой же; колебание смены значение первичного ключа во всей схеме всегда кошмар
- это всегда плохая идея использовать конфиденциальная или личная информация как внешний ключ
В реляционной модели любой столбец или набор столбцов, которые гарантированно присутствуют и являются уникальными в таблице, можно назвать ключом-кандидатом для таблицы. «Настоящее» означает «НЕ NULL». При проектировании базы данных обычной практикой является обозначение одного из ключей-кандидатов в качестве первичного ключа и использование ссылок на первичный ключ для ссылки на всю строку или на элемент предмета, который описывает строка.
В SQL, ограничение PRIMARY KEY составляет ограничение NOT NULL для каждого столбца первичного ключа и ограничение UNIQUE для всех столбцов первичного ключа, вместе взятых. На практике многие первичные ключи оказываются отдельными столбцами.
Для большинства продуктов СУБД ограничение PRIMARY KEY также приведет к автоматическому построению индекса по столбцам первичного ключа. Это ускоряет работу системной проверки при создании новых записей для первичного ключа, чтобы убедиться, что новое значение не дублирует существующее. Это также ускоряет поиск на основе значения первичного ключа и соединений между первичным ключом и внешним ключом, который на него ссылается. То, насколько происходит ускорение, зависит от того, как работает оптимизатор запросов.
Первоначально разработчики реляционных баз данных искали естественные ключи в данных, как это было. В последние годы появилась тенденция всегда создавать столбец с именем ID, целое число в качестве первого столбца и первичного ключа каждой таблицы. Функция автоматического создания СУБД используется для обеспечения уникальности этого ключа. Эта тенденция зафиксирована в «Стандартах дизайна Осло». Это не обязательно реляционный дизайн, но он служит некоторым непосредственным потребностям людей, которые следуют ему. Я не рекомендую эту практику, но я признаю, что это распространенная практика.
Индекс - это структура данных, которая обеспечивает быстрый доступ к нескольким строкам в таблице на основе описания столбцов таблицы, которые проиндексированы. Индекс состоит из копий определенных столбцов таблицы, называемых ключами индекса, перемежающихся указателями на строки таблицы. Указатели обычно скрыты от пользователей СУБД. Индексы работают в тандеме с оптимизатором запросов. Пользователь указывает в SQL, какие данные ищутся, а оптимизатор предлагает стратегии индексации и другие стратегии для преобразования того, что ищется, в состояние поиска. Существует некий принцип организации, такой как сортировка или хеширование, который позволяет использовать индекс для быстрого поиска и некоторых других целей. Все это внутри СУБД, после того, как построитель базы данных создал индекс или объявил первичный ключ.
Можно создавать индексы, не имеющие ничего общего с первичным ключом. Первичный ключ может существовать без индекса, хотя, как правило, это очень плохая идея.