Aide pour le choix d'une suite SGBD sur MacOS

[saint.112]

Bonjour à toutes et à tous
J’ai eu quelques problèmes de santé, plusieurs ennuis à résoudre, plus les obligations usuelles.
J’ai tout de même fait un peu de homework. J’ai réfléchi à mon diagramme.
J’ai décidé, à tort ou à raison, de procéder ainsi pour le développement :
Je vais commencer par la modélisation de la base sans faire appel à l’IA sauf pour des cas particuliers. Je connais mon modèle par cœur et j’ai des idées précises sur la structure. J’ai aussi des conventions de nommage des objets auxquelles je suis habitué et qui ont fait leur preuve. Je suis assez maniaque sur ce terrain.
J’ai cherché pendant un moment les softs avec une interface graphique qui m’éviteraient de me palucher le code SQL, en vain, jusqu’à ce que je tombe par hasard sur une vidéo sur les database designers : Top Free ER Diagram Tools for PostgreSQL, dont le titre est trompeur car la plupart de ces outils ont des versions simplifiées gratuites mais sont dans l’ensemble payants, certains abordables et d’autres assez chers.
Ce que j’attends de ces outils :

1. Les modelers :
   • Créer les tables, les colonnes, les relations, les index, etc., dans une interface graphique en n’ayant pas de code à écrire ou très peu.
   • Documenter systématiquement tous les objets.
   • Générer le script SQL (ça va de soi).
   • Exporter un document .pdf ou HTML du diagramme et des scripts. Ça me parait indispensable pour donner le bébé à une IA.
   
   Dans ce registre j’ai sélectionné trois modelers possédant une interface graphique pour le DDL et générant automatiquement le code SQL :
   
   1. pgModeler
      La version gratuite est assez complète.
      La version payante doit revenir assez cher : from $59.90/6 months
   2. DbSchema
      La version gratuite est assez complète.
      La version payante One Time 196$ + Taxes possède une fonction Visual Query Builder qui me fait baver.
   3. Luna Modeler
      Pas de version gratuite mais une version abordable à $99 USD Pay once qui possède pas mal de fonctions et a une interface graphique formidable. Je la trouve assez tentante.
      La version payante à $189 USD Pay once ne possède pas grand-chose de plus et rien de vraiment pertinent pour moi.
2. Les IDE
   Jusqu’à présent, suivant vos conseils, je n’ai retenu que Jetbrains. Il fait ce que les précédents ne font pas. Je n'ai aucune religion concernant le langage de programmation. Si je comprends bien c'est Python qui recueille le plus de suffrages.

Une fois que j’aurai créé mon modèle je donnerai le bébé à une IA pour la création de l’interface utilisateur. Ça me demandera un certain travail en aval pour établir mon projet. Je donnerai les vues que j’ai mises plus haut de mon ancienne base.
Nico
-----

[saint.112]

Pour plus de clarté, je crée un message pour chaque thème.
Ici c’est la question de l’import des données. J’avais fait de mon ancienne base un export complet des données au format tabulé. Plusieurs des outils listés dans le message précédent possèdent des fonctions d’import à partir de fichiers CSV ou TSV. Mais la question qui se pose est celle des clés primaires et étrangères. Aucune base de données ne va admettre d’importer dans les clés primaires des valeurs qu’elle n’a pas générées elle-même. Sans ça ce sont toutes les relations partent à la baille. C’est peut-être banal pour vous. J’ai fini par imaginer le stratagème suivant.

Supposons les deux tables liées suivantes :
Mother_Table
PrimaryKey_MT
Daughter_Table
PrimaryKey_DT
ForeignKey_MT
La relation se fait de PrimaryKey_MT à ForeignKey_MT.

J’ajoute à chaque table une colonne pour importer les clés des fichiers externes :
Mother_Table
PrimaryKey_MT
Imported_PrimaryKey_MT
Daughter_Table
PrimaryKey_DT
ForeignKey_MT
Imported_ForeignKey_MT

Je ne sais pas s’il est possible de faire une relation entre ces deux nouvelles colonnes. En tout cas un script va parcourir toute la table Daughter_Table, rechercher pour chaque enregistrement dans Mother_Table la valeur de Imported_PrimaryKey_MT égale à celle de Imported_ForeignKey_MT et copier celle PrimaryKey_MT dans ForeignKey_MT. Puis je pourrais supprimer les deux colonnes Imported qui ne servent plus à rien. À moins de les conserver pour le cas où.
Qu’en pensez-vous ? Y a-t-il d’autres solutions éventuellement plus simples.
Nico

[saint.112]

Encore une question pour votre sagacité.
En ce qui concerne les libellés sur les formulaires et les boites de dialogues etc., j’ai commencé comme tout le monde par les taper directement dans un champ texte sur le formulaire lui-même. À l’usage j’ai trouvé ça difficile à gérer, en particulier pour avoir des libellés cohérents.
J’ai voulu avoir une liste de libellés centralisée et les afficher dans des variables sur les formulaires. Pour ça j’ai créé une table spécifique et une procédure pour renseigner les variables au lancement de l’appli. J’ai raffiné la chose en créant une table secondaire permettant de créer autant de versions dans des langues différentes que voulu.
Ça s’est révélé très pratique.
Je suppose qu’on peut implémenter ça avec les outils à ma disposition.

[polo974]

...
Aucune base de données ne va admettre d’importer dans les clés primaires des valeurs qu’elle n’a pas générées elle-même. ...

Bonjour,
Ben si, à partir du moment où il n'y a pas de doublon, ça insère, sauf si ta clé primaire est une une séquence (gérée en interne par la base).

Bon, en effet, si tu aimes les séquences, il faudra ajouter les colonnes Imported_*** avec une contrainte "unique" sur la primaire pour éviter les accidents industriels entre 2 imports (et si conflit, "décorer" les clés importées de façon différente d'un import à l'autre).

Au moment de l'import des tables filles, il faudrait directement ajouter la colonne de clé étrangère avec le bon select pour récupérer la nouvelle clé primaire (à voir si l'importateur csv en est capable), sinon, en mode cochon, il faut momentanément désactiver la clé étrangère, le temps de faire l'import puis la mise en phase de la (nouvelle) clé étrangère puis réactiver...

[saint.112]

Bonjour,

Ben si, à partir du moment où il n'y a pas de doublon, ça insère, sauf si ta clé primaire est une une séquence (gérée en interne par la base).

Oui, par défaut je la mets AUTO INCREMENT. Donc il me semble qu'il vaut mieux ne pas risquer d'interférer.

Bon, en effet, si tu aimes les séquences, il faudra ajouter les colonnes Imported_*** avec une contrainte "unique" sur la primaire pour éviter les accidents industriels entre 2 imports (et si conflit, "décorer" les clés importées de façon différente d'un import à l'autre).

Je n'aime pas particulièrement les séquences, c'est par paresse et par souci de sécurité que je laisse le SGBD attribuer les clés primaires automatiquement.
Donc toute la manip consiste à attribuer, pour chaque enregistrement fille, dans la ForeignKey_MT la PrimaryKey_MT qui va bien.
Le premier import proviendra d'une base qui fonctionne. Donc il n'y a aucun souci de conflits. Par sécurité, une fois la manip terminée j'effacerai les Imported_PrimaryKey_MT et Imported_ForeignKey_MT qui n'ont plus d'utilité et qui risquent de créer de conflits par la suite.
Par contre j'ai une tripotée de fichiers txt divers et variés de ce genre :

Title	Time	Composer	Performers	Album
Roadhouse Blues	4:06	Jim Morrison, The Doors	Jim Morrison, v; Ray Manzarek, kbrd; Robby Krieger, g; G. Puglese (John Sebastian), harm; Lonnie Mack, b; John Densmore, d	Morrison Hotel

Ça risque d'être beaucoup plus rock and roll car il s'agit de vérifier à chaque coup si chaque entité n'a pas déjà son enregistrement sinon le créer, créer le nouvel enregistrement intermédiaire Interprétation entre la table Œuvre et la table Artiste.

Au moment de l'import des tables filles, il faudrait directement ajouter la colonne de clé étrangère avec le bon select pour récupérer la nouvelle clé primaire (à voir si l'importateur csv en est capable), sinon, en mode cochon, il faut momentanément désactiver la clé étrangère, le temps de faire l'import puis la mise en phase de la (nouvelle) clé étrangère puis réactiver...

Je ne comprends pas bien le problème :
Pour chaque nouvel enregistrement de chaque table le SGBD attribue le nouveau numéro incrémenté (du moins je le suppose) aux clés primaires.
Par contre :

• Dans la table mère le Imported_PrimaryKey_MT est importé du fichier TSV.
• Dans la table fille le Imported_ForeignKey_MT est importé du fichier TSV.

Donc à ce niveau il n'y a pas de risque de conflit même si on a établi une relation entre les deux.

Je préfère les fichiers TSV (tabulés) parce que qu'il risque d'y avoir des virgules dans certains champs et ça va mettre le souk si ce sont des fichiers CSV (avec séparateurs virgules).

[umfred]

Pour les clés étrangères, il faut qu'elles soient déjà présentes dans sa table source, sinon erreur (tu ne peux pas faire le lien avec la source si dans la source la donnée n'est pas présente)

[polo974]

Bonjour,
...
Je ne comprends pas bien le problème :
Pour chaque nouvel enregistrement de chaque table le SGBD attribue le nouveau numéro incrémenté (du moins je le suppose) aux clés primaires.
Par contre :

• Dans la table mère le Imported_PrimaryKey_MT est importé du fichier TSV.
• Dans la table fille le Imported_ForeignKey_MT est importé du fichier TSV.

Donc à ce niveau il n'y a pas de risque de conflit même si on a établi une relation entre les deux.

Je parlais de la nouvelle clé étrangère qu'il faut alimenter...
Mais, sinon, s'il n'y a qu'un seul import "massif", créer les tables sans associer de séquences, importer avec avec les clés existantes en tant que clés "réelles" puis créer et associer les séquences avec comme valeur initiale un truc genre select max(clé) from table:

CREATE SEQUENCE serial_one as bigint OWNED BY table_one.pkey_one ;
select setval('serial_one', (select max(pkey_one) from table_one));

(on peut ajouter 1000000 au max pour séparer "visuellement" les premières données des suivantes)
(quelle beeep, on ne peut pas mettre un select dans le CREATE SEQUENCE, du coup, mise en place de la séquence en 2 étapes...)
(et oui, j'aime pas les majuscules à outrance, mais je laisse quand je copie/colle...)

Et ensuite, vogue la galère pour tes autres sources ...

test=> select * from table_one;
   name   | pkey_one 
----------+----------
 toto     |        5
 totobis  |       77
 trucmuch |       79
(3 lignes)

test=> insert into table_one (name,pkey_one) values ('machin chose',nextval('serial_one'));
INSERT 0 1
test=> select * from table_one;
     name     | pkey_one 
--------------+----------
 toto         |        5
 totobis      |       77
 trucmuch     |       79
 machin chose |       80
(4 lignes)

test=>

Je préfère les fichiers TSV (tabulés) parce que qu'il risque d'y avoir des virgules dans certains champs et ça va mettre le souk si ce sont des fichiers CSV (avec séparateurs virgules).

Oui, je comprends, j'ai parlé de CSV comme on parle de Frigidaire...
Quand j'ai des trucs dans un tableurs et que je dois mettre ça dans une base, je construis parfois le insert à la suite des colonnes brutes, mais bon, un bon petit python fait ça plus proprement surtout quand il y a des "astropofs" dans le texte...

[saint.112]

Pour les clés étrangères, il faut qu'elles soient déjà présentes dans sa table source, sinon erreur (tu ne peux pas faire le lien avec la source si dans la source la donnée n'est pas présente)

Ça ne m'avait pas échappé.
Je suppose, peut-être à tort, qu'au moment de l'import, à chaque nouvel enregistrement créé le SGBD attribue à sa clé primaire le numéro selon la règle définie.

[saint.112]

(on peut ajouter 1000000 au max pour séparer "visuellement" les premières données des suivantes)
(quelle beeep, on ne peut pas mettre un select dans le CREATE SEQUENCE, du coup, mise en place de la séquence en 2 étapes...)

C'est la première solution qui m'est venue à l'esprit mais à la réflexion elle présente plusieurs défauts.
Le premier est que je définis mes clés primaires selon ce modèle :
"PK_Artist" longint PRIMARY KEY AUTO_INCREMENT UNIQUE CREATE INDEX "Ind_PK_Artist",
Je n'ai pas envie de mettre le souk là-dedans ou alors il faudrait que je désactive la clause AUTO_INCREMENT pour toutes les tables. Bonjour la galère et peut-être les dégâts. Et comme j’aurai l’occasion de répéter la manip ça deviendra ingérable.

Je pars du principe, peut-être erroné, corrigez-moi si je me trompe, que quand on fait une importation d’enregistrements à partir d’un fichier texte les clés primaires sont alimentées normalement.
Dans mon schéma (fort schématique) :

Mother_Table
PrimaryKey_MT
Imported_PrimaryKey_MT
Daughter_Table
PrimaryKey_DT
ForeignKey_MT
Imported_ForeignKey_MT

La relation normale est : PrimaryKey_MT -> ForeignKey_MT
Je ne sais pas si c’est possible d’établir une deuxième relation Imported_PrimaryKey_MT -> Imported_ForeignKey_MT sachant que pour la majorité des enregistrements ces champs seront NULL et que pour les enregistrements importés il n’y aura dans un premier temps aucun enregistrement correspondant dans la table mère à ceux de la table fille via cette relation. Est-ce que postgreSQL tolère ça ou est-ce qu’il y a une contrainte ?
Ça simplifierait les choses car pour mon importation je procèderais ainsi :

1. J’importe tous les enregistrements de toutes les tables.
2. Une procédure parcourt tous les nouveaux enregistrements de la table fille.
3. Pour chacun selon la relation Imported_PrimaryKey_MT -> Imported_ForeignKey_MT elle copie la PrimaryKey_MT de la table mère et la colle dans ForeignKey_MT. La relation normale est donc établie.
4. La procédure efface les Imported_PrimaryKey_MT et les Imported_ForeignKey_MT et donc cette relation n’existe plus (je suppose qu’il n’y a pas de relation de NULL à NULL.

Je suis sûr ainsi de ne pas introduire de gremlin dans ma base.
Nico

[polo974]

... Bonjour la galère et peut-être les dégâts.

Pas plus la galère que de devoir parcourir les tables secondaires pour mettre à jour la foreign.

Et comme j’aurai l’occasion de répéter la manip ça deviendra ingérable. ...

Répéter une seule fois sur plusieurs tables ou répéter pour divers "imports massifs" dans la même table?

La gestion des foreign key "à postériori" n'est pas simple non plus lors de l'import.

Pour revenir à la clé primaire auto-icrémentée
le AUTO_INCREMENT ne semble pas exister dans postgresql, mais il y a la directive IDENTITY, genre (je continue à torturer ma base de test):

alter table table_one add column id_one bigint GENERATED BY DEFAULT AS IDENTITY;

ensuite, il faut (aussi) la rendre pk ou unique. mais attention, ça crée une séquence et elle peut être manipulée à souhait, tout comme on peut faire des inserts avec une valeur spécifique qui pourra provoquer un futur pb d'unicité...

(je n'ai pas essayé le GENERATED ALWAYS AS IDENTITY ...)

bref, (adapter les noms):

select setval('serial_one', (select max(pkey_one) from table_one));

permet toujours de positionner la séquence au-delà des valeurs déjà existantes dans la table...

maintenant, je suis très loin d'être un architecte de base de données...

[saint.112]

Il y a un bug dans le forum : plus moyen de passer à la ligne.

[saint.112]

Répéter une seule fois sur plusieurs tables ou répéter pour divers "imports massifs" dans la même table?

Dans l’exemple que j’ai donné dans le message #35

Title	Time	Composer	Performers	Album
Roadhouse Blues	4:06	Jim Morrison, The Doors	Jim Morrison, v; Ray Manzarek, kbrd; Robby Krieger, g; G. Puglese (John Sebastian), harm; Lonnie Mack, b; John Densmore, d	Morrison Hotel

il faut ventiler ces données dans 4 tables principales plus 4 tables intermédiaires de relation.

La gestion des foreign key "à postériori" n'est pas simple non plus lors de l'import.

C’est bien une des raisons pour laquelle je ne veux pas y toucher.

Pour revenir à la clé primaire auto-icrémentée
le AUTO_INCREMENT ne semble pas exister dans postgresql, mais il y a la directive IDENTITY, genre (je continue à torturer ma base de test):

alter table table_one add column id_one bigint GENERATED BY DEFAULT AS IDENTITY;

Quand j’ai écrit mon code je croyais suivre la syntaxe standard de SQL. Mais là, j’ai à peine commencé à programmer avec SQL, que je me retrouve dans une situation catastrophique : j’ai passé plusieurs heures à tenter de savoir quel "statement" écrire pour une clé primaire dans Postgre. En regardant sur le site de formation w3schools on trouve cette page : SQL AUTO INCREMENT Field où l’on voit ces syntaxes diverses et variées selon les éditeurs :

1. Syntax for MySQL
   Personid int AUTO_INCREMENT PRIMARY KEY,
2. Syntax for SQL Server
   Personid int IDENTITY(1,1) PRIMARY KEY,
3. Syntax for MS Access
   Personid AUTOINCREMENT PRIMARY KEY,
4. Syntax for Oracle
   CREATE SEQUENCE seq_person
   MINVALUE 1
   START WITH 1
   INCREMENT BY 1
   CACHE 10;

Mais il n’est pas question de PostgreSQL. Pour ça je suis allé à la source dans PostgreSQL 18.4 Documentation, paragraphe 8.1.4. Serial Types, page 154. Mais je ne suis pas sûr de bien tout comprendre. Ça me parait vachement alambiqué.
J’ai encore trouvé autre chose dans des tutoriaux sur YouTube :
id bigserial,
ou
id integer NOT NULL DEFAULT nextval (‘bookmarks_id_seq’::regclass) ,

À quoi ça sert que l’ISO se décarcasse à édicter des normes si les différents éditeurs de SGBD n’en tiennent pas compte et n’en font qu’à leur tête. Et l’on dit que le code SQL est portable d’un SBGD à un autre ! Mon genou, oui ! Et ça commence dès la première ligne !
La ligne que j’avais tapée :
"PK_Artist" longint PRIMARY KEY AUTO_INCREMENT UNIQUE CREATE INDEX "Ind_PK_Artist",
est sans doute trop simple car selon le principe Shadock « Pourquoi se compliquer la vie à faire simple alors qu’il est si simple de faire compliqué »

Bon, ceci dit, je n’ai pas de temps à perdre avec ces idiosyncrasies et ça me conforte dans mon projet d’utiliser un Database Modeler qui me mâchera le code à ma place, du moins je l’espère.

Pour en revenir à la question de l’import de données, jetbrains a une fonction Import/Export mais je ne l’ai pas encore explorée. Là aussi je n’ai pas envie de me prendre la tête avec des trucs qui ici sont comme ceci et là comme cela. J’espère qu’il est capable de me mâcher le travail sinon ça va être la galère. Il y a aussi l’IA a explorer.

Nico

[Ikhar84]

Personne de sérieux ne dirait qu'un code SQL est strictement portable... on parle même de "dialectes" SQL par "vendeur".

Dans le temps, le SQL était l'étape final, on passait par d'autres notations/notions avant (modèle relationnel, algèbre relationnel, calcul relationnel) puis il suffisait de traduire dans le bon dialecte ...

Ceci dit en passant, Postgre (qui est perso dans mon top 2) est loin d'être le plus accessible pour un débutant..
MySQL/MariaDB restent bien plus accessibles, amha...
Je comprends même pas pourquoi tu as fait ce choix ?
Dans le cas d'une appli "locale" mononutilisateur, même SQLite reste un choix très correct et très facile d'accès...

[saint.112]

Personne de sérieux ne dirait qu'un code SQL est strictement portable... on parle même de "dialectes" SQL par "vendeur".

Ça va même plus loin puisque j'ai vu que Microsoft propose un utilitaire pour convertir les bases créées avec Access vers SQL Server. Donc chez un même vendeur les SGBD ne parlent pas la même langue.

Dans le temps, le SQL était l'étape final, on passait par d'autres notations/notions avant (modèle relationnel, algèbre relationnel, calcul relationnel) puis il suffisait de traduire dans le bon dialecte ...

Donc l'établissement de normes n'a pas vraiment réussi. Il devrait y avoir un comité qui attribue le label SQL à ceux qui respectent les normes.
Qu'est-ce ça couterait à Postgre d'appliquer la syntaxe SQL auto_increment ?

Ceci dit en passant, Postgre (qui est perso dans mon top 2) est loin d'être le plus accessible pour un débutant..
MySQL/MariaDB restent bien plus accessibles, amha...
Je comprends même pas pourquoi tu as fait ce choix ?

Je suis débutant en SQL mais je touche assez bien ma bille en bases de données relationnelles. J'ai utilisé Quatrième Dimenssion (4D). J'ai fait des bases qui tournaient très bien avec une interface utilisateur très sympa.
Pour le développement je vais utiliser extensivement un ou plusieurs database modelers et le plus possible l'IA. Ça m'évitera de me prendre la tête avec les singularités imbéciles de ce différents softs.
Le plus dur à mon sens est de concevoir sa modélisation, donc de faire l'analyse de ses données. Pour mon projet c'est déjà fait et elle a fait ses preuves dans une base qui marchait parfaitement. Après ça, l'implémentation dans un SGBD particulier est ou devrait être un simple problème d'exécution. Tout ce que j'ai vu comme présentation ou comme tutoriaux sur Postgre était pour moi un terrain connu, bien souvent au ras des pâquerettes, si je fais abstraction du langage de programmation spécifique avec lequel je ne suis pas vraiment familier.

Nico

[polo974]

Bon, si tu pars sur le 'AS IDENTITY' de postgresql (ici, c'est un alter, mais ça peut être défini dès la création de table).

alter table table_one add column id_one bigint GENERATED BY DEFAULT AS IDENTITY;

Tu injectes tes anciennes données en gardant les même clés (qui sont normalement ok)
Puis tu modifies la valeur de la séquence (dont on ne connaît pas le nom) à une valeur supérieure au max des id injectés en y accédant à travers la colonne de la table:

ALTER TABLE table_one ALTER id_one restart 6666;

à faire une fois pour chaque table dont la clé primaire est une séquence dont on a récupéré le valeurs.

Bref, tu peux intégrer tes anciennes données avec leurs clés, puis mettre à jour la séquence pour ne pas avoir de conflit. Tes clés étrangères n'ont pas à être modifiées, vu que les clés primaires de la table principale n'ont pas été modifiées.

Ensuite (après l'import massif initial), tu insères sans même t'occuper de la valeur à mettre dans la colonne. Bref, je ne vois pas plus simple.

Pour ton exemple donné dans le message #35 où il faut ventiler ces données dans 4 tables principales plus 4 tables intermédiaires de relation, quelle que soit la façon d'importer la "vieille" base, le travail reste le même.

[saint.112]

Bon, si tu pars sur le 'AS IDENTITY' de postgresql (ici, c'est un alter, mais ça peut être défini dès la création de table).

alter table table_one add column id_one bigint GENERATED BY DEFAULT AS IDENTITY;

Tu injectes tes anciennes données en gardant les même clés (qui sont normalement ok)
Puis tu modifies la valeur de la séquence (dont on ne connaît pas le nom) à une valeur supérieure au max des id injectés en y accédant à travers la colonne de la table:

ALTER TABLE table_one ALTER id_one restart 6666;

à faire une fois pour chaque table dont la clé primaire est une séquence dont on a récupéré le valeurs.

C'est en effet une option.

Pour ton exemple donné dans le message #35 où il faut ventiler ces données dans 4 tables principales plus 4 tables intermédiaires de relation, quelle que soit la façon d'importer la "vieille" base, le travail reste le même.

Ça demandera évidemment un travail en amont : ventiler les données dans différents fichiers TSV correspondant aux tables cibles. À moins qu'une IA trouve le moyen de mouliner tout ça manuellement pendant que je reste sur le sofa à manger des loukoums.

[saint.112]

Je viens de regarder ce que jetbrains propose pour l'import dans la page Import/Export options. Il ne s'agit que de l'import d'une table et il n'y a rien de prévu pour une base complète. Manifestement il importe les clés primaires à partir du fichier. Rien ne dit quelles contraintes il y a sur cette clé.
Je demanderai à une IA de me concocter une solution.
Ce qui me surprend c'est que le problème doit se poser : pour une entreprise qui remplace sa vieille base de données non conforme à SQL doit bien trouver un moyen de transférer les données dans la nouvelle.

[pm42]

pour une entreprise qui remplace sa vieille base de données non conforme à SQL doit bien trouver un moyen de transférer les données dans la nouvelle.

Cela s'appelle un projet et pour un des clients, l'évaluation était en millers de jours/homme. Ce n'est pas le transfert des données qui pose problème mais tout ce qui utilise des spécificités.
Le SQL "standard" supporté par toutes les bases existe mais il ne permet pas de faire grand chose. Donc chaque base a ses types de données, triggers, procédures stockées (ou pas), functions diverses et j'en oublie comme les niveaux de lock, gestion des rollback, checkpoints.
Et je ne parle même pas de l'optimisation des pers.

Bref, la solution standard est de passer par une librairie qui abstrait tout ça, quand on fait de l'objet cela s'appelle un ORM, en Python, le plus utilisé est SQLAlchemy.

Et on ne charge pas les données à la main comme tu veux le faire : on écrit le code qui lit les entrées et utilise le dit ORM pour le faire. Cela marche très bien sauf pour les énormes volumes.

[saint.112]

Cela s'appelle un projet et pour un des clients, l'évaluation était en millers de jours/homme. Ce n'est pas le transfert des données qui pose problème mais tout ce qui utilise des spécificités.
Le SQL "standard" supporté par toutes les bases existe mais il ne permet pas de faire grand chose. Donc chaque base a ses types de données, triggers, procédures stockées (ou pas), functions diverses et j'en oublie comme les niveaux de lock, gestion des rollback, checkpoints.
Et je ne parle même pas de l'optimisation des pers.

J’imagine qu’un système de gestion complexe d’une grande entreprise doit être difficilement transférable. Mais mon problème est beaucoup plus terre à terre : il s’agit du transfert des seules données, sachant qu’il s’agit d’une base de données relationnelle et donc que, pour que les relations viennent avec, il faut que les clés primaires étrangères règnent. À part ça je n’ai pas de problème de traitement complexe des données comme c’est le cas dans un programme de gestion.
Ce que je voudrais reproduire c’est tout ce qui concerne la présentation, c’est-à-dire essentiellement les formulaires, les aides à la saisie et à l’intégration des données, les recherches, etc. Mais là il ne faut pas songer extraire quoi que ce soit de tel d’une base FileMaker Pro. C’est à refaire de zéro.

Et on ne charge pas les données à la main comme tu veux le faire : on écrit le code qui lit les entrées et utilise le dit ORM pour le faire. Cela marche très bien sauf pour les énormes volumes.

J’ai bien l’intention d’écrire une procédure pour automatiser la manip, ou plutôt de demander à une IA de le faire pour moi. Le problème qui se pose à moi est la stratégie à adopter. J’en vois deux et ma question était de savoir s’il n’y en a pas de meilleure et si par hasard il n’existerait pas une librairie toute prête pour ça.
Pour chaque table de la base FMP les données brutes sont dans un fichier texte tabulé (TSV) avec en première ligne les noms des colonnes. Chaque fichier a le même nom que la table correspondante dans la base cible et chaque en-tête de colonne a le même nom que la colonne correspondante. Je peux même les mettre dans le même ordre. Ceci est surtout pour que je ne m’emmêle pas les crayons.

1. Première stratégie brutale.
   On importe tout tel que table par table, clés primaires et étrangères. Je l’ai déjà tentée avec 4D : il ne tolère pas qu’on vienne mettre le souk dans une colonne auto-incrémentée et avec la contrainte unique. Je le comprends. Donc la manip échoue.
   Il faudrait désactiver provisoirement la contrainte. Mais alors il faut ensuite penser à la remettre et changer la valeur de départ de l’incrémentation. Bonjour la galère pour plus d’une douzaine de tables, les risques d’erreur, etc.
2. Deuxième stratégie.
   Comme je l’ai montré dans le message #32, pour une base schématique comme celle-ci.
   • Mother_Table
     PrimaryKey_MT
     Daughter_Table
     PrimaryKey_DT
     ForeignKey_MT
     La relation se fait de PrimaryKey_MT à ForeignKey_MT.
   • J’ajoute à chaque table une colonne pour importer les clés :
     Mother_Table
     PrimaryKey_MT
     Imported_PrimaryKey_MT
     Daughter_Table
     PrimaryKey_DT
     ForeignKey_MT
     Imported_ForeignKey_MT

Une fois l’import terminé il y a là aussi deux stratégies possibles :

1. Pour chaque enregistrement de la table fille on cherche l’enregistrement de la table mère tel que Imported_PrimaryKey_MT = Imported_ForeignKey_MT, on copie PrimaryKey_MT et on le colle dans ForeignKey_MT. And voilà, comme disent les Américains, la relation est rétablie. On termine par un petit ménage : on donne aux deux colonnes Imported la valeur NULL.
2. La chose serait sans doute plus simple si l’on pouvait établir une relation Imported_PrimaryKey_MT -> Imported_ForeignKey_MT mais je ne sais pas dans quelle mesure ce serait toléré puisque Imported_PrimaryKey_MT n’est pas une clé primaire.
   Un fois le job terminé, plus que pour la première stratégie un ménage s’impose.

Voilà où en sont mes réflexions. Mais y a-t-il d’autres méthodes ?

Nico

[polo974]

Ta stratégie 1 peut fonctionner avec posgresql POUR UNE SEULE INJECTION MASSIVE PAR TABLE. Il faut juste ajuster la séquence cachée à une valeur > au max de la pk.
Donc une injection, un update par table concernée.

Ta stratégie 2 est plus lourde en pré et post-traitement, oublie...

La stratégie 3 proposée par pm42 est plus clean et ne met pas en œuvre 2 méthodes différentes entre l'import massif initial et l'ajout au coup par coup d'une performance musicale. Passer par SQLAlchemy (ou autre) te permet en plus de faire abstraction des coulisses du dialecte sql. Mais j'avoue ne jamais avoir utilisé (je m'occupais plus des IO et du rattrapage de (parfois grosses) boulettes

Bon, sinon, j'ai du mal à voir l'intérêt d'une pk autogénérée, surtout quand sa valeur doit servir en fk, comment la récupérer à coup sûr ? Il faut bien une unicité dans les données à ce moment... Mais comme déjà dit, moi les bdd, c'est pas mon kif suprême, je fais (essaye de faire) avec quand il y en besoin, point barre...

[pm42]

La stratégie 3 proposée par pm42 est plus clean et ne met pas en œuvre 2 méthodes différentes entre l'import massif initial et l'ajout au coup par coup d'une performance musicale. Passer par SQLAlchemy (ou autre) te permet en plus de faire abstraction des coulisses du dialecte sql.

Je dois dire qu'à l'époque de Claude Code qui m'écrit un petit soft web complet en 15 min, un complet en 3h, et de toutes les technologies actuelles, je dois reconnaître que avec tout le respect que je dois à saint.112 que j'ai l'impression de le voir faire du feu avec des silex, c'est à dire essayer de régler des problèmes avec des moyens plus que dépassés.

[saint.112]

Ta stratégie 1 peut fonctionner avec posgresql POUR UNE SEULE INJECTION MASSIVE PAR TABLE. Il faut juste ajuster la séquence cachée à une valeur > au max de la pk.
Donc une injection, un update par table concernée.

Mais je voudrais pouvoir en faire autant que je veux quand je veux.

Ta stratégie 2 est plus lourde en pré et post-traitement, oublie.

L’expérience m’a appris qu’on a parfois intérêt à faire un peu lourd mais sûr et reproductible dans différentes circonstances. Surtout ce que je veux c’est une routine où en gros je clique sur bouton et elle effectue le boulot sans que j’aie à intervenir. Je ne veux pas avoir à mettre les mains dans le cambouis, quitte à me faire suer un peu plus pour la programmation. C’est d’autant plus vrai si je donne la base à un néophyte.

La stratégie 3 proposée par pm42 est plus clean et ne met pas en œuvre 2 méthodes différentes entre l'import massif initial et l'ajout au coup par coup d'une performance musicale. Passer par SQLAlchemy (ou autre) te permet en plus de faire abstraction des coulisses du dialecte sql.

Je ne vois pas quelle méthode propose pm42. Je n’ai rien vu dans SQLAlchemy pour mon problème.

Bon, sinon, j'ai du mal à voir l'intérêt d'une pk autogénérée, surtout quand sa valeur doit servir en fk, comment la récupérer à coup sûr ? Il faut bien une unicité dans les données à ce moment.

Je ne comprends pas, sois plus explicite.

Dans ma base les clés primaires de toutes les tables sont auto incrémentées de façon automatique.
Pour l’entrée manuelle des données, quand je suis dans la table Artistes par exemple, pour créer la fiche d’une nouvelle œuvre d’un artiste donné je clique sur le bouton Nouvelle œuvre et l’algorithme crée un nouvel enregistrement dans la table Œuvres et un autre dans la table intermédiaire Créer dans laquelle il attribue aux deux clés étrangères les valeurs des clés primaires des enregistrements concernés de Œuvres et de Artistes. Il utilise pour ça des variables. Le lien est donc établi et je me retrouve dans le formulaire de saisie de Œuvres. Je peux inversement aller d’abord dans le formulaire de saisie de Œuvres et soit choisir un ou plusieurs artiste(s) dans un menu déroulant s’ils sont déjà enregistrés dans la base, soit cliquer sur le bouton Nouvel auteur qui me renvoie dans la table Artistes dans le formulaire de saisie pour créer un nouvel enregistrement. Au passage, comme pour la première manip, l’algorithme a créé un nouvel enregistrement dans la table Créer et a attribué les valeurs qui vont bien aux clés étrangères. Ça ne marche que si les clés primaires sont générées automatiquement, ou alors il faudrait programmer ça.
Ça me parait tout à fait banal.
Pour les interprétations c’est encore mieux : il y a une table intermédiaire Jouer faisant des relations tripartites entre les tables Artistes, Interprétations et Formations. Sans compter que cette table Jouer entretient des relations avec elle-même pour déterminer les rôles des différents artistes (chef, instrumentiste, soliste, (etc.), leur appartenance à une formation, etc. Elle possède donc 12 clés étrangères. Ça marche nickel.

Ceci dit, mon plan est d’établir la structure de ma base, puis de faire mon cahier des charges et de le donner à une IA et de lui dire « Demerden sie sich ».

Par parenthèse, j’ai appris il y a peu que certains programmeurs recommandent de mettre les noms des tables au singulier plutôt qu’au pluriel. Je les ai toujours mis au pluriel pour les entités et généralement un verbe pour les tables intermédiaires. Je ne vois ce que ça change.

[saint.112]

Je dois dire qu'à l'époque de Claude Code qui m'écrit un petit soft web complet en 15 min, un complet en 3h, et de toutes les technologies actuelles, je dois reconnaître que avec tout le respect que je dois à saint.112 que j'ai l'impression de le voir faire du feu avec des silex, c'est à dire essayer de régler des problèmes avec des moyens plus que dépassés.

Serais-tu en train d’insinuer que je me creuse trop la tête pour rien et que je devrais plus me reposer sur l’IA ?
Le fait est que je mesure mal ce que je peux lui laisser faire par rapport à ce que j’ai à lui dicter.
En fait j’ai plusieurs contraintes.

• Si je créais une base à partir de rien je pencherais pour laisser à l’IA la bride sur le cou. Mais j’ai une base dont la structure et l’interface utilisateur me donnaient entière satisfaction. J’ai envie de retrouver quelque chose d’assez similaire.
  
• Mais surtout j’ai pas mal de données à réimporter, lesquelles sont actuellement enregistrées dans des fichiers texte tabulés qui dépendent entièrement de la structure de la base d’origine avec les clés primaires et étrangères. À tort ou à raison, pour pouvoir importer ces données, il me semble que je dois reproduire cette structure dans ma nouvelle base, avec peut-être quelques ajustements.

De quels moyens dépassés tu parles ? Si c’est pour l’importation de données je suis tout ouie si l’on me propose un moyen simple et efficace. Mais n’y a-t-il pas de procédure toute faite pour réimporter les données d’une base dans l’autre ?

À part ça j'ai entendu parler d'une IA qu'on installe sur son ordi : Locally IA. Vous connaissez ?


Nico

[pm42]

Serais-tu en train d’insinuer que je me creuse trop la tête pour rien et que je devrais plus me reposer sur l’IA ?

Je n'insinue pas mais ce n'est pas non plus un reproche.
Beaucoup de programmeurs actuels actifs et d'entreprises ne l'utilisent pas à sa pleine puissance et de très loin. Certains regardent même en se demandant si cela sert à quelque chose.

D'un coté, je comprends parfaitement que tu veuilles maitriser ce que tu fais, que tu repartes de ce que tu connais. C'est normal et c'est même très sain.
Je dis juste que tu vas passer beaucoup de temps à régler des problèmes triviaux au lieu de te concentrer sur ton projet.
Si tu as envie de faire cela parce que tu te dis que tu apprends, que c'est un hobby, très bien.

Je te dis juste que si ce n'est pas le cas, il y a plus efficace.

Le fait est que je mesure mal ce que je peux lui laisser faire par rapport à ce que j’ai à lui dicter.

Elle peut tout faire mais curieusement, il faut savoir s'en servir pour lui laisser tout faire

[*]Si je créais une base à partir de rien je pencherais pour laisser à l’IA la bride sur le cou. Mais j’ai une base dont la structure et l’interface utilisateur me donnaient entière satisfaction. J’ai envie de retrouver quelque chose d’assez similaire.

C'est parfaitement compréhensible. A titre perso, j'utilise Claude Code donc dans des cas comme ça, on lui donne le répertoire du projet existant et on lui dit ce qu'on souhaite (20$/mois).
L'idéal est bien sur d'avoir fait une copie avant ou mieux d'avoir un outil de gestion de version comme git. Si tu n'as pas, tu lui dis "je veux un repository git local" et il va le faire.
Mais la différence de fond, c'est que c'est un agent : il va de lui même lire ton code et tout ce que tu as, écrire, tester, lancer, etc.
Et te poser des questions.

[*]Mais surtout j’ai pas mal de données à réimporter, lesquelles sont actuellement enregistrées dans des fichiers texte tabulés qui dépendent entièrement de la structure de la base d’origine avec les clés primaires et étrangères. À tort ou à raison, pour pouvoir importer ces données, il me semble que je dois reproduire cette structure dans ma nouvelle base, avec peut-être quelques ajustements.

Pas forcément pour la reproduction.

De quels moyens dépassés tu parles ? Si c’est pour l’importation de données je suis tout ouie si l’on me propose un moyen simple et efficace. Mais n’y a-t-il pas de procédure toute faite pour réimporter les données d’une base dans l’autre ?

Ce que je trouve dépassé, c'est de travailler au niveau SQL quand on n'a pas de grosses masses de données. Comme je disais, lire des fichiers textes tabulés, Python fait ça en dormant.
Ensuite, on les met dans des classes et on demande à SQLAlchemy de sauver en base : il va se débrouiller tout seul pour les clés primaires, foreign key, etc.

Mais c'est aussi lié à ma façon de travailler : je ne défini en général pas la base à l'avance mais les classes dans le langage dans lequel je travaille. Puis on en déduit les tables et c'est l'ORM (SQLAlchemy) ou autre qui fait le travail de lire/écrire.

À part ça j'ai entendu parler d'une IA qu'on installe sur son ordi : Locally IA. Vous connaissez ?

Il y en a plein. Sauf à avoir beaucoup de matériel très cher, c'est très lent et cela ne fait tourner que des modèles très simples et peu performants.

P.S : pour ce qui est de l'utilisation de l'IA, voici le genre de chose toute simple qu'on peut faire.
Dans ChatGPT (ou autre de bon niveau), j'ai demandé :

Peux tu lire https://forums.futura-sciences.com/p...d-macos-2.html ainsi que la page 1 et me donner une réponse pour ses questions sur l'import des données ?

Ce qui donne :

Je n’ai pas pu ouvrir proprement la page Futura complète, mais les extraits visibles indiquent qu’il demande comment importer sans gérer à la main les clés générées. Réponse que je lui donnerais :

Le bon schéma est de ne pas importer directement dans les tables finales quand les clés primaires sont auto-générées et servent ensuite de foreign keys.

Il faut faire en 2 temps :

1. Importer les fichiers bruts dans des tables temporaires/staging, avec les identifiants d’origine ou des clés métier lisibles : code, nom unique, référence externe, date+libellé, etc.
2. Insérer ensuite dans les vraies tables dans l’ordre logique, en récupérant les nouveaux identifiants générés, puis en reconstruisant les foreign keys par jointure.

Exemple conceptuel :
-- table temporaire importée depuis CSV
stg_lignes(id_origine_client, nom_client, id_origine_commande, montant)

-- insertion des clients
INSERT INTO client(nom)
SELECT DISTINCT nom_client
FROM stg_lignes;

-- insertion des commandes avec jointure vers les nouveaux ids
INSERT INTO commande(client_id, montant)
SELECT c.id, s.montant
FROM stg_lignes s
JOIN client c ON c.nom = s.nom_client;

Donc il faut conserver pendant l’import une clé naturelle ou ancienne clé source permettant de faire la correspondance. Les clés auto-générées ne sont pas un problème si on ne les utilise qu’après coup.

Avec PostgreSQL, COPY FROM est adapté pour charger rapidement des CSV dans des tables staging . Les foreign keys imposent que la valeur référencée existe déjà dans la table parent, ce qui explique le problème “œuf et poule” .

Pour un volume modéré et avec SQLAlchemy, c’est encore plus simple : créer les objets parents, faire un flush() pour obtenir leurs ids, puis créer les enfants avec les relations ORM. L’ORM sait gérer l’ordre d’insertion quand les relations sont correctement définies ; les cas circulaires restent spéciaux .

Donc ma recommandation : PostgreSQL + DBeaver/pgAdmin + scripts Python/SQLAlchemy, pas besoin d’un outil lourd. Pour un import ponctuel : staging CSV + SQL. Pour un import répété : petit script Python reproductible.

Normalement, je ne fais pas du copier/coller d'échange avec l'IA mais là, c'est juste pour te montrer, même pas besoin de faire du copier/coller, de te poser des questions, tu as déjà donné l'info ici et normalement, elles peuvent lire.

Un agent ira même plus loin, il pourrait poster à ta place
Si tu fais ça, je fais un agent pour te répondre

[saint.112]

Je vois que tu te fais du souci du fait que je risque de me casser le dos au travail. C’est bien connu « Le travail ça fatigue, ça salit et ça déshonore¹. » J’ai acheté mon premier ordi en 1987, un Mac 512 (d’où mon pseudo), et j’ai tout de suite compris que l’informatique ne pouvait qu’inciter à la paresse. Enfin un véritable esclave pour faire le travail, ou du moins une partie, à notre place. Et je n’ai pas été déçu par ces quatre dernières décennies d’évolution de l’informatique. Donc, oui, l’IA est tout à fait pour moi. Je vais l’utiliser à mort.
Mais dans le cas particulier je veux qu’elle comprenne parfaitement le type de base documentaire que je veux faire. Or l’approche de l’écrasante majorité des gens sur ce terrain est focalisée avant tout sur trois éléments : l’artiste, la chanson et l’album. Par défaut la chanson appartient à l’artiste. On a par exemple Taylor Swift qui chante Bad Blood dans son premier album 1989. Le reste n’a guère d’importance : qui l’accompagne, où et quand ça a été enregistré, etc. Les auteurs et compositeurs sont des paramètres secondaires. C’est le point de vue de la pop. C’est tout à fait évident dans iTunes, le player d’Apple.
Je crains donc que toute AI ait ce même point de vue.J’ai vu des exemples de bases de données pédagogiques qui avaient exactement cette approche aussi.

Comme j’aime des musiques de styles très différents je me suis évertué à faire une base absolument tout terrain qui puisse gérer n’importe quel type de pratique de la musique : baroque, classique, jazz, blues, rock, indienne, etc.
Contrairement à la majorité des gens, pour qui l’album est une entité majeure, pour moi l’album est une entité secondaire, ce n’est qu’un support. La notion de “chanson“ est réductrice, de façon générique ça devrait d’ailleurs s’appeler plage. Dans un opéra ou un symphonie c’est un morceau ou un mouvement mais pas une œuvre. Une autre entité importante est l’interprétation : je peux en avoir plusieurs différentes de certaines cantates de Bach par exemple. C’est aussi une entité en soi.
Ce que je crains si je dis à l’IA « Conçois-moi une base documentaire pour gérer ma discothèque. » c’est qu’il adopte par défaut le point de vue de la pop. Ou alors il faudrait que je lui explique de long en large ce que je veux et alors j’aurai plus vite fait de créer moi-même la base de données. Je lui laisserai le soin de créer le programme de gestion de la chose.
De plus, comme je veux récupérer les données j’ai besoin de faire une base qui soit en quelque sorte un miroir de mon ancienne base.

Concernant la réponse de l’IA à mon problème d’importation je dois dire que je n’ai pas tout compris. Il y a des termes et des signes que je ne connais pas. Elle ne précise pas de quelle table elle parle.

Le bon schéma est de ne pas importer directement dans les tables finales quand les clés primaires sont auto-générées et servent ensuite de foreign keys.

Bon, là on est d’accord : il ne faut pas faire d’import dans la clé primaire. Sa solution et la mienne ont un point commun : récupérer la clé primaire auto-incrémentée de la table mère pour l’entrer dans la clé étrangère de la table fille. Là où on diffère c’est que crée une colonne spécifique dans les deux tables et elle crée des tables spécifiques. La question qui se pose donc est : quel est la solution la moins couteuse en terme d’espace disque et de requête. Avec la mienne on a une colonne surnuméraire dans chaque table. Avec la sienne on des tables surnuméraires sachant qu’on efface les enregistrements importés une fois l’opération terminée. Mais surtout le problème est que cette table temporaire correspondant à la table mère aura sa propre clé étrangère auto-incrémentée qui doit devenir l’identifiant de relation dans la table principale. J’ai du mal à voir comment ça se goupille.
Je reprends mon exemple. J’ai mes deux tables normales :
Mother_Table
PrimaryKey_MT
Daughter_Table
PrimaryKey_DT
ForeignKey_MT

Je crée deux tables temporaires :

Mother_Temp_Table
PrimaryKey_M_TempT
Imported_PrimaryKey_MT
Daughter_Temp_Table
PrimaryKey_D_TempT
ForeignKey_MT
Imported_ForeignKey_MT

À moins que je me plante sur ce schéma, quand j’aurai rempli mes tables temporaires j’aurai la PrimaryKey_M_TempT, l’identifiant de la table mère temporaire, or ce qu’il me faut c’est le futur identifiant de la table mère principale alors que l’enregistrement correspondant n’existe pas encore.

1. Importer les fichiers bruts dans des tables temporaires/staging, avec les identifiants d’origine ou des clés métier lisibles : code, nom unique, référence externe, date+libellé, etc.
2. Insérer ensuite dans les vraies tables dans l’ordre logique, en récupérant les nouveaux identifiants générés, puis en reconstruisant les foreign keys par jointure.

Je mets en gras les mots que je ne comprends pas.
Si je comprends bien le point 2 il s’agit d’entrer dans la nouvelle clé étrangère de la table fille les nouveaux identifiants correspondants de la table mère. La procédure qui suit n’est pas claire du tout pour moi.

Ce qu’elle ne dit c’est comment on cherche ces nouveaux identifiants. Ça consiste donc à faire peu ou prou la même chose par une méthode que je trouve plus compliquée.

Nico

1) Ainsi s’exprimait Louis Jouvet dans « La charrette fantôme », un film de Julien Duvivier en 1939.

[pm42]

Je comprends tes questions mais si tu veux que l'IA fasse ce que tu veux, tu lui dis très exactement ça.
En gros, tu engages avec elle le même dialogue, tu n'essaie surtout pas de "prompter".

Les IAs actuelles ont leurs limites et défaut mais elles ont atteint un point où leur parler comme à un collègue, leur donner de l'information précise sur ce qu'on veut à haut niveau est très efficace.

Et surtout, tu ne lui demandes pas de coder tout de suite. Tu lui demandes si elle a bien compris, de te proposer un plan et éventuellement plusieurs solutions et tu lui dis ce sur quoi tu es d'accord, ce qui ne colle pas, tu poses des questions.

Quand le plan est prêt, tu lui dis que c'est ok et qu'on peut commencer à coder. Et tu restes dans cette session.
Si elle dérive, tu précises et demande une correction.

Si je n'était pas déjà en train de faire avancer je ne sais plus combien de projets avec d'autres en retard, je te ferais un proto vite fait mais là, la bande passante de mon cerveau est à sa limite.

[vgondr98]

Voila le genre de discussion qu'on peut avoir avec une IA :

1. Validation de sa vision (Le modèle "Tout Terrain")
Nico a parfaitement raison de rejeter le modèle standard des plateformes grand public (Artiste ➔ Album ➔ Chanson), qu'il qualifie à juste titre de vision réductrice de la "pop". Pour les musiques complexes (classique, jazz, blues, musiques indiennes), ce système est incapable de gérer les œuvres à interprétations multiples ou les contributeurs multiples (compositeurs vs interprètes vs chefs d'orchestre).

2. La fin du travail fastidieux : L'automatisation par API
Le plus grand risque du modèle de Nico était la lourdeur de la saisie manuelle. Nous avons trouvé et testé la solution ultime pour un "paresseux informatique" : L'API gratuite de Discogs.

Le test concret : Nous avons généré un Token de sécurité et interrogé directement l'API avec le code-barres de l'album Kind of Blue de Miles Davis.

Le résultat : L'API renvoie un fichier texte ultra-complet contenant déjà l'album, toutes les œuvres, les durées des plages et la liste de tous les musiciens (avec leurs rôles précis : piano, trompette, etc.) ainsi que le lieu et la date d'enregistrement.

Voila les url testés :
https://api.discogs.com/database/sea...26&token=TOKEN

https://api.discogs.com/releases/24342800?token=TOKEN

https://api.discogs.com/releases/34939976?token=TOKEN

Voila le lien pour générer le token : https://www.discogs.com/fr/settings/developers

Il faut juste se créer un compte avant sur https://www.discogs.com/fr/

L'api renvoie un json bien velu

[saint.112]

Je comprends tes questions mais si tu veux que l'IA fasse ce que tu veux, tu lui dis très exactement ça.
En gros, tu engages avec elle le même dialogue, tu n'essaie surtout pas de "prompter".

OK. Mon plan est le suivant :

1. Je crée ma base. Je la documente précisément. Par parenthèse, comment fait-on pour documenter un code SQL ?
2. J’exporte le schéma et le code dans un document .pdf. Il y a des SQL modeler qui font ça très bien. Je suppose que pour communiquer avec l’IA le plus commode est avec des .pdf, non ?
3. J’expose les grandes lignes de ce que je veux comme interface utilisateur : les formulaires d’entrée des données, les formulaires de présentation, les formulaires de recherches complexes, etc. Je joins les copies d’écran de ma base pour illustrer mon propos.
4. Je lui demande ce qu’elle en pense mais peut-être de ne pas coder tout de suite, que nous discutions des orientations du programme.
5. Je lui demande de ne pas coder tout de suite mais de me faire des propositions sous forme d’avant-projet sommaire.

J’attends sa réponse. Selon ce qu’elle me dit :

1. J’analyse ses propositions.
2. Selon les cas je les amendes.
3. Je suis précis sur les spécifications de mon programme.

On avance donc par incréments.


À part ça, j’ai eu une intuition hier soir en cherchant le sommeil à propos du problème de l’importation de données.
Je reviens d’abord sur les avantages et les inconvénients de ce que nous avons vu :

1. La solution de polo974
   Elle consiste à importer toutes les données des tables, clés primaires comprises.
   Inconvénient relevé par moi et par l’IA : pas touche aux clés primaires, point barre.
2. La solution que je proposais initialement.
   Les données sont importées dans leurs colonnes respectives et les clés primaires et secondaires sont importées dans des colonnes idoines, une par table.
   • Avantages :
     Elle n’a pas l’inconvénient de la première.
     Elle permet une importation très facile des données.
   • Inconvénients :
     Cela demande une procédure peut-être un peu complexe pour reventiler les clés là où elles vont bien.
     Je ne sais pas dans quelle mesure c’est vraiment pertinent : cela oblige à créer dans les tables une colonne "inutile" qui ne servira qu’une fois pour quelques enregistrements seulement, qui restera vide l’essentiel du temps et qui n’a pas de raison d’être dans le modèle conceptuel des données. Ça prend donc de la place inutilement et c’est un peu inélégant à mon sens.
3. La solution qui m’est apparue dans un demi-sommeil.
   Plutôt que de stocker provisoirement les clés importées dans une colonne dédiée dans chaque table qui restera vide le reste du temps, je les stocke dans une table annexe liée à chaque table. Cette table annexe ne comportera, outre ses clés primaire et secondaire, que la clé importée.
   L’importation est donc un peu plus compliquée puisqu’il faut ventiler les données de chaque enregistrement importé dans deux tables liées. Mais ensuite la procédure est fondamentalement la même que dans ma première solution. Une fois l’opération terminée on efface tous les enregistrements de toutes les tables annexes, lesquelles resteront vides de toute donnée l’essentiel du temps, donc il n’y aura aucun gâchis de place sur le disque.

Qu’en pensez-vous ?

[Ikhar84]

Il y a des SQL modeler qui font ça très bien. Je suppose que pour communiquer avec l’IA le plus commode est avec des .pdf, non ?

Le mieux avec une "IA" en mode chat est de lui fournir directement les fichiers de code .sql par exemple, pourquoi s'embarrasser du format pdf qui contient des méta données et pleins de trucs inutiles ?
L'IA n'est pas comme une humain qui ouvrirait un logiciel lecteur de fichier et aurait des yeux pour lire, c'est un système informatique.

En mode agentic, par exemple, elle a accès toute seule à tous les fichiers du projet.

[pm42]

Oui, le pdf est l'un des formats les pires pour les IA. Elles les transforment en texte pur pour pouvoir les lire.

Le format le plus fréquent est le texte seul où le .md (markdown). Si tu veux leur passer des images, un jpeg est très bien.