Nous avons une base de données avec un tas de tables larges (40 à 80 colonnes chacune) et il suffit de trouver un bogue qui introduit des valeurs nulles dans environ 500 des enregistrements. Les valeurs NULL peuvent apparaître dans l'une des colonnes (toutes sont des colonnes entières, voir l'image ci-dessous), mais ces valeurs nulles causent des problèmes avec l'un de nos systèmes de reporting qui ne peuvent pas être modifiés facilement. Nous devons remplacer les valeurs NULL avec une valeur statique spécifique (dans ce cas 99), mais comme ce changement doit être effectué sur une base par colonne pour plus de 250 colonnes différentes, je préférerais ne pas écrire des scripts de TSQL individuels à la mise à jour de chaque colonne une par un.
Mon cerveau est trop frit pour penser à une solution intelligente, alors ma question est de savoir comment puis-je exécuter cette tâche sur toutes les colonnes d'une table (ou mieux encore plusieurs tables) à l'aide d'une requête SQL simple et lisible. Je peux isoler les enregistrements suffisamment facilement à l'aide d'une chaîne de Voici une requête d'échantillon indiquant quelques-unes des enregistrements de 4 tables différentes:
où (réponse_1 est null) ou (réponse_2 est null) ou ... ou même par des numéros administratifs pour chaque table, mais ce truc ne fonctionnera pas Lors de la mise à jour comme où la clause est par ligne non par colonne. Tout conseil?
4 Réponses :
Il n'y a pas de convention à cela - si vous souhaitez uniquement traiter des enregistrements dans lesquels des colonnes respectives sont NULL, vous devez utiliser: mais vous pouvez l'utiliser dans la mise à jour Déclaration: La logique est que la valeur sera mise à jour à 99 uniquement si la valeur de la colonne est NULL, en raison de la fonctionnement de la regroupement - renvoyant la première valeur non nulle (Traitement de la liste fournie de gauche à droite).
+1 - Je dois être fatigué, j'essayais de le faire avec un cas déclaration ... O_O
Et du côté brillant, les colonnes sont toutes dans Réponse _ Format, de sorte que GREG devrait être capable de couper les scripts dans Excel assez rapide
Il suffit de sonder la table Sys.Columns pour chaque table et créez un SQL dynamique ... c'est une force brute, mais cela vous permet de devoir écrire tout le T-SQL out.
Par exemple: < Pré> xxx
Je suis partiellement d'accord avec Ashish Patel sur l'Isnull. Vous devez frotter les données de votre environnement de rapport et fournir les valeurs par défaut nécessaires pour simplifier le rapport SQL IMO. Je pense que l'Isnull est une fonction scalaire à démarrer, ce qui est tout aussi mauvais sur la performance (je ne peux pas sembler être capable de confirmer cette hypothèse via Google Recherches :)) Si les colonnes ne doivent pas être nuls, alors peut-être que le schéma devrait Soyez changé pour ne pas permettre à NULL ou à une valeur par défaut pour être ajoutée au niveau de la base de données. Encore une fois, cela est en dehors du champ d'application de la question et se résume probablement à chaque édifice des magasins.
Depuis que vous devez le faire partout où j'ai écrit du JavaScript pour vous aider à construire le SQL. Coupez et collez-la dans votre barre d'adresse de navigateur pour obtenir votre SQL.
javascript:sql='update your table set ';x=0;while(x <= 40){sql += 'answer_'+x+ ' = coalesce(answer_'+x+',99),\n';x++;};alert(sql);
Je n'aime pas l'idée de manipuler les données elles-mêmes aux fins de la déclaration. Si vous modifiez les valeurs NULL à 99 pour faciliter votre rapport, je considère que les données sont corrompues. Et s'il existe d'autres consommateurs en dehors des rapports qui nécessitent des données authentiques?
Je préférerais écrire une requête intelligente pour le rapport. Par exemple, si vous utilisez ISNULL (ColumnName, 99), il retournerait 99 chaque fois que la valeur de la colonne est null.
Je serais habituellement d'accord, mais dans ce cas, les valeurs nulelles ont été ajoutées par erreur au lieu d'utiliser la valeur correcte de 99. Modification également la requête de rapport n'est pas une option car il s'agit d'un système de déclaration exclusif.
Je suppose que j'ajouterais une contrainte non nulle avec un 99 par défaut sur chaque colonne?
Je regarde cela et je me demande pourquoi les colonnes ne sont pas les suivantes: AdministrationId, Instrumide, Répondu, Valeur. Heck, vous pouvez même ajouter un autre identifiant afin que vous puissiez fusionner toutes ces tables en 1 ...