My<cod/>.net
Таблицы без первичного ключа
У меня есть несколько таблиц, единственными уникальными данными которых является столбец uniqueidentifier (Guid). Поскольку GUID не являются последовательными (и они генерируются на стороне клиента, поэтому я не могу использовать newsequentialid()), я сделал непервичный, некластеризованный индекс для этого поля ID, а не дал таблицам кластеризованный первичный ключ.
Мне интересно, каковы последствия этого подхода для производительности. Я видел, как некоторые люди предполагают, что таблицы должны иметь автоинкрементный ("identity") int в качестве кластеризованного первичного ключа, даже если он не имеет никакого значения, поскольку это означает, что сам компонент database engine может использовать это значение для быстрого поиска строки вместо того, чтобы использовать закладку.
Моя база данных реплицируется слиянием через кучу серверов, поэтому я избегаю столбцов identity int, поскольку они немного волосаты, чтобы получить право на репликацию.
О чем вы думаете? Таблицы должны иметь первичные ключи? Или это нормально-не иметь никаких кластеризованных индексов, если нет никаких разумных столбцов для индексирования таким образом?
При работе с индексами необходимо определить, для чего будет использоваться ваша таблица. Если вы в первую очередь вставляете 1000 строк в секунду и не делаете никаких запросов, то кластеризованный индекс является ударом по производительности. Если вы делаете 1000 запросов в секунду, то отсутствие индекса приведет к очень плохой производительности. При попытке настроить запросы/индексы лучше всего использовать анализатор плана запросов и профилировщик SQL на сервере SQL. Это покажет вам, где вы сталкиваетесь с дорогостоящим сканированием таблиц или другими блокировщиками производительности.
Что касается аргумента GUID против ID, вы можете найти в интернете людей, которые клянутся обоими. Меня всегда учили использовать GUIDs, если только у меня не было действительно веской причины этого не делать. У Джеффа есть хороший пост, который рассказывает о причинах использования GUIDs: https://blog.codinghorror.com/primary-keys-ids-versus-guids/ .
Как и в большинстве случаев, связанных с развитием, если вы хотите улучшить производительность, нет ни одного правильного ответа. Это действительно зависит от того, что вы пытаетесь сделать и как вы реализуете решение. Единственный верный ответ - это проверять, тестировать и снова тестировать показатели производительности, чтобы убедиться, что вы достигаете своих целей.
[Редактировать] @Matt, проведя еще несколько исследований по дебатам GUID/ID, я наткнулся на этот пост. Как я уже упоминал ранее, не существует истинного правильного или неправильного ответа. Это зависит от ваших конкретных потребностей в реализации. Но вот несколько довольно веских причин использовать GUIDs в качестве первичного ключа:
Например, существует проблема, известная как "hotspot", когда некоторые страницы данных в таблице находятся под относительно высокой конкуренцией за валюту. В основном, происходит то, что большая часть трафика на таблице (и, следовательно, блокировки на уровне страницы) происходит на небольшой площади таблицы, ближе к концу. Новые записи всегда будут идти в эту точку доступа, потому что IDENTITY-это генератор последовательных чисел. Эти вставки являются хлопотными, потому что они требуют исключительной блокировки страницы на странице, на которую они добавлены (точка доступа). Это эффективно сериализует все вставки в таблицу благодаря механизму блокировки страниц. NewID() с другой стороны не страдает от горячих точек. Значения, генерируемые с помощью функции NewID(), являются последовательными только для коротких пакетов вставок (где функция вызывается очень быстро, например, при многорядной вставке), что приводит к случайному распределению вставленных строк по страницам данных таблицы вместо всех в конце - таким образом, исключается точка доступа от вставок.
Кроме того, поскольку вставки распределены случайным образом, вероятность разбиения страниц значительно снижается. Хотя разбиение страницы здесь и там не так уж плохо, эффекты складываются быстро. С IDENTITY коэффициент заполнения страницы довольно бесполезен в качестве механизма настройки и может быть также установлен на 100% - строки никогда не будут вставлены ни в одну страницу, кроме последней. С помощью NewID() вы можете фактически использовать фактор заполнения в качестве инструмента для повышения производительности. Вы можете установить коэффициент заполнения на уровень, который приближается к расчетному росту объема между перестроениями индекса, а затем запланировать перестроения в нерабочее время с помощью DBCC reindex. Это эффективно задерживает хиты производительности разбиения страниц до тех пор, пока не наступит пиковое время.
Если вы даже думаете , что вам может понадобиться включить репликацию для рассматриваемой таблицы - тогда вы можете также сделать PK uniqueidentifier и пометить поле guid как ROWGUIDCOL. Для репликации потребуется однозначно значимое поле guid с этим атрибутом, и она добавит его, если такового не существует. Если подходящее поле существует, то оно будет просто использовать то, что там есть.
Еще одним огромным преимуществом использования GUIDs для PKs является тот факт, что значение действительно гарантированно уникально - не только среди всех значений, генерируемых этим сервером, но и среди всех значений, генерируемых всеми компьютерами, будь то сервер БД, веб - сервер, сервер приложений или клиентская машина. Почти каждый современный язык имеет возможность генерировать действительный guid теперь - в .NET вы можете использовать System.Guid.NewGuid. Это VERY удобно при работе с кэшированными наборами данных master-detail, в частности. Вам не нужно использовать сумасшедшие временные схемы манипулирования ключами только для того, чтобы связать ваши записи вместе, прежде чем они будут совершены. Вы просто получаете совершенно действительный новый Guid из операционной системы для каждого нового значения постоянного ключа записи в момент ее создания.
Первичный ключ служит трем целям:
- указывает, что столбец(ы) должен быть уникальным
- указывает, что столбец(ы) должен быть не null
- документируйте намерение, что это уникальный идентификатор строки
Первые два могут быть определены множеством способов, как вы уже сделали.
Третья причина хороша:
- для людей, чтобы они могли легко увидеть ваши намерения
- для компьютера, так что программа, которая может сравнить или иным образом обработать вашу таблицу, может запросить базу данных для первичного ключа таблицы.
Первичный ключ не обязательно должен быть автоматически увеличивающимся числовым полем, поэтому я бы сказал, что неплохо указать свой столбец guid в качестве первичного ключа.
Просто прыгаю туда, потому что Мэтт меня немного подловил.
Вы должны понимать, что хотя кластеризованный индекс помещается на первичный ключ таблицы по умолчанию, эти два понятия являются отдельными и должны рассматриваться отдельно. CIX указывает способ хранения данных, на который ссылается NCIXs, в то время как PK обеспечивает уникальность для каждой строки, чтобы удовлетворить требованиям LOGICAL таблицы.
Таблица без CIX - это просто куча. Таблица без PK часто считается "not a table". Лучше всего получить представление о концепциях PK и CIX отдельно, чтобы вы могли принимать разумные решения при проектировании базы данных.
Грабить
Никто не ответил на актуальный вопрос: каковы плюсы / минусы таблицы без PK и индекса CLUSTERED? На мой взгляд, если вы оптимизируетесь для более быстрых вставок (особенно инкрементальной массовой вставки, например, когда вы массово загружаете данные в непустую таблицу), такая таблица: с NO кластеризованным индексом, NO ограничениями, без внешних ключей, без значений по умолчанию и без первичного ключа, в базе данных с простой моделью восстановления, является лучшей. Теперь, если вы когда-нибудь захотите запросить эту таблицу (а не сканировать ее целиком), вы можете добавить некластеризованные неуникальные индексы по мере необходимости, но свести их к минимуму.
Поскольку вы делаете репликацию, ваши правильные идентичности-это то, от чего нужно избавиться. Я бы сделал ваш GUID первичным ключом, но некластеризованным, поскольку вы не можете использовать newsequentialid. Это stikes мне, как ваш лучший курс. Если вы не сделаете его PK, но поставите на него уникальный индекс, рано или поздно это может привести к тому, что люди, обслуживающие систему, не поймут отношения FK должным образом, вводя ошибки.