Не хранить в базе данных одинаковые данные в SQL Server

@ayrat_net · Регистрация: 12.01.2011

Студворк — интернет-сервис помощи студентам

В общем вопрос делится на 2 части

1) Как сделать так чтобы не было одинаковых данных в столбце имена с разными ID на стороне SQL Server можно ли это сделать? Если да то прошу подсказок (это для того чтобы к примеру если я захочу войти в в саму БД и сам добавить данный и чтобы в случаи вода идентичных данных мне выдавалась ошибка и не разрешался ввод, сами понимаете всякое бывает иногда по неволе свои кривые ручки направляеш туда куда направлять не стоит)
2) Как это сделать посредством C# то есть сохранять как осуществлять проверку перед сохранением в БД а еще точнее, какой наиболее быстрый метод использовать для этого?

@turbanoff · 02.03.2012, 08:08

Сообщение от ayrat_net

Как сделать так чтобы не было одинаковых данных в столбце имена с разными ID

Сделать ID первичным ключом, тогда SQL server не допустит чтобы там были 2 записи с одинаковым ID

Сообщение от ayrat_net

Как это сделать посредством C# то есть сохранять как осуществлять проверку перед сохранением в БД а еще точнее, какой наиболее быстрый метод использовать для этого?

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

Если вы не знаете что будет чаще - выбирайте любой способ.

PS. Я точно не уверен, sql server создаст сам индекс на первичный ключ?

@ayrat_net · 02.03.2012, 08:14 **[ТС]**

Сообщение от turbanoff

в столбце имена с разными ID

Читайте внимательней

поясню:
id name
1 tubanov
2 turbanov
3 turbanov

Мне нужно чтобы был один turbanov и чтобы при вводе еще одного turbanov мне выдавало ERROR

Притензий к ID у меня нет

@turbanoff · 02.03.2012, 08:26

В таком случае просто навесьте ограничение уникальности на это поле

@ayrat_net · 02.03.2012, 10:52 **[ТС]**

Вроде то что надо спасибо

Добавлено через 1 час 52 минуты
Осталось только спросить где он устанавливается никак не найду

Добавлено через 30 минут
нашел но теперь выдает ошибку, что индекс не может превышать 9000 байт, поясню что я хочу сделать уникальным текст

@JeyKip · 02.03.2012, 13:40

вместо text можно использовать varchar (N) с указанием максимального количества символов (если, конечно, тебе не требуется там хранить очень длинный текст). Если фамилии или прочие данные, то text использовать нет необходимости. Тогда у тебя проблем с байтами в ограничении не будет.

@ayrat_net · 02.03.2012, 13:43 **[ТС]**

JeyKip, Вы не поняли вопроса. в коментах дано объяснение Сказанное вами совершенно не то что я ожидал услышать.

Хотя я разобрался как turbanoff нужно использовать уникальные идентификаторы

@nio · 03.03.2012, 01:05

Сообщение от ayrat_net

нашел но теперь выдает ошибку, что индекс не может превышать 9000 байт, поясню что я хочу сделать уникальным текст

ayrat_net, есть такая наука - математика. Рекомендую почитать учебники, особенно разделы где про умножение написано.

Небольшой пример.

Одно из назначений идентификатора - уменьшить объём данных. Представь, что ты создашь ключ на 9тыс байт, а потом делаешь на эту запись 10 тыс внешних ключей, в результате БД вырастает на 9 000*10 000 = 90 000 000.
90 МБ(!) на одних ключах. Пользователи будут тебе "очень благодарны" при выборке по такому ключу

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

Тоже самое при использовании int значений займет 4*10 000 = 40 000 (40 кБ). Думаю разница очевидна. Причем диапазон int значительно шире без всяких ухищрений.

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

Добавлено через 5 минут
9000 символов - это ~100 строк 12-м шрифтом в Word, т.е. 2 стр. текста. Ты что собираешься цитаты из "Война и мир" в качестве ключей использовать?

@ayrat_net · 03.03.2012, 01:14 **[ТС]**

nio, Здравствуйте, я конечно ценю Ваше мнение, но если бы Вы прочли все обсуждение на форуме Вы бы поняли, что меня интересует не КЛЮЧ как таковой, другой столбец типа nvarchar где я ввожу название чего либо ну например категории товара, я обеспокоен тем чтобы названия категорий товаров не повторялись и возникло желание организовать одно из ограничений на уровне БД.

Мне был предложен вариант использовать ограничение уникальности, чем я и воспользовался, но пока на уровне моих знаний. Когда я решал это проблему в моем типе данных было ограничение nchar(500) - поясняю я не использую категорию товаров это был только пример. После этого мне выдало ошибку о которой Вы так яростно глумитесь указывая на то что я так глуп (возможно не отрицаю, но я при этом не думаю что и Вы являетесь гением), потом я ограничил nchar(450) ошибка пропала и все работает прекрасно

Еще раз поясню как оказывается 9000 байтов это примерно не более 450 символов в типе nvarchar если не верите проверьте пожалуйста в моем случаи это 6 строк в 12pt шрифт Calibri
Повторюсь я его не собираюсь использовать как ключ

@nio · 03.03.2012, 01:34

ayrat_net, всему должно быть обоснование. Использованию уникального поля на 500 символов тем более. Ты уверен, что у тебя будут некие данные такой размерности? Я сомневаюсь и считаю, что допущена какая-то ошибка в анализе задачи. ДАже на примере товара, вряд ли найдется товар с таким длинным названием, и при этом он он все-равно будет иметь некое кодированное значение однозначно его идентифицирующее.

Добавлено через 4 минуты

Сообщение от ayrat_net

Еще раз поясню как оказывается 9000 байтов это примерно не более 450 символов в типе nvarchar если не верите проверьте пожалуйста в моем случаи это 6 строк в 12pt шрифт Calibri

да нет. Это Word, и у него разметка еще ресурсы жрет, текст занимает 1 или 2 байта на символ (в зависимости от кодировки), таким образом получается , что 9000 байт - это как минимум 4500 символов

@ayrat_net · 03.03.2012, 01:36 **[ТС]**

nio, Благодарю тебя, я обязательно проанализирую свою задачу

Сообщение от nio

вряд ли найдется товар с таким длинным названием

В прежнем посте я написал, что это только пример, а не то что я применяю на самом деле

Сообщение от nio

все-равно будет иметь некое кодированное значение однозначно его идентифицирующее.

Поясните пожалуйста эти слова я немного не понял

А касаемо что там будет, может как Вы и сказали я делаю цитатник по войне и миру ис пользуя самые красивые предложения написанные в нем

@nio · 03.03.2012, 01:45

Сообщение от ayrat_net

Поясните пожалуйста эти слова я немного не понял

если брать за пример некую промышленную продукцию, то все выпускаемое имеет свой код. Раньше, если не ошибаюсь, это был артикул, а сейчас успешно используются штрихкоды. Штрихкод - позволяет вести централизованный учет товаров в глобальном масштабе, таким образом можно идентифицировать, что за товар, кем и где выпущен. При этом штрихкод всего-лишь графическое представление числового значения.

@ayrat_net · 03.03.2012, 01:50 **[ТС]**

Сообщение от nio

что 9000 байт - это как минимум 4500 символов

Для своего интереса проверь пожалуйста это на реальном примере в SQLSERVER, я думаю тебе это будет интересно суть в том что как раз таки не более примерно 450 символов указывает в типе nvarchar. Я бы и рад оказаться неправым.

Добавлено через 3 минуты

Сообщение от nio

При этом штрихкод всего-лишь графическое представление числового значения.

Я понял Вас и согласен с Вами, но поясню что для такого рода данных я использую ID (то есть с ключиком)

А названия например товаров я я не определяю как КЛЮЧ, просто я хочу чтобы они не повторялись, понимаю, что такую проверку можно осуществить используя язык обращения, но я хочу обезопасить себя от кривых рук и сделать так, чтобы на уровне БД нельзя было написать повторяемые данные

@nio · 03.03.2012, 10:09

Сообщение от ayrat_net

Для своего интереса проверь пожалуйста это на реальном примере в SQLSERVER, я думаю тебе это будет интересно суть в том что как раз таки не более примерно 450 символов указывает в типе nvarchar.

проверил, создал столбец varchar(500), уникальный индекс установился без проблем, попробовал varchar(600), тоже без проблем.
При попытке создать индекс на столбец varchar(1000) получил предупреждение (см. рис.). Там написано, что вставка и обновление не сработают, если сумарное(!) количество байт индексов превысит 900 (!), а не 9000.
Таким образом получаем, что достигнуть требуемого не получится даже при использовании нескольких столбцов. Более того, учитывая, что данная концепция не меняется, следует сделать вывод в оправданности такого решения со стороны MS и отсутствии острой необходимости в расширении со стороны разработчиков. Всвязи с этим рекомендую пересмотреть подход к организации обработки данных.

Из личного опыта: видел уже несколько десятков достаточно крупных БД и сам не мало разработал, ни разу не сталкивался с необходимостью создания полей описанных ТС. Как правило поля такого размера являются описаниями и примечаниями и не претендуют на уникальность

@ayrat_net · 03.03.2012, 18:20 **[ТС]**

Сообщение от nio

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

Тогда посоветуйте пожалуйста самое оптимальное число

И я Вам попробую показать свою ошибку.

@nio · 03.03.2012, 23:45

Сообщение от ayrat_net

посоветуйте пожалуйста самое оптимальное число

Оптимальное число чего? Символов в строке? Все зависит от поставленной задачи. Для названия товара вполне достаточно 100 символов, в крайнем случае потом (при необходимости) можно увеличить до 150. Больше я не встречал. А для примечаний и описаний большого размера используется поле типа "text".

Новые блоги и статьи Все статьи Все блоги /
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .
SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .

@ayrat_net 84 / 84 / 12 Регистрация: 12.01.2011 Сообщений: 1,049

	Не хранить в базе данных одинаковые данные в SQL Server 02.03.2012, 03:14. Показов 3138. Ответов 15 Метки нет (Все метки) В общем вопрос делится на 2 части 1) Как сделать так чтобы не было одинаковых данных в столбце имена с разными ID на стороне SQL Server можно ли это сделать? Если да то прошу подсказок (это для того чтобы к примеру если я захочу войти в в саму БД и сам добавить данный и чтобы в случаи вода идентичных данных мне выдавалась ошибка и не разрешался ввод, сами понимаете всякое бывает иногда по неволе свои кривые ручки направляеш туда куда направлять не стоит) 2) Как это сделать посредством C# то есть сохранять как осуществлять проверку перед сохранением в БД а еще точнее, какой наиболее быстрый метод использовать для этого? 0

@turbanoff 4094 / 3828 / 745 Регистрация: 18.05.2010 Сообщений: 9,331 Записей в блоге: 12
	02.03.2012, 08:26
	В таком случае просто навесьте ограничение уникальности на это поле 1

@ayrat_net 84 / 84 / 12 Регистрация: 12.01.2011 Сообщений: 1,049
	02.03.2012, 10:52 [ТС]
	Вроде то что надо спасибо Добавлено через 1 час 52 минуты Осталось только спросить где он устанавливается никак не найду Добавлено через 30 минут нашел но теперь выдает ошибку, что индекс не может превышать 9000 байт, поясню что я хочу сделать уникальным текст 0

@JeyKip 58 / 50 / 16 Регистрация: 23.06.2011 Сообщений: 122
	02.03.2012, 13:40
	вместо text можно использовать varchar (N) с указанием максимального количества символов (если, конечно, тебе не требуется там хранить очень длинный текст). Если фамилии или прочие данные, то text использовать нет необходимости. Тогда у тебя проблем с байтами в ограничении не будет. 1

@ayrat_net 84 / 84 / 12 Регистрация: 12.01.2011 Сообщений: 1,049
	02.03.2012, 13:43 [ТС]
	JeyKip, Вы не поняли вопроса. в коментах дано объяснение Сказанное вами совершенно не то что я ожидал услышать. Хотя я разобрался как turbanoff нужно использовать уникальные идентификаторы 0

@ayrat_net 84 / 84 / 12 Регистрация: 12.01.2011 Сообщений: 1,049
	03.03.2012, 01:14 [ТС]
	nio, Здравствуйте, я конечно ценю Ваше мнение, но если бы Вы прочли все обсуждение на форуме Вы бы поняли, что меня интересует не КЛЮЧ как таковой, другой столбец типа nvarchar где я ввожу название чего либо ну например категории товара, я обеспокоен тем чтобы названия категорий товаров не повторялись и возникло желание организовать одно из ограничений на уровне БД. Мне был предложен вариант использовать ограничение уникальности, чем я и воспользовался, но пока на уровне моих знаний. Когда я решал это проблему в моем типе данных было ограничение nchar(500) - поясняю я не использую категорию товаров это был только пример. После этого мне выдало ошибку о которой Вы так яростно глумитесь указывая на то что я так глуп (возможно не отрицаю, но я при этом не думаю что и Вы являетесь гением), потом я ограничил nchar(450) ошибка пропала и все работает прекрасно Еще раз поясню как оказывается 9000 байтов это примерно не более 450 символов в типе nvarchar если не верите проверьте пожалуйста в моем случаи это 6 строк в 12pt шрифт Calibri Повторюсь я его не собираюсь использовать как ключ 0