Calcul dans l'instruction SQL

J'ai une table contenant un champ appelé ChannelId. Je veux le diviser en deux champs en fonction de la valeur. J'ai essayé ceci:Calcul dans l'instruction SQL

SELECT CustomerId, ChannelId = 1 as Chan1, ChannelId = 2 as Chan2 FROM ....

L'objectif étant que j'ai deux colonnes booléenne si le champ ChannelId est de la valeur approriate. Je reçois une erreur de syntaxe.

En regardant la syntaxe SQL Je ne vois pas pourquoi je ne peux pas utiliser une expression, puis l'alias comme un nouveau nom de colonne, mais SQL Server croassa dessus. Est-ce que je fais quelque chose de vraiment bête? Comment puis-je obtenir cet effet?

Source

2011-01-06 Mike Jones

Je ne comprends pas la question. S'il n'y a que deux valeurs dans la colonne, pourquoi ne pas simplement retourner les valeurs en colonnes? Voulez-vous effectuer un agrégat sur la colonne? comme dire compter combien de fois chaque valeur est présente? – spinon

Non, reformatage des données pour l'entrée dans un processus différent. –

Je pense que vous devez créer deux requêtes lâches (ou par sous-requêtes). L'astuce de SQL n'est pas de demander des choses dans la partie 'SELECT', mais dans la partie' WHERE'. – Marnix

Vous devez effectuer une expression, pas une affectation, et cela dépend de la saveur de SQL. Puisque vous utilisez SQL Server (T-SQL):

SELECT CustomerId, (CASE WHEN ChannelId = 1 THEN 1 ELSE 0 END) as Chan1, (CASE WHEN ChannelId = 2 THEN 1 ELSE 0 END) as Chan2 FROM ....

Il pourrait y avoir une meilleure façon de le faire, mais c'est comme je le fais.

Source

2011-01-06 21:42:36 SilverbackNet

Essayez:

select 
    CustomerId 
    , case when ChannelId = 1 then 1 else 0 end as Channel_1 
    , case when ChannelId = 2 then 1 else 0 end as Channel_2 
from Customer_Channel ;

Source

2011-01-06 21:42:48

Les gens ont déjà dit comment faire, en utilisant une déclaration de style CASE ... WHEN ... THEN, mais je voudrais simplement proposer l'avis que cela revient à avoir la logique métier dans la base de données. Typiquement, je vise à garder la base de données uniquement pour le stockage, et avoir une logique métier dans une couche supérieure de mon application. Je pense ainsi parce que si vous considérez une application pour avoir une architecture en couches, vous placeriez votre logique métier dans une couche, et une ou plusieurs couches plus profondes seraient votre base de données. Un ou plusieurs niveaux plus élevés seraient votre interface utilisateur. La "logique métier dans la base de données" est mauvaise, de la même manière qu'il serait mauvais de mettre la logique métier dans le gestionnaire pour un événement button_Click sur un formulaire.

J'apprécie que cela ne convienne peut-être pas à votre situation particulière en ce jour de 2011, mais j'espère que cela sera utile aux futurs lecteurs de cette question.

Source

2011-01-06 21:47:39

"logique métier dans la base de données" pouvez-vous expliquer pourquoi c'est mauvais –

Si vous considérez une application pour avoir une architecture en couches, vous mettriez votre logique métier dans une couche, et une ou plusieurs couches plus profondes seraient votre base de données. Un ou plusieurs niveaux plus élevés seraient votre interface utilisateur. C'est mauvais de la même manière qu'il serait mauvais de mettre la logique métier dans le gestionnaire pour un événement 'button_Click' sur un formulaire. –

Tout ce que vous pouvez mettre dans la couche inférieure est un avantage pur. Je n'ai jamais travaillé avec une architecture à 3 niveaux, mais avec 2 niveaux (client-serveur) je mettrais autant de logique métier que possible dans le back-end. Cela signifie des applications plus sûres et plus rapides. –

Calcul dans l'instruction SQL

Répondre

Questions connexes