Création d'objets "par lots"

**chaplin** · 13/10/2008, 13h56

perso je n'utilise pas du tout les procédures stockées. Je n'ai jamais vraiment compris pourquoi j'irais mettre du code dans la base.

Par exemple lorsque tu traites plusieurs millions d'enregistrements, tu peux élaborer un test au travers d'un procédure stockée,
par exemple vérifier qu'un champ date au format CHAR(8) soit bien converti en TimeStamp avant de faire une migration de base de données, cette
dernière pouvant être fait aussi par l'utilisation des procédures stockées.

Comme la procédure stockée s'execute dans le moteur natif SQL du SGBDR, tu obtiens les meilleures performances.

Certains maîtres te dirons même qu'il faut mettre toutes les règles métiers dans la base de donnée.

Tout SGBDR qui se respecte propose des procédures stockées.

Comme quoi à un pb donné -> plusieurs visions possibles.

Mais revenons à notre sujet:

Sauf peut-être si ce code permettait à la dite base de me retouner ...des objets

Si la base de données permet de créer des procédures stockées en dynamiques, je ne vois pas de raison qu'elles ne renvoient pas des objets
au travers d'interface qu'il faudrait créé dans le moteur SQL de la base de données au même titre que les procédures stockées.

**phplive** · 13/10/2008, 16h57

Certains maîtres te dirons même qu'il faut mettre toutes les règles métiers dans la base de donnée.

ha non ! des contraintes dans la base ok mais les règles dans mes objets
je veux pouvoir vérifier les règles (donc la cohérence d'un objet) avant de l'enregistrer dans l'espace de stockage

Où alors cela signifie-t-il qu'il faut faire un accès à la base pour vérifier chaque règle ?

Par contre pour les traitements batch il est clair que les procédures stockées peuvent apporter un réel gain de performance puisque pratiquement aucune donnée ne transite sur le réseau finalement.

Objet vs relationnel :
un article intéressant (jusqu'à la page 24 après c'est trop axé sur J2EE que je ne connais pas ..)
http://www.info.univ-angers.fr/~gh/i...stanceJ2EE.pdf

**chaplin** · 13/10/2008, 17h43

Objet vs relationnel :
un article intéressant (jusqu'à la page 24 après c'est trop axé sur J2EE que je ne connais pas ..)

De ton document, j'ai retenu:

La faiblesse du modèle objet réside dans la manipulation des données. Celle-ci s’effectue par envoi de messages (appels de méthodes),
et ce mécanisme s’avère nettement moins puissant que l’algèbre relationnelle.
...
Historiquement, la technologie objet a manqué de fondements théoriques et de standards au niveau des techniques de manipulation.

Et LINQ essaye de rattraper cette bévue.

utiliser une architecture hybride objet-relationnelle : avec cette approche, on peut tirer parti des avantages de la modélisation
par objets métier tout en bénéficiant de la fiabilité et des performances des bases de données relationnelles et en conservant,
le cas échéant, la compatibilité avec les bases de données relationnelles existantes. Cette solution marie avec élégance applications
anciennes et nouvelles, non seulement en termes d’architecture, mais aussi en termes de compétences investies dans les deux modèles
(développement, administration, exploitation… etc.). Cette approche est d’autant plus intéressante que la majorité des entreprises
possède un héritage relationnel fort (culture, compétences, produits utilisés, relations commerciales, etc.) et que ce modèle hybride
est parfaitement adapté à la majorité des applications développées par les entreprises.

Donc, pour parler plus concrètement j'aurais du parlé de modèle hybride.

Il y a encore un framework Open Source qui s'appelle TiOPF qui semble être assez proche de ce que tu cherches à réaliser.

**phplive** · 13/10/2008, 19h03

Ben oui les hybrides ! C'est pourtant d'actualité

... en attendant l'hydrogène et la pile à combustible

Décidément y'a pas que dans le domaine des énergies que ça peut fonctionner

D'ailleurs c'est clair que je n'ai pas l'intention de renoncer aux SGBD ni au SQL direct lorsque le besoin s'en fait sentir.

**ShaiLeTroll** · 14/10/2008, 15h08

Code :

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

MyFacture.Nom_Client := MyClient.Nom_Client;

Cela peut se faire via des TFields déclaré dans le code (avec un petit Value en plus ...), certe la syntaxe amené par le "FrameWork" Objet facilite le travail, mais cela fourni surtout des mécanismes automatiques avec la Base automatique mais pas implicite car clairement décrit dans un XML, et la surcharge des méthodes force le développeur à prendre conscience de ce qu'il utilise !

Code :

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

MyFacture.Client := MyClient;

avec la couche que j'ai écrit ça donnerait plutôt (et surement celle de phplive aussi, qui utilise des collections)

Code :

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

MyClient.Factures.Add(MyFacture);

Dans une relation, 1-n, comme pour phplive, MyFacture a une propriété publiié ID_Client (clé étrangère), ... pour une relation n-n, il n'y a pas de propriété mais une table de le relation (ou même un objet carrément si il y a des informations pour la relation comme une Date par exemple), le save créant dans la table la relation ID_Client et ID_Facture ...

Pour les Designs Patterns, idem, je connais de nom, j'en fait sans le savoir !

Envoyé par Pascal Jankowski

Par ailleurs, en ce qui concerne UML et les bases de données, je peux t'assurer que tu peux vraiment concilier les deux. En effet, j'utilise au quotidien les InstantObject, j'utilise également ModelMaker qui me permet de bâtir mon modèle UML puis d'obtenir assez simplement le modèle relationnel

Ah, j'aimerais bien voir ça un jour ! Cela doit vraiement changer la méthode de travail, où je suis on fait n'importe comment tout ce qu'on peut ! ça marche, c'est la méthode utilisée depuis des années, après il y a de la maintenance à vendre

**phplive** · 14/10/2008, 16h57

Bjr

MyFacture.Nom_Client := MyClient.Nom_Client;

De mon point de vue cette affectation n'a pas lieu d'être !
Si je désire sauvegarder le nom du client je le fais lors du
MyFacture.Client := MyClient.Client;

En fait MyFacture.Nom_Client est une propriété READ ONLY
En effet pourquoi vouloir changer le nom du client dans la facture ?

MyClient.Factures.Add(MyFacture);

Oui ca marche de cette façon

mais on peut aussi envisager MyFacture := MyClient.NewFacture();

Dans une relation, 1-n, comme pour phplive, MyFacture a une propriété publiié ID_Client (clé étrangère), ... pour une relation n-n, il n'y a pas de propriété mais une table de le relation (ou même un objet carrément si il y a des informations pour la relation comme une Date par exemple), le save créant dans la table la relation ID_Client et ID_Facture ...

Mais relations sont en fait fixées par l'objet métier : si j'ai une table j'ai une relation 0-n point

Si par ex j'ai le cas

Etudiants
Etudiant_ID
...

Cours
Cour_ID
....

Inscrits
Cour_ID / Etudiant_ID
...

J'aurais

Code :

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

1
2
3
4
5
6
IBOCourList
	IBOCour 
		IBOInscritList
			IBOInscrit
				IBOInscritEdudiant
				IBOInscritCour

Sachant que IBOCour et IBOInscritCour pointent certe vers le même objet persistant IPOCour mais sont 2 objets métiers distincts

**chaplin** · 14/10/2008, 17h02

J'ai trouvé dans le tuto suivant:

http://laurent-dardenne.developpez.c...hi/Interfaces/

Sur la plate-forme Win32 seules les classes peuvent implémenter des interfaces, en revanche sous la plate-forme .NET le type enregistrement (Record) peuvent également implémenter des interfaces.

Si une base de données pouvaient envoyées en .NET des records élaborées
à partir d'interface dans un programme, le résultat pourrait être pas mal.

C'est juste des idées en l'air

**DarkWinter** · 14/10/2008, 19h15

Le type Record de Delphi .Net est en fait l'équivalent du type struct de Java / C#. Il fonctionne comme un type valeur - c'est à dire comme un integer ou un string - et non pas comme un type reférence, c'est à dire une classe. Il n'est donc pas possible de modéliser des relations entre entités avec ce type.

En fait MyFacture.Nom_Client est une propriété READ ONLY
En effet pourquoi vouloir changer le nom du client dans la facture ?

J'y connait rien en logiciels de gestion commerciale, mais lorsque je commande sur le net j'ai la possibilité de modifier l'adresse de facturation et de livraison

.

En fait si je proposais MyFacture.Client := MyClient; , c'est plutot pour pouvoir écrire, si par exemple l'utilisateur souhaite filtrer l'affichage de ses factures d'après un groupe de client :

Code :

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

List<Facture>MaListeDeFactureFiltree = MesFactures.where(p => p.Client.Groupe == MonGroupeFiltre).ToList();

Navré de mettre du Linq, mais cela me fait moins de code a taper

Chose pas possible si je n'est pas le lien entre mes factures et mes clients, sauf a relancer une requête SQL sur le serveur.

**phplive** · 15/10/2008, 10h18

Bjr

J'y connait rien en logiciels de gestion commerciale, mais lorsque je commande sur le net j'ai la possibilité de modifier l'adresse de facturation et de livraison .

Oui mais là tu parles de l'interface graphique. Derrière les données saisies sont stockées/manipulées différemment.
Pour les adresses comme ellles sont effectivement enregistrées dans la facture les affectations Facture.AdresseLivraison := AdresseLivraison sont possibles.
Mais tout ceci s'apparente juste à des règles de gestion propre à la facture.

MyFacture.Client := MyClient;

Ca par contre il le faut bien sûr ! Dans MyFacture ça met à jour à la fois
MyFacture.ClientID et la référence vers l'objet MyClient donc MyFacture.SubObjects['Client'] (en interne)

LINK ? Connait pas

A priori on dirait une sorte de SQL Objet couplé à un générateur SQL classique si nécessaire.

j'utilise D7 pas Visual Studio.
Mais j'ai hâte de pouvoir utiliser les templates avec Delphi 2009

Pour réaliser l'équivalent je pense que j'écrirais

MyFactureListFiltered := MyFactureList.Clone(Filter, Sorter)

avec Filter correspondant à ton where et Sorter au group by

Encore que j'ai jamais écrit ce genre de truc c'est juste une idée

**ShaiLeTroll** · 15/10/2008, 11h26

C'est un peu dans l'idée de ce que j'ai fait pour mes Collections, utilisés avec un DBGrid

Code :

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

1
2
3
    class function Select(const Keys: array of string; const Values: array of Variant; OnlyOne: Boolean = False): TEpcPersistantCollection; overload;
    class function Select(const Keys: array of string; const Values: array of Variant; OnlyOne: Boolean; const Operators: array of TRelationalOperatorType): TEpcPersistantCollection; overload;
    class function Select(Location: TPersistantProcLocation; const ProcName: string; const Values: array of const; Index: Integer = 1; OnlyOne: Boolean = False): TEpcPersistantCollection; overload;

Code :

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

1
2
3
4
5
6
7
 
TMyFacture.PersistantClassDescriptor.Order := 'FieldTruc, FieldMachin';
MyFactureCollection1 := TMyFacture.Select(['FieldTruc'], [EdFiltreTruc.Text]);
MyFactureCollection1.DataSource := DBGrid1.DataSource;
 
MyFactureCollection2 := TMyFacture.Select(pplXML, 'SelectFilterFactureTruc', [EdFiltreTruc.Text]);
MyFactureCollection2.DataSource := DBGrid2.DataSource;

je l'ai prévu mais pas codé (je n'ai pas bcp bossé sur l'héritage des collections pour le moment)

Code :

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

TMyFactureCollection.DefaultOrder := 'FieldTruc, FieldMachin';

On retombe tous sur les mêmes choses ...

**chaplin** · 15/10/2008, 12h45

Un algèbre relationnel des objet/types intégré dans Delphi.

A l'époque ils faisaient des batch comme on utilisait la BDE par TTable sans TQuery(SQL).

Aujourd'hui on fait des procedures stockées avec SQL. Pourquoi ne pas avoir une forme de SQL intégré dans l'EDI ?

La norme SQL a été une révolution dans les bases de données. Je rappelle sa définition:

Structured Query Language, traduisez Langage de requêtes structuré

Lorqu'on fait une application de gestion s'appuyant sur un SGBDR, on fait des:

- Filtres
- Ordres de trie
- Manipulations de données
- Loockup (ie jointure)
- vues (ie Grid,DBgrid)

Le problème aujourd'hui, c'est qu'on communique avec les SGBDR en leur envoyant des commandes entre crochets, c'est à dire du string à donf !!

Est ce que les compilateurs ne seraient pas capable de comprendre ces syntaxe directement au niveau du language et de les traduire en language
SQL, après il s'agirait aux fournisseurs des SGBDR d'en faire les adaptations.

En fait il s'agit de prendre le problème à l'envers

**phplive** · 15/10/2008, 15h55

Bjr

Est ce que les compilateurs ne seraient pas capable de comprendre ces syntaxe directement au niveau du language et de les traduire en language
SQL, après il s'agirait aux fournisseurs des SGBDR d'en faire les adaptations.

Oui mais pour le moment c'est surtout l'application qui génère dynamiquement du code SQL standard ou utilise du code "en dur" et l'envoi au SGBDR .

Note que LINQ (et pas LINK

) le fait déjà : en fait si j'ai bien compris les ex que j'ai parcouru depuis c'est une sorte de SQL mais côté application on utilise exclusivement les noms des objets / des attributs. Ca génère également une liste d'objets correspondant à la requête. Ensuite si on a une base de données le tout est converti en SQL. Si on utilise du XML en fichier XML / XPATH etc ...

Par contre la base de données ne semble pas faire grand chose de plus.

**chaplin** · 15/10/2008, 17h12

On est d'accord sur LINQ, mais si des bases de données sont capables de crées des tables en mémoire,
pourquoi ne peut on pas transposé cette mécanique à un EDI, juste pour la partie Cache avec une syntaxe SQL
standard avec une précompilation. En plus comme Delphi permet de mixer POO et code procédural, c'est possible.

QT le fait bien avec son mécanismes des slots. Pourquoi pas faire la même chose en SQL.

**phplive** · 15/10/2008, 17h29

pourquoi ne peut on pas transposé cette mécanique à un EDI, juste pour la partie Cache avec une syntaxe SQL
standard avec une précompilation

C'est plus ou moins ce que font les framework non ?

**chaplin** · 15/10/2008, 18h38

Voici un bout de code que j'ai trouvé dans une doc Interbase. On est d'accord que ce n'est pas de l'objet.
Quand on regarde ce que fait ce petit bout de code, c'est tout de même puissant

et surtout lisible et compréhensible

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
EXEC SQL
BEGIN DECLARE SECTION;
char country[26], asciimult[10];
int multiplier;
EXEC SQL
END DECLARE SECTION;
. . .
main ()
{
EXEC SQL
DECLARE CHANGEPOP CURSOR FOR
SELECT CITY, POPULATION
FROM CITIES
WHERE COUNTRY = :country;
printf("Enter country with city populations needing adjustment: ");
gets(country);
EXEC SQL
OPEN CHANGEPOP;
EXEC SQL
FETCH CHANGEPOP INTO :country;
while(!SQLCODE)
{
printf("\nPercent change (100%% to -100%%:");
gets(asciimult);
multiplier = atoi(asciimult);
EXEC SQL
UPDATE CITIES
SET POPULATION = POPULATION * (1 + :multiplier / 100)
WHERE CURRENT OF CHANGEPOP;
EXEC SQL
FETCH CHANGEPOP INTO :country;
if (SQLCODE && (SQLCODE != 100))
{
isc_print_sqlerr(SQLCODE, isc_status);
EXEC SQL
ROLLBACK RELEASE;
exit(1);
}
}
EXEC SQL
COMMIT

Je ne suis pas convaincu qu'il faille systématiquement faire du 100% objet pour faire du bon code.
Ici ils utilisent une directive EXEC SQL qui sera traité lors d'une précompilation. J'attire juste l'attention
sur l'absence de chaîne de charactère et que c'est écrit dans un langage C,
disons dans un langage de programmation qui intègre SQL.

**phplive** · 16/10/2008, 09h47

Bjr

Je ne suis pas convaincu qu'il faille systématiquement faire du 100% objet pour faire du bon code.

je suis d'accord ! y'a pas de bon ou mauvais code y'a que des bons ou mauvais programmeurs

(bien sûr c'est une notion très subjective ...)

Evidemment que même en POO je mixe avec de la prog procédurale classique voir des appels à des outils qui n'ont rien à voir avec Delphi si nécessaire

Maintenant pour rien au monde je n'abandonnerais la POO pour revenir au tout procédurale : on est bien d'accord ?

Le C possèdant un précompilateur c'est un avantage sur Delphi.
Je passerais sur les références circulaires entres unités sous Dephi qui m'obligent souvent à rassembler des codes dans la même unité alors qu'ils devraient être dans des unités distinctes

**chaplin** · 16/10/2008, 12h52

Maintenant pour rien au monde je n'abandonnerais la POO pour revenir au tout procédurale : on est bien d'accord ?

,bien entendu, je suis allé dans les extrèmes afin de poser le problème en explorant les difficultés
et soulevé des questions afin de s'interrogé sur les objectifs du framework, de ses forces et de ses faiblesses.

Un framework de persistence objet encapsule la couche de communication avec des fournisseurs
d'accès aux données.

J'ai évoqué un SQL dans l'EDI. Nous avons deux approches extrèmes de la programmation.

J'ai regardé le code source du composant TIBSQL, je prends cet exemple car il utilises
une interface pour communiquer avec l'API WIN32 d'interbase. On envoi une instruction SQL
que la dll s'empresse d'interprêter et renvoie une structure de données par l'appel d'une
autre fonction, ils ne perdent pas le fil de la communication grâce au Handle.

Est-ce possible de créer une fabrique d'objet/classe/interface qui par le biais d'un TIBSQL pour l'exemple
concerné sans passer par un framework intermédiaire comme DBExpress, pour répondre à la question de la performance.
J'ai bien conscience que je n'ai pas formuler correctement le besoin, j'insiste sur le concept.

Ce raisonnement pourrait s'appliquer à une autre base de données.

je suis d'accord ! y'a pas de bon ou mauvais code y'a que des bons ou mauvais programmeurs

J'ai le sentiment que des langages comme Java ou C# ont été fait sur un cahier des charges
pour limiter les déviances de certains programmeurs

(100% objet,héritage simple,absence de pointeurs, garbage collector) .

En .NET, il est question de code managé.

**Franck SORIANO** · 16/10/2008, 13h58

Envoyé par chaplin

Ici ils utilisent une directive EXEC SQL qui sera traité lors d'une précompilation. J'attire juste l'attention
sur l'absence de chaîne de charactère et que c'est écrit dans un langage C,
disons dans un langage de programmation qui intègre SQL.

Et quel est l'intérêt d'une telle chose ?
Entre :

Code :

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

1
2
 
EXEC select * from MaTable

Et

Code :

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

1
2
 
EXEC "select * from MaTable"

Dans le premier cas, tu mélanges dans le même source du code SQL et le code de ton langage.
Dans le deuxième cas, tu délimites ce qui ne fait pas partie de ton source et qui sera exécuté par le serveur, dans une chaîne de caractères. Je préfère de loin la deuxième solution. D'autant plus que dans la première, tu ne sais pas comment ton langage va faire pour exécuter la requête. Tu ne sais pas si va travailler de façon optimale. Et s'il fait n'importe quoi, tu n'as pas la possibilité de reprendre la main sur l'exécution de la requête pour faire le travail plus efficacement...

J'ai le sentiment que des langages comme Java ou C# ont été fait sur un cahier des charges
pour limiter les déviances de certains programmeurs (100% objet,héritage simple,absence de pointeurs, garbage collector) .

Je pense que Java a clairement été écrit pour des puristes de l'OO.
Par contre les concepts dont tu parles ne sont pas là que pour limiter les erreurs des devs :
héritage simple : L'héritage multiple est très complèxe, surtout pour le compilateur et d'une utilité limité. Même en C++, il est rarement utilisé. Je pense plutôt que les concepteurs de Java et C# ont choisit de faire l'impasse dessus pour simplifier les compilateurs.
absence de pointeurs : Heu, les pointeurs existent en C# !
garbage collector : Le garbage collector est un excellent moyen d'améliorer les performances d'une appli, surtout en C#. Il permet de rendre les allocations mémoires quasi-instantanée, tout en retardant les traitements lourds de libération mémoire à un moment où l'appli n'a plus grand chose à faire.
De plus, c'est plus un piège à débutant qu'une réelle aide. Ca fait croire aux débutants qu'ils n'ont plus à se préoccuper de la gestion des ressources. Ca les encourage à conserver des références plus longtemps que nécessaires (ce qui donne des memory leak aussi grave que d'oublier de faire un Free en Delphi).
Au final même avec un GC, on a toujours besoin du Dispose-pattern.

**phplive** · 16/10/2008, 14h21

afin de s'interrogé sur les objectifs du framework, de ses forces et de ses faiblesses.

Evidemment ! le framework n'est pas la panacée dans tous les cas. Pour les situations qui nécessites des traitements lourds manipulant des millions d'enregistrements il est préférable de continuer à s'en remettre à la base : elle est robuste elle est fiable (ou alors faut en changer

) elle a été concue et optimisée pour ça. Bref la requête c'est son truc

Par ex pour du reporting l'accès direct via SQL est plus efficace c'est certain que des objets qu'on charge.

maintenant dans une application un peu complexe où on manipule n fenêtres à la fois et où les même données peuvent être représentée de N manières différentes simultanément je pense que le framework peut apporter un plus.

Est-ce possible de créer une fabrique d'objet/classe/interface qui par le biais d'un TIBSQL pour l'exemple
concerné sans passer par un framework intermédiaire comme DBExpress, pour répondre à la question de la performance.
J'ai bien conscience que je n'ai pas formuler correctement le besoin, j'insiste sur le concept.

Y'a pas de raison de penser qu'on puisse pas le faire : la couche DBExpress exite bien non ? Donc cette nouvelle fabrique viendrait en lieu et place

Accèder directement aux API n'est pas gênant et garantie une efficacité optimum (sous réserve que l'API soit bien écrite bien sûr).
Par ex pour accèder à MySQL vaut-il mieux utiliser le BDE+lien ODBC via MyODBC, DBExpress + libmysql.dll ou directement appellé les API de MySQL ?
Intuitivement je serais tenter de répondre : la 3ème solution ...
Par contre ça nécessite plus de travail que de réutiliser des objets déjà tout fait. Faut donc bien peser le pour et le contre.

J'ai le sentiment que des langages comme Java ou C# ont été fait sur un cahier des charges
pour limiter les déviances de certains programmeurs

Il est clair qu'avec la montée en puissance des PC et les GO de RAM embarqués peu de développeurs se soucis d'instancier un tableau d'1 Mo même si au final l'application ne se sert que de 300 Ko. Ceux qui ont connus les machines moins puissantes font peut être plus attention.
Comme en plus les compilateurs sont laxistes mais sympa ils masquent les memroy leak mais libèrent qd même la mémoire à la fin.
Jusqu'au jour où on a une appli multi-threadée à développer mettant en jeu un service par ex qui doit tourner des jours voir des mois, le truc déjà nettement moins trivial : oh ben c'est bizarre ça le process bouffe de plus en plus de RAM et et au bout de quelques heures/jours/mois le serveur tombe !

Maintenant loin de moi l'idée de me plaindre de la gestion automatique des chaînes par Delphi, des tableaux dynamiques etc ...

En .NET, il est question de code managé

Bien que ne développant pas en .NET il me semble qu'il reste encore une possibilité de gèrer des weak references : ha tient donc ?

**chaplin** · 16/10/2008, 14h41

Dans le deuxième cas, tu délimites ce qui ne fait pas partie de ton source et qui sera exécuté par le serveur, dans une chaîne de caractères

J'ai eu une discussion avec un programmeur VB de formation scientifique qui me parlait de cette abérration

des commandes SQL en chaîne de charactère dont les erreurs ne sont pas détectées à la compilation
mais au moment ou le serveur interprête la commande.

Pourquoi ont ils inventé LINQ (TO XML,TO SQL, TO ...) ?

Sur AS400, dés que tu changes la base de données, il va te lancer automatiquement des warnigs sur tout les programmes touchés (RPG).
J'insiste sur le fait qu'il faut s'en tenir à l'idée pas à l'exemple.

Parce qu'au fond, quand on modifie la structure des tables (ie DBA), va
bien falloir revoir le schmilblick

pour répercuter les modifications.
Autrement dit le monde SQL impose sa vision au monde objet.

Pour le reste, je me suis un peu égaré