Discussion :

[escartefigue]

Oh wait, faut que je révise mon script d'import. Ca devrait pas mettre 2 liens !

Les données sont ajoutées depuis un fichier .csv, et un script que j'ai créé insère ensuite les valeurs des colonnes en fonction des tables. Voici quelques lignes du fichier (non exhaustif) :

"Le Sermon du siècle";"Guichard de BEAULIEU";"Manuscrit";1200;;"Edition moderne par Achille Jubinal en 1834 éd. Techener et Silvestre "
"L'Enfance d'Ogier le Danois ";"ADENET LE ROI";"Manuscrit";1270;;
"Joie et douleur de Notre-Dame";"Blaise d'AURIOL";;1520;;
"Rymes";"Pernette DU GUILLET";"Jean de Tournes";1545;"Antoine DU MOULIN";"Epitaphes par Maurice Scève et Jean de Vauzelles"

La colonne 3 correspond à l'éditeur, la 5 au préfacier.

D'après ce que je vois, votre fichier ne comporte pas les identifiants mais uniquement les libéllés, du coup je suppose que vous attribuez un nouvel identifiant dans la table cible a chaque occurrence d'un même nom d'éditeur dans le fichier, c'est ballot
Méthode d'extraction et de chargement à revoir

[tatayo]

Hé bien arrêtez de travailler avec des SGBDR de merde alors qu'il y en a des gratuits qui fonctionnent parfaitement bien....

Oui, mais... si je prends mon exemple, à l'époque du choix la contrainte était simple: "ce que tu veux comme SGBD, mais gratuit, et sous Windows.". Fin de la discussion. Et toujours à l'époque, il n'y avait que MaxDb et MySQL. SqlServer était payant, et PostgreSQL uniquement sous Linux.
Entre deux maux, choisit le moindre, j'ai rejeté MySQL...
Les choses ont bien changé, et la bascule sur SqlServeur est très sérieusement envisagée (surtout qu'on a les licences maintenant !).
Il ne nous manque qu'une seule chose: le temps.
Si un changement de SGBD était aussi simple qu'un changement de chemise, ce serait fait depuis longtemps.

Désolé pour l'aparté.

Tatayo.

[SQLpro]

Oui, mais... si je prends mon exemple, à l'époque du choix la contrainte était simple: "ce que tu veux comme SGBD, mais gratuit, et sous Windows.". Fin de la discussion.

Quelle époque ? Parce que en 1997 il y avait MSDE l’ancêtre de SQL Server Express qui était une version gratuite ! Il y avait aussi PostGreSQL 7 qui pouvait fonctionner dans Windows sous CygWin (j'ai eu un client qui fonctionnait comme ça...) et en 2005 nativement sous WIndows.... Sans parler de Ingres de Computer Associates tombé en libre en 2004

Et toujours à l'époque, il n'y avait que MaxDb et MySQL. SqlServer était payant, et PostgreSQL uniquement sous Linux.

Ton projet date donc de plus de 20 ans ? Et aucune remise en cause ???

Entre deux maux, choisit le moindre, j'ai rejeté MySQL...
Les choses ont bien changé, et la bascule sur SqlServeur est très sérieusement envisagée (surtout qu'on a les licences maintenant !).
Il ne nous manque qu'une seule chose: le temps.
Si un changement de SGBD était aussi simple qu'un changement de chemise, ce serait fait depuis longtemps.

Et bien essaye, je pense que tu seras supris !

Désolé pour l'aparté.

Tatayo.

A +

[tatayo]

Avant de me tirer dessus à boulet rouge, je n'étais pas décisionnaire à l'époque, j'avais eut du mal à évincer MySQL...
Le projet date maintenant d'une quinzaine d'années, j'avoue que je ne sais plus pourquoi SqlServer avait été écarté (peut-être les limitations de la version gratuite à l'époque...).
PostgreSQL ne tournait pas nativement (CygWin) => écarté.

MaxDB fait parfaitement son travail jusqu'à présent, mais comme nous avons désormais les licences SqlServer, la question de la migration revient de temps en temps.
Mais comme il existe à peu près autant de dialectes SQL que de moteurs, il faut bien vérifier s'il n'y a pas de problème avec les requêtes. IfNull par exemple n'existe pas avec SqlServer (je sais, les NULL c'est le mal !).
Il faut aussi prévoir la migration des 200Go de données d'une base utilisée quasiment H24.

Je ne suis pas nombreux (sic) et j'ai déjà un planning chargé jusqu'à la fin de l'année minimum (plus les imprévus).

Et comme cette migration "n'apporte rien" du point de vue utilisateur, elle n'est pas une priorité niveau planning...

On ne fais pas toujours ce qu'on veux...

Tatayo.

[SQLpro]

Avant de me tirer dessus à boulet rouge, je n'étais pas décisionnaire à l'époque, j'avais eut du mal à évincer MySQL...
Le projet date maintenant d'une quinzaine d'années, j'avoue que je ne sais plus pourquoi SqlServer avait été écarté (peut-être les limitations de la version gratuite à l'époque...).
PostgreSQL ne tournait pas nativement (CygWin) => écarté.

MaxDB fait parfaitement son travail jusqu'à présent, mais comme nous avons désormais les licences SqlServer, la question de la migration revient de temps en temps.
Mais comme il existe à peu près autant de dialectes SQL que de moteurs, il faut bien vérifier s'il n'y a pas de problème avec les requêtes. IfNull par exemple n'existe pas avec SqlServer (je sais, les NULL c'est le mal !).

1) vous n'avez pas étudier le niveau du SQL ni sa conformité au standard... C'est stupide !
Pour SQL Server vous avez le choix : ISNULL, NULLIF ou encore, créer une UDF appelée IFNULL !

Il faut aussi prévoir la migration des 200Go de données d'une base utilisée quasiment H24.

Pour info, avec SSIS (intégré avec SQL Server) 1 To = 30mn.
https://technet.microsoft.com/en-us/...=sql.100).aspx
Il faut maquetter et planifier... vous ne devriez pas mettre plus d'une heure à faire cette migration...

Je ne suis pas nombreux (sic) et j'ai déjà un planning chargé jusqu'à la fin de l'année minimum (plus les imprévus).

Et comme cette migration "n'apporte rien" du point de vue utilisateur, elle n'est pas une priorité niveau planning...

Jusqu'au jour ou vous aurez un crash majeur et perdrez toutes les données, car je suppose qu'il n'y a pas de système de haute dispo intégré à MaxDB...

On ne fais pas toujours ce qu'on veux...

Tatayo.

A +