oh je déteste quand des choses comme ça se produisent. J'avais travaillé avec SQL Server hier et j'essaie la commande pivot d'essayer de déterminer comment cela a fonctionné. J'ai donc créé une nouvelle table avec quatre colonnes et la première colonne allait avoir la même valeur pour les premières lignes. J'ai ajouté la "valeur1" à la première ligne, première colonne et appuyez sur Entrée - Sine Aucune clé ou contrainte n'a été ajoutée, cela m'a permis d'entrer à la ligne suivante avec des nulls pour les autres colonnes pour les autres colonnes. sur la première rangée (qui va bien). À ma grande surprise, cela m'a également permis d'entrer "valeur1" sur la deuxième rangée et d'entrer en panne - cela devrait être impossible depuis maintenant il y a deux rangées identiques. Cependant, depuis que je me suis juste en train de jouer, cela ne m'a pas dérangé. Donc, je procède à créer quatre lignes comme telles: évidemment c'est étrange et casse la théorie relationnelle, Mais je ne m'en souciais pas vraiment depuis que c'est juste une table que j'ai créée pour gâcher. Cependant, je viens de sortir mes cheveux sur ce qui s'est passé ensuite. Après avoir eu ces données dans, je ne pouvais pas faire rien à la table. Si j'essayais de remplir Col2, Col3 ou Col4 sur l'une des lignes, SQL Server vous crierait-moi pour avoir des lignes en double: "Aucune ligne n'a été mise à jour. Les données de la ligne 1 n'ont pas été commises .... la valeur de la ligne (s) mises à jour ou supprimées, ne faites pas la ligne unique ou ne modifient pas plusieurs lignes (4 lignes). " Ainsi, en d'autres termes, SQL Server m'a permis d'entrer dans des lignes en double, mais quand j'ai essayé Pour mettre à jour les lignes pour les rendre unique, cela ne me permettrait pas, citant qu'il existe des lignes en double comme sa raison. La pire partie est que je ne pouvais même pas supprimer les lignes non plus (je reçois le même message d'erreur). La seule solution que j'ai trouvée une fois dans ce scénario était de supprimer la table et de recommencer - ce qui est ridicule. Ma question est, comment ce type de comportement peut exister dans un programme bien connu qui a évolué sur une décennie? Suis-je l'un des cerveaux et je devrais accepter le comportement de SQL Server? Pour moi, cela est inacceptable et SQL Server ne vous a pas permis de ne jamais me permettre d'entrer des lignes en double en premier lieu, sinon cela aurait dû me permettre de mettre à jour les lignes en double jusqu'à ce qu'ils soient tous uniques et d'essayer d'économiser. Ceci n'est en aucun cas conçu pour être une sorte de SQL Server Hating Post. C'est relativement rare que je rencontre un comportement comme celui-ci, mais quand je le fais, cela peut vraiment me mettre derrière et me conduire fou. Je ne comprends tout simplement pas pourquoi le programme a un comportement construit comme celui-ci. Comme pourquoi dans le monde, il m'a laissé entrer les lignes en double en premier lieu s'il n'a pas prévu de me laisser réparer? Je me souviens de travailler avec Mme Access Retour dans la journée et je voudrais courir dans le même genre d'étrange comportement archaïque. À quelques reprises, je devais copier d'énormes quantités de données, recréer la table et le copier simplement parce que l'accès m'avait permis de faire quelque chose qu'il ne devrait pas avoir et qui me bloque maintenant de tout changement pour le réparer. - produire efficacement une impasse. Alors qu'est-ce qui se passe ici? Ai-je besoin d'une sorte de changement de paradigme lors de l'approche de SQL Server? Est-ce que c'est moi ou SQL Server qui est le problème? (Vous pouvez dire que c'est moi, je peux le prendre.)
4 Réponses :
L'éditeur d'enregistrement dans SQL Server Management Studio est une petite partie (et relativement sans importance) de l'offre de produits SQL Server. Je pense que vous pouvez accepter en toute sécurité les bizarreries de l'éditeur sans être préoccupée par la qualité relative du serveur lui-même.
Dans les coulisses, le studio de gestion exécute des instructions SQL pour effectuer vos actions, comme si vous avez tapé ce SQL vous-même. Donc, si vous cassez une règle, vous payez l'amende.
Oui, je pense que c'est mon problème. Je photographie dans ma tête SSMS étant étroitement associé au serveur actuel, mais elle envoie et recevant des déclarations SQL comme n'importe quelle application que j'écris pour ma base de données.
Un quirk oui, mais une faille, non. Il est parfaitement légitime d'avoir une table sans clé unique, mais il n'est pas possible de supprimer une ligne à partir de celui-ci avec l'éditeur de table dans SSMS (ou gestionnaire d'entreprise avant de cela) s'il y a des lignes identiques.
Ce n'est pas des SSMS qui vous permettent de créer les lignes en double, c'est vous qui l'a permis lorsque vous avez créé votre table sans clé primaire. Vous pouvez toujours créer une colonne d'identité d'incrémentation automatique qui résoudrait le problème.
Je n'utiliserais pas l'éditeur de table pour ce type de choses, je voudrais insérer des instructions.
Si SSMS vous permet d'entrer des lignes en double, mais ne les supprimez pas, cela me semble pishy. Je ne vois aucune raison de permettre cela. À mon avis, cela devrait permettre à la fois ou non.
Mais une suppression de MyTable sans affection supprimera les enregistrements. Ce n'est donc pas comme si vous n'avez pas le moyen de les supprimer. Les SSMS semblent assumer un certain niveau de compétence minimale; Ce ne sera pas nécessairement tout de la police pour vous. Bienvenue dans la programmation.
Si vous ajoutez une clé primaire, tout le problème disparaîtra.
Tous les studios de gestion ont jamais fournit une interface utilisateur de créer des SQL pour vous et le gère contre la DB.
Dans votre cas, chaque fois que vous avez ajouté une ligne, il a produit une déclaration d'insertion. Ceci est parfaitement valide.
Lorsque vous avez essayé ensuite d'utiliser l'interface utilisateur pour supprimer ou mettre à jour une seule fiche de tous ces enregistrements en double, il n'a pas pu produire le SQL pour le faire. La raison étant, car il n'y avait pas de clé sur la table, il n'ya aucun moyen de produire une clause où cela représenterait le dossier que vous essayiez de mettre à jour ou de supprimer.
C'est "Erreur" les messages sonnent parfaitement clair et valide pour moi.
Quant à vos commentaires:
à ma surprise, cela m'a aussi permis de Entrez "valeur1" sur la deuxième ligne et Entrez vers le bas - cela devrait être impossible Depuis maintenant il y a deux identiques Lignes. Cependant, depuis que j'étais juste Messing autour, cela ne m'a pas dérangé.
évidemment c'est étrange et casse théorie relationnelle, mais je n'ai pas vraiment soin depuis que c'est juste une table i créé pour désordre avec.
Il n'y a rien de mal à avoir une table de base de données qui permet des duplicats, c'est une chose parfaitement valide à faire si c'est ce dont vous avez besoin. Comme pour ne pas "soin" ou "dérangé" que vous aviez autorisé des doublons. C'est là que l'erreur réside. C'est alors que vous auriez dû réaliser que vous avez oublié d'ajouter une clé primaire.
Merci d'avoir expliqué en réalité les raisons qui permettent d'autoriser les insertions mais n'autorisant pas les mises à jour / suppression. C'était très utile.
Ah, je comprends le message d'erreur beaucoup mieux maintenant. Au début, je pensais que l'erreur était une réalisation latente des lignes en double, comme dans ce système SSMS, la SSMS était une sorte de "réveil" et de voir que si j'ai supprimé une rangée, il y aurait trois dupliqués encore là-bas, et il ne pouvait pas permettre des doublons. Mais non, il était incapable de supprimer la ligne car il ne savait pas lequel des quatre à supprimer.
Je ne sais pas comment vous pouvez vous attendre à ce que l'outil sache quelle ligne supprimer si vous n'avez pas eu une clé unique. Voulez-vous qu'il supprimait l'un des doublons ou les deux? Si juste un, quelle est la clé, elle devrait utiliser.
Le studio de gestion est un outil . Le travail est de ne pas appliquer la conception de table parfaite ou la base de données de base 101, qui inclurait une clé unique de la majorité du temps. Et si vous avez eu un modèle d'entreprise folle qui nécessitait des lignes en double? La plainte ne serait alors pas que l'outil empêchait des rôles en double?
La ligne de fond est que
1. Vous ne devriez pas éditer ou supprimer des données avec l'outil de toute façon. Vous devriez être script des déclarations pour la plupart des choses. ne peut blâmer aucun outil pour ne pas avoir ces choses en place.
2. Vous devriez avoir une clé unique
J'ai déjà entendu cette déclaration. Vous devez toujours utiliser des scripts pour tout et n'utilisez jamais d'éditeur. Pourquoi est-ce? Masochisme?
@ROBERT HARVEY, je sais que c'est un très vieux commentaire, mais les raisons pour lesquelles vous devriez utiliser des scripts sont les suivantes: premièrement, l'interface graphique fait souvent des choses de manière la plus inefficente, causant des serrures de table qui n'auraient pas eu lieu si l'utilisation d'un script. Ensuite, toutes les modifications apportées aux bases de données doivent être scriptées et placées dans le contrôle de la source afin que les scripts soient disponibles pour exécuter dans d'autres environnements lorsqu'il est temps de passer de Dev à QA à prod. Troisièmement, il y a des choses que l'interface graphique vous dira que vous ne pouvez pas faire cela est possible si vous écrivez le script SQL.