Уникальная проблема ограничения SQL Server

Как визуально создать уникальное ограничение для поля varchar(max) в Visual Studio.

проблема в том, что когда я пытаюсь это сделать:

управлять индексами и ключами > добавить > столбцы

Я могу выбрать только столбцы bigint, но не любой из столбцов varchar(max).

Возможно, мне придется использовать проверочные ограничения?

Если да, то что вставить в выражение?

Спасибо за информацию


person b0x0rz    schedule 07.05.2010    source источник


Ответы (3)


Вы не можете наложить уникальное ограничение на столбец VARCHAR(MAX) (который может содержать до 2 ГБ текста!!). Вы просто не можете.

Ограничение уникальности обеспечивается уникальным индексом в фоновом режиме, а SQL Server имеет ограничение в 900 байтов для записей индекса. По этой причине вы также не можете наложить уникальное ограничение на поле VARCHAR(2000).

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

person marc_s    schedule 07.05.2010
comment
это должно быть поле электронной почты. что я могу сделать? укоротить? - person b0x0rz; 08.05.2010
comment
Да, укоротить. 320 символов — максимальная длина в соответствии с email.about.com/od/emailbehindthescenes/ f/address_length.htm - person Martin Smith; 08.05.2010
comment
Черт возьми, поле EMAIL? Да, укоротить. Когда кто-то покажет мне адрес электронной почты длиной 2 ГБ, я съем свои слова - person Neil N; 08.05.2010
comment
@b0x0rz: адрес электронной почты НИКОГДА не должен иметь длину 2 ГБ!! Используйте соответствующий размер - обычно я использую VARCHAR(200) и еще ни разу не видел адрес электронной почты, который не подходит для этого..... - person marc_s; 08.05.2010
comment
Я использую Varchar(100) уже около 10 лет и ни разу не видел письма, которое хотя бы приближалось к этому. - person Neil N; 08.05.2010
comment
да, не злитесь, люди :( все, что я сделал, это исследовал это и обнаружил: вы можете избежать путаницы позже, создав все текстовые сообщения типа varchar(n) [...] Даже если другие бизнес-требования ограничивают максимальная длина определенных полей до конкретных значений, схема БД, возможно, не лучшее место для обеспечения соблюдения этих правил.К тому времени, когда данные достигают БД, уже слишком поздно что-либо делать с этим (кроме отклонения). - person b0x0rz; 08.05.2010
comment
@b0x0rz: Да, но varchar(n) не означает varchar(max) для всех полей. Используйте здравый смысл и сделайте свои поля такой длины, какой они должны быть, но не больше. Иметь все VARCHAR(MAX) может показаться умным ходом — это не так, как раз наоборот. У него много производительности и других негативных последствий. Используйте здравый смысл и сделайте поля такими большими, какими они обычно должны быть. - person marc_s; 08.05.2010
comment
я всегда так делал, до СЕГОДНЯ, когда я прочитал это :( это действительно казалось правдоподобным, с технологическими достижениями и базами данных, которые становятся все умнее и умнее, я подумал - может быть, база данных МОЖЕТ внутренне настроиться с данными, которые там есть... во всяком случае, мой плохой , но советы по проектированию баз данных в Интернете как-то не согласуются - person b0x0rz; 08.05.2010
comment
еще один быстрый вопрос, это 900 байт на таблицу или на столбец/поле? спасибо - person b0x0rz; 08.05.2010
comment
@ b0x0rz: каждая запись индекса (длина всех столбцов, составляющих одну запись индекса) не может превышать 900 байт - для каждого индекса в любой таблице. Например. у вас может быть два поля VARCHAR(200), но не два поля VARCHAR(500). - person marc_s; 08.05.2010
comment
@ b0x0rz В предыдущем абзаце рекомендуется 32, 256 или 4k - и я думаю, что это нормально для полных неизвестных. Но, как правило, я собираюсь получить более точную информацию при сборе требований и буду применять длины в базе данных, как только я их узнаю. Применение длин (как и любых ограничений) поможет выявить непредвиденные проблемы раньше. Что еще хуже, узнать, что вы годами получали огромные и недействительные электронные письма, или узнать, что у кого-то слишком длинный адрес электронной почты, и вам нужно немного пересмотреть систему. - person Cade Roux; 08.05.2010
comment
@b0x0rz: никаких проблем - для этого и существует этот сайт - задавайте вопросы и получайте ответы! - person marc_s; 08.05.2010
comment
Только что вспомнил, что раньше у меня был 36-символьный адрес электронной почты, который досадно отклонялся в некоторых веб-формах. Я не могу себе представить, что многие люди будут намного выше 50 лет. - person Martin Smith; 08.05.2010
comment
да, это потрясающе, как быстро вы можете получить ответ здесь, я часами искал в сети, пытаясь понять, в чем проблема, а до этого искал совет по проектированию базы данных. спасибо еще раз - person b0x0rz; 08.05.2010
comment
Извините за зомби-комментарий, но.... адрес электронной почты может содержать максимум 254 символа, поэтому установка его как VARCHAR(254) была бы очень разумной. Невозможно иметь более длинный адрес электронной почты... определенно не 2 Гб! - person Algy Taylor; 11.05.2016

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

Вы можете использовать это ключевое слово T-SQL:

http://msdn.microsoft.com/en-us/library/ms174415.aspx

person Keith Adler    schedule 07.05.2010

Даже если бы это было возможно, это была бы плохая идея.

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

2) Если вы АБСОЛЮТНО ДОЛЖНЫ использовать varchar (Max). Может быть, хешировать его при вставке/обновлении и добавить хеш-столбец?

person Neil N    schedule 07.05.2010