Вопрос по ssms, sql, sql-server-2008 – SSMS разрешает дублирование записей в таблице, но не последующие обновления

6

Edit: When I say "SQL Server", I'm really talking about the Management Studio. Sorry if that was confusing.

О, я ненавижу, когда такие вещи случаются. Вчера я работал с SQL Server и пробовал команду PIVOT, чтобы выяснить, как она работает. Поэтому я создал новую таблицу с четырьмя столбцами, и первый столбец будет иметь то же значение для первых нескольких строк.

Я добавил & quot; значение1 & quot; к первой строке, первому столбцу и нажатию клавиши enter - поскольку ключи и ограничения еще не добавлены, это позволило мне перейти вниз к следующей строке с NULL для других столбцов в первой строке (что нормально). К моему удивлению, это также позволило мне ввести «значение1» во втором ряду и войдите вниз - это должно быть невозможно, так как теперь есть два одинаковых ряда. Однако, так как я просто возился, это меня не беспокоило. Итак, я продолжаю создавать четыре строки как таковые:

Table 1

Col1       Col2      Col3     Col4
---------------------------------
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL
Value1     NULL      NULL     NULL

Очевидно, что это странно и нарушает реляционную теорию, но мне было все равно, так как это просто таблица, которую я создал, чтобы возиться с ней. Тем не менее, я чуть не вырвал свои волосы из-за того, что произошло дальше. После того, как у меня были эти данные, я не мог сделатьanything к столу. Если бы я попытался заполнить col2, col3 или col4 в любой из строк, SQL Server крикнул бы на меня за наличие дублирующихся строк: & quot; Строка не была обновлена. Данные в строке 1 не были зафиксированы .... Обновленные или удаленные значения строк либо не делают строку уникальной, либо изменяют несколько строк (4 строки). & Quot;

Другими словами, SQL Server позволял мне вводить дублирующиеся строки, но когда я пытался обновить строки, чтобы сделать их уникальными, он не позволил мне, сославшись на наличие дублирующихся строк в качестве причины. Хуже всего то, что я даже не могу удалить строки (я получаю то же сообщение об ошибке). Единственное решение, которое я нашел однажды в этом сценарии, состояло в том, чтобы удалить таблицу и начать все сначала - что смешно.

Мой вопрос: как такое поведение может существовать в хорошо известной программе, которая развивалась более десяти лет? Я один безмозглый, и я должен принять поведение SQL Server? Для меня это неприемлемо, и SQL Server никогда не должен был позволять мне вводить повторяющиеся строки в первую очередь, или он должен был позволять мне обновлять дублирующиеся строки до тех пор, пока они не станут уникальными, а затем попытаться сохранить.

Это ни в коем случае не означает что-то вроде ненавистнических сообщений SQL Server. Относительно редко я сталкиваюсь с таким поведением, но когда я это делаю, это может действительно отстать от меня и привести меня в бешенство. Я просто не понимаю, почему в программе встроено такое поведение. Например, почему вначале он позволял мне вводить повторяющиеся строки, если он не планировал позволять мне это исправлять?

Я помню, как работал с MS Access в те времена, и я столкнулся с таким же странным, архаичным поведением. Несколько раз мне приходилось копировать огромные объемы данных, пересоздавать таблицу и копировать ее обратно только потому, что Access позволил мне сделать то, чего не должно было быть, и теперь блокирует меня от любых изменений, чтобы исправить это. - эффективно создавая тупик.

Так что здесь происходит? Нужно ли мне какое-то изменение парадигмы при приближении к SQL Server? Это я или SQL Server, что проблема? (Вы можете сказать, что это я, я могу принять это.)

Ваш Ответ

4   ответа
1

но недостаток, нет. Совершенно законно иметь таблицу без уникального ключа, но невозможно удалить из нее строку с помощью редактора таблиц в SSMS (или Enterprise Manager перед ним), если есть идентичные строки.

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

Я бы не использовал редактор таблиц для такого рода вещей, я бы писал сценарии INSERT.

Если вы добавите первичный ключ, вся проблема исчезнет.
Но DELETE FROM mytable без условия удалит записи, поэтому не похоже, что у вас нет способа их удалить. SSMS, кажется, принимает определенный уровень минимальной компетентности; Это не обязательно все полицейские для вас. Добро пожаловать в программирование.
Если SSMS позволяет вам вводить дублирующиеся строки, но не удалять их, мне это кажется подозрительным. Я не вижу причин, чтобы это допустить. На мой взгляд, это должно позволять и то, и другое. JoeCool
9

что когда-либо делает студия управления, - это предоставляет пользовательский интерфейс для создания некоторого SQL-кода и запускает его для БД.

В вашем случае каждый раз, когда вы добавляете строку, она создает оператор INSERT. Это совершенно верно.

Затем, когда вы попытались использовать пользовательский интерфейс для УДАЛЕНИЯ или ОБНОВЛЕНИЯ одной записи из всех этих дублирующих записей, он не смог создать SQL для этого. Причина в том, что в таблице не было ключа, нет способа создать предложение WHERE, которое представляло бы запись, которую вы пытались ОБНОВИТЬ или УДАЛИТЬ.

Это & quot; ошибка & quot; сообщения звучат совершенно ясно и действительны для меня.

Что касается ваших комментариев:

To my surprise, it also allowed me to enter "value1" on the second row and enter down - this should be impossible since now there are two identical rows. However, since I was just messing around, this didn't bother me.

Obviously this is strange and breaks relational theory, but I didn't really care since this is just a table I created to mess around with.

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

Ах, теперь я понимаю сообщение об ошибке намного лучше. Сначала я подумал, что ошибка заключалась в скрытой реализации дублирующихся строк, так как в этом случае SSMS как бы «просыпался». и увидев, что если бы я удалил строку, там было бы еще три дубликата, и он не мог бы разрешить дубликаты. Но нет, он не смог удалить строку, потому что не знал, какой из четырех удалить. JoeCool
Спасибо за фактическое объяснение причин, по которым разрешается вставка, но не разрешается обновление / удаление. Это было очень полезно. JoeCool
1

ельно незначительная) часть предложения продукта SQL Server. Я думаю, что вы можете спокойно принять причуды редактора, не заботясь об относительном качестве самого сервера.

За кулисами Management Studio выполняет операторы SQL для выполнения ваших действий, как если бы вы вводили этот SQL самостоятельно. Так что если вы нарушаете правило, вы платите штраф.

Да, я думаю, что это моя проблема. Я изображаю в своей голове систему SSMS, тесно связанную с реальным сервером, но она фактически отправляет и получает операторы SQL точно так же, как любое приложение, которое я пишу для своей базы данных. JoeCool
1

как вы ожидаете, что инструмент узнает, какую строку удалить, если у вас не было уникального ключа. Вы хотите удалить только один из дубликатов или оба? если только один, какой ключ он должен использовать.

Студия управления являетсяtool.  Его задача не состоит в том, чтобы обеспечить идеальный дизайн таблицы или базовую базу данных 101, которая в большинстве случаев включала бы в себя наличие некоторого уникального ключа. Что если у вас есть какая-то сумасшедшая бизнес-модель, требующая дублирования строк? Не будет ли тогда жалоба на то, что инструмент предотвращает дублирование ролей?

Суть в том, что 1. В любом случае вы не должны редактировать или удалять данные с помощью инструмента. Вы должны писать сценарии для большинства вещей.
2. У вас должен быть уникальный ключ

Не могу обвинить любой инструмент в том, что эти вещи не установлены.

@ Роберт Харви, я знаю, что это очень старый комментарий, но причины, по которым вы должны использовать скрипты: во-первых, графический интерфейс часто делает вещи неэффективным образом, вызывая блокировки таблиц, которых не было бы при использовании скрипта. Затем все изменения в базах данных должны быть записаны в сценарии и помещены в систему контроля версий, чтобы у вас были сценарии, доступные для запуска в других средах, когда пришло время перейти от dev к QA к prod. В-третьих, есть вещи, которые GUI скажет вам, что вы не можете сделать это, если вы напишете сценарий SQL.
Я слышал это заявление раньше. Вы должны всегда использовать сценарии для всего и никогда не использовать редактор. Почему это? Мазохизм?

Похожие вопросы