Intérêt (voire utilité) des types composites

Saluton,
Je m'intéresse de très près, depuis peu, à PostgreSQL et je découvre, entre autres choses, les types composites qui me rappellent ma jeunesse avec les structures en langage PASCAL.
Cela étant, je m'interroge sur l'intérêt réel de cette possibilité, notamment en termes de conformation à la modélisation des données et, bien sûr, à la portabilité des requêtes (je pense notamment à PDO).
Merci d'avance à qui voudra éclairer ma réflexion.

C'est sûr que quand je lis ceci :

Citation:

---

For example, a column of a table can be declared to be of a composite type.

---

Et que je vois cet exemple :

Code:

---

1 2 3 4 5

CREATE TYPE inventory_item AS ( name text, supplier_id integer, price numeric );

---

Je me dis que ça revient à vouloir stocker plusieurs attributs dans une seule colonne, ce qui est contraire à l'atomicité requise par la première forme normale.

1) il est impossible d'indexer une structure composite (ou plus exactement cela n'est pas prévu sauf si le stockage bianire est ordonancé).
2) difficulté d'accès...
Imaginons un type composite composé à partir d'un type composite....

SELECT mabase.MonSchema.Matable.MaColonne.MonsSousType1.MonsSousType2.MonAttribut ....
FROM ....

mais aussi :

SELECT Matable.MaColonne.MonsSousType1.MonsSousType2.MonAttribut ....
FROM ....

Si l'utilisateur est dans le contexte de la base de données "mabase" et comme schéma par défaut "MonSchema"... Bref, impossible d'y retrouver ses petits... d'abord pour vous, mais aussi et surtout pour lui : résolution de nom a effectuer => baisse des perf !!!!!!

Bref, les types ont des avantages pour le simple stockage mais sont contraignant pour le requêtage !

A +

Je vois que nous nous rejoignons et vous remercie de conforter mon point de vue.
Je vais cependant de surprise en surprise puisque PostgreSQL propose également un type Tableau (Array)

Citation:

---

8.14. Tableaux

PostgreSQL™ permet de définir des colonnes de table comme des tableaux multidimensionnels de longueur variable. Il est possible de créer des tableaux de n'importe quel type utilisateur : de base, composé, enum. Toutefois, les tableaux de domaines ne sont pas encore supportés.
8.14.1. Déclaration des types tableaux

La création de la table suivante permet d'illustrer l'utilisation des types tableaux :

CREATE TABLE sal_emp (
nom text,
paye_par_semaine integer[],
planning text[][]
);

Comme indiqué ci-dessus, un type de données tableau est nommé en ajoutant des crochets ([]) au type de données des éléments du tableau. La commande ci-dessus crée une table nommée sal_emp avec une colonne de type text (nom), un tableau à une dimension de type integer (paye_par_semaine), représentant le salaire d'un employé par semaine et un tableau à deux dimensions de type text (planning), représentant le planning hebdomadaire de l'employé.

La syntaxe de CREATE TABLE permet de préciser la taille exacte des tableaux, par exemple :

CREATE TABLE tictactoe (
carres integer[3][3]
);

Néanmoins, l'implantation actuelle ignore toute limite fournie pour la taille du tableau, c'est-à-dire que le comportement est identique à celui des tableaux dont la longueur n'est pas précisée.

De plus, l'implantation actuelle n'oblige pas non plus à déclarer le nombre de dimensions. Les tableaux d'un type d'élément particulier sont tous considérés comme étant du même type, quels que soient leur taille ou le nombre de dimensions. Déclarer la taille du tableau ou le nombre de dimensions dans CREATE TABLE n'a qu'un but documentaire. Le comportement de l'application n'en est pas affecté.

Une autre syntaxe, conforme au standard SQL via l'utilisation du mot clé ARRAY, peut être employée pour les tableaux à une dimension. paye_par_semaine peut être défini ainsi :

paye_par_semaine integer ARRAY[4],

ou si aucune taille du tableau n'est spécifiée :

paye_par_semaine integer ARRAY,

---

et va même jusqu'à autoriser

Citation:

---

... les utilisateurs à ajouter de nouveaux types à PostgreSQL™ en utilisant la commande CREATE TYPE(7).

---

Je sais bien qu'il ne s'agit là que de possibilités que rien n'empêche, à l'inverse, d'ignorer; mais ces braves gens ne gaspillent-ils pas un temps précieux à mettre en œuvre des fonctionnalités qui m'apparaissent déviantes voire contre-productives, alors qu'elles semblent cependant, et paradoxalement, conformes au standard SQL (pour le type Array en tout cas) ?
Mes doutes ayant reçu d'aussi éminentes cautions, il vaut peut-être mieux en rester là, ce post commençant à virer au troll :mouarf:

Je suis bien d'accord avec toi Maljuna Kris, ces types sont contraires aux principes de base des bases de données relationnelles.