Envoyé par
kazou
ça dépend si on considère le sens de la chaine, ou le fait que ça soit une seule chaine
Je suppose que vous voulez dire qu’à la lettre la 1re forme normale est scrupuleusement respectée, mais qu’elle est copieusement violée dans l’esprit, auquel cas il est certain qu’on ne peut que recommander de s’attacher à l’esprit.
Envoyé par
kazou
Dans ce cas il absolument impossible de violer cette forme normal (a moins de ne pas mettre d'identifiant).
Puisqu’on parle de 1re forme normale, on se situe dans le cadre de la théorie relationnelle et dans cette théorie, on ne parle pas d’identifiant mais de clé candidate. Cela dit, je ne comprends rien à l’amalgame que vous faites de la normalisation et de la clé.
Par définition, chaque relation (table en SQL) comporte une clé, sinon ça n’est pas une relation mais un sac (bag), c'est-à-dire quelque chose qui est hors sujet.
La 1re forme normale ne concerne que les relations (et les variables dont elles sont les valeurs). Prenons la définition de Gardarin, on ne peut plus exacte et concise :
Une relation est en première forme normale si tout attribut contient une valeur atomique
atomique étant synonyme de scalaire. Voyez-vous figurer des termes tels que clé ou identifiant dans la définition ?
Qu'avez-vous exactement en tête ?
Maintenant, reprenons votre affirmation concernant les types scalaires :
Dans ce cas il absolument impossible de violer cette forme normale
Dans le cas d’un type scalaire comme Varchar, c’est certain, mais si vous utilisez des types non scalaires, vous violez la 1NF. Manifestement, la norme SQL n’en a cure et propose le type ARRAY ( c'est-à-dire TABLEAU), qui expose le niveau subatomique (on "désencapsule"). Un SGBD comme PostgreSQL en permet du reste la mise en oeuvre : Cf. PostgreSQL, Arrays.
Est-ce grave ? L'auteur de l'article auquel je vous renvoie donne son sentiment :... searching for specific array elements may be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale up better to large numbers of elements.
C'est-à-dire :... chercher des éléments particuliers dans un tableau peut être le signe d’une mauvaise conception de la base de données. Étudiez la mise en place d’une table séparée dont chaque ligne soit affectée à chaque élément du tableau. La recherche sera plus simple et cela sera plus adapté si ces éléments sont nombreux.
Et j'ajouterais : pensez à l'intégrité à l'occasion des mises à jour...
Je ne voudrais pas paraître strictement dogmatique, et le type ARRAY n'est certainement pas une mauvaise chose, mais il faut étudier l'ensemble des conséquences de chacun de ses choix, en sortant du cadre purement structurel.
Partager