Discussion :

[juju05]

Bonjour,

Je cherche à trier une vue sql par n° de commande. Ce n° est alphanumérique et s'écrit de la forme : ssaa-sequence.
La longueur du n° de séquence n'est pas fixe. Je peux donc avoir 2011-99 et 2011-1012.
Je souhaite avoir un tri décroissant de sorte que 2011-10001 se trouve avant 2011-9999.

Je pense fixer un nombre de caractères maximum à 12. Je voudrai concaténer ssaa au n° de séquence complété à gauche par des zéro de manière à atteindre les 12 caractères et trier par cette concaténation.
Je suis sur une bd Oracle.

Julien.

[Waldar]

Quelle idée ! Pourquoi ne pas avoir deux colonnes, année et numéro de commande, et gérer l'affichage par une vue avec une simple concaténation ?

Si vous pouvez encore changer votre modèle, faites-le, vous ne respectez pas le principe d'atomicité des données de la première forme normale.

[pacmann]

Salut !

Quelle idée ! Pourquoi ne...gérer l'affichage par une vue avec une simple concaténation ?

Si j'ai bien compris, c'est justement une vue

Je cherche à trier une vue sql par n° de commande.

Bref, juju, tu peux parser tout ça sur le "-" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
SQL> ed
écrit file afiedt.sql
 
  1  WITH t AS (
  2  SELECT '2011-10001' cd FROM DUAL UNION ALL
  3  SELECT '2011-9999' FROM DUAL UNION ALL
  4  SELECT '2010-11111' FROM DUAL)
  5  SELECT substr(cd, 1, 4), lpad(substr(cd, instr(cd, '-') + 1), 12, '0')
  6  FROM t
  7* ORDER BY substr(cd, 1, 4), lpad(substr(cd, instr(cd, '-') + 1), 12, '0')
SQL> /
 
SUBSTR(CD,1,4)   LPAD(SUBSTR(CD,INSTR(CD,'-')+1),12,'0')
---------------- ------------------------------------------------
2010             000000011111
2011             000000009999
2011             000000010001

=> Avec INSTR tu cherches la position du '-'
=> Avec SUBSTR tu découpes la chaîne d'une position A, pour un nombre de caractères B (si le deuxième paramètre est omis, c'est jusqu'à la fin)
=> avec lpad, tu "shiftes" une chaîne en remplissant avec le troisième paramètre

Voilà

(Bien sûr, si tu veux ajouter ça dans la définition de la vue, il sera plus facile d'utiliser les colonnes d'origine)

[Oishiiii]

Bonsoir,

Si vous pouvez encore changer votre modèle, faites-le, vous ne respectez pas le principe d'atomicité des données de la première forme normale.

En réalité la table qui aurait ce genre de valeur dans une de ses colonnes respecterait tout de même la première forme normale.
Le paragraphe auquel vous faites référence explique d'ailleurs que la notion d' "atomicité" est ambigüe et maintenant obsolète.

Pour un exemple de violation de première forme normale, voir par exemple : La première forme normale [Résolu]

Cela dit, je suis d’accord sur le fait qu'il s'agit ici certainement d'une erreur de modélisation et qu'il serait intéressant de créer deux colonnes. Une vue pourra éventuellement reconstruire le numéro de commande pour les utilisateurs.

[juju05]

Bonjour,

Je travaille sur un ERP sur lequel il est possible de définir le n° de commande tel quel afin que sur un écran de liste des commandes on puisse trier par celui-ci.

Chose faite très rapidement puisque cela ne fonctionne que pour les n° de séquence ayant le même nombre de caractères !

Merci pour vos réponses.

Julien.

[SQLpro]

Pour être vrai, la notion de 1FN à besoin du contexte de modélisation. Or à l'évidence, la requête demandée est catastrophique dans le modèle présenté par la vue.
Mais peut être la vue a fait une synthèse de deux colonnes....
Si dans la table cette données est en une seule colonne alors la 1FN n'est pas respectée compte tenu du contexte !

Lisez ce que je viens de publier à ce sujet : http://blog.developpez.com/sqlpro/p1...ances-petites/

A +

[Oishiiii]

Si dans la table cette données est en une seule colonne alors la 1FN n'est pas respectée compte tenu du contexte !

Je persiste La table serait tout de même en 1NF avec une colonne numéro de commande de ce style.

Nous n'avons pas la même compréhension de la définition de 1NF. Apparemment votre position n'a pas évoluée depuis cette discussion à ce sujet avec fsmrel ou vous semblez être en désaccord. Je me range du côté d'fsmrel à ce sujet.

Par exemple le viol de la notion d'atomicité (première forme normale), c'est à dire mettre plusieurs informations dans une même colonne est une erreur aux conséquences lourdes. Elle conduira tôt ou tard à des tables obsèdes et des acrobaties pour écrire des requêtes qui ne pourront jamais être optimisées.

Certes je suis entièrement d'accord avec vous, placer plusieurs informations (de même nature ou non) dans une colonne est une erreur de modélisation et c'est une source de complication, mais pas forcément une violation de 1NF si l'on suit la définition de Chris Date et fsmrel par exemple.

Bonne journée