[Résolu] Comportement SQL

[Troll]

Bah l'option "fichier plat" ne serait-elle pas la même que le .bak : elle contient le SQL nécessaire pour recréer la base, non ?

[dardadax]

oui. en fait ça organise une sorte de tableau à la excel...sauf qu'au lieu d'avoir des colonnes, on a des "," pour séparer les colonnes

au début quand j'ai vu : "code d'insertion" j'ai de suite pensé à : INSERT blabla répété chaque fois que nécessaire (vu que dans le cas de l'export, on n'a pas de code mais les données brutes sauce "fichier plat", "excel" etc. pour la mise en forme) donc je me disais bien que c'était bizarre ^^ -> il n'y a donc pas d'export SQL, sauf si l'on ne veut que la structure de la base, les utilisateurs, vues, schémas, contraintes, procédures stockées

par contre là où j'ai halluciné, c'est les tailles de fichier .bak : même vide le datawarehouse fait plus de 20 Mo (sauf compressée...moins de 2Mo ^^ ouf)

[Troll]

Citation : sauf si l'on ne veut que la structure de la base, les utilisateurs, vues, schémas, contraintes, procédures stockées Wink

Oui bah ça nous aurait suffit. Les données à l'intérieur avec les INSERT etc c'est plus pratique pour travailler sur du concret mais c'est surtout la structure qu'il nous fallait pour mieux comprendre ton problème...


Oui la compression permet de gagner énormément de place quand c'est du texte, pour le texte de mémoire le mieux c'est la compression en GZip

[dardadax]

ok je note pour la compression Gzip ce n'était pas une archive de chez linux ?

concernant les données, le problème a été résolu par l'ajout de l'ID d'analyse (qui évitait les mauvaises surprises en le récupérant dans la base de prod et l'insérant dans la table des questions du datawarehouse) donc...je n'ai plus ce soucis.

par contre j'ai un collègue qui a le même à nouveau...SSIS serait-il capricieux ? ^^ (pour une exécution de même package, il a plusieurs résultats de fusion lol)
petite question associée : qu'est ce qui peut faire que, lors d'une jointure externe gauche, l'on récupère moins de lignes après la jointure que dans la table de gauche de la jointure ?

ex : "personne" 1000 lignes et "statut" 2 lignes
dans le package on arrive à une jointure externe gauche de "personne" sur "statut" cependant au lieu d'avoir mini 1000 lignes il en a parfois 900 parfois 800 etc. (or chaque personne a un statut obligatoirement)

les ID de jointures peuvent-ils générer ce comportement ? (il n'y a aucun ID nul servant à la jointure)

[Troll]

Bah normalement, la théorie dit qu'une jointure gauche récupère tout dans la table de gauche et seulement les résultats join dans la table de droite.

Après les filtres de la clause WHERE s'appliquent évidemment aux sélection. Mais si tu fais sans WHERE une jointure gauche "personne LEFT JOIN statut" un bon sgbd doit renvoyer tout ce qu'il y a dans "personne"...

[dardadax]

c'est bien le problème ^^ pas de filtre et on n'a pas tout. Pire le résultat est aléatoire...
à mon avis ça vient d'un problème de mémoire, comme pour l'exécution...

on a modifié des paramètres pour améliorer la vitesse d'exécution (nombre de buffers max) pour la partie test en développement, donc peut-être que ça vient de mémoire insuffisante ? (on teste et on voit ce que ça donne de toute façon)

[Troll]

Citation :(on teste et on voit ce que ça donne de toute façon)

Voilà