Question sur les références de table (de Russel)
Cette question est apparue dans le fil de discussion sur " Re: Session pratique 2022Q1 - Débutants" - et j'aimerais que d'autres se joignent également à la discussion, alors je l'ai mise sur le forum de discussion.
Question sur les références de table que vous avez montrées aujourd'hui : si vous traitez plusieurs tables de manière séquentielle dans le cadre d'un script, itérez-vous les références de table à l'infini (dt1, dt2, dt3, ...) ou existe-t-il une solution plus intelligente ?
Contexte : Je manipule fréquemment des tables (joindre, concaténer, diviser, etc.) et j'ai parfois plusieurs tables que j'ouvre, traite et ferme de manière séquentielle avant de passer à la table suivante dans le même script jusqu'à ce que j'aie la table finale que je veux .
Re : Question sur les références de table (de Russel)salut @Ressel ,
cela dépend vraiment de ce que vous voulez faire finalement. Si vous avez, disons, 100 tables de données que vous souhaitez traiter de la même manière et fermer ensuite, une boucle (pour ouvrir, traiter, fermer chaque table) ferait mieux le travail que d'ouvrir les 100 tables puis de les traiter une après L'autre. L'une des raisons est que vous ne créez pas autant de poignées de fenêtres, ce qui pourrait provoquer un autre problème côté système.
En général, je serais un peu plus descriptif dans le nom de la variable de table, donc je comprends mieux ce que c'est, si cela a du sens. "dt" est pour le hack sale principalement 
Vous pouvez également obtenir toutes les tables de données ouvertes, puis les parcourir en utilisant
Get Data Table List();
Ce serait probablement une décision intelligente.
Comment les autres se sentent-ils à ce sujet ?
Re : Question sur les références de table (de Russel)je suis d'accord avec @martindemel , cela dépend de l'emplacement des fichiers, de l'ordre dans lequel vous les traitez et de ce que vous voulez en faire. JSL a de nombreuses fonctions intégrées en dehors du journal amélioré qui peuvent aider. Par exemple, Fichiers dans le répertoire vous donne une liste de tous les fichiers dans un répertoire. Choisissez un fichier vous permet de sélectionner de manière interactive un ou plusieurs fichiers dans un répertoire. Bien que le journal amélioré fasse un bon travail en capturant les opérations interactives, vous souhaitez toujours remplacer les références de nom de table codées en dur par des références de variable aux tables. @martindemel montré une partie de cela en utilisant dt = Ouvrir(... Dans la plupart des cas, une opération JSL qui ouvre un fichier renverra un handle vers la table de données créée. Les descripteurs de table de données sont également créés lorsque vous envoyez un message à une table avec une opération à partir du les tables menu. Par exemple, si vous créez un sous-ensemble, la syntaxe
subsetDT = dt << Subset(...
vous permettra de capturer la référence à la table nouvellement créée. Les autres opérations de table fonctionnent de la même manière.
Re : Question sur les références de table (de Russel)Merci pour les réponses. Un peu plus sur le fond de ce avec quoi je travaille.
Je charge les tables de notre implémentation Google Cloud Platform via ODBC. Ces tableaux sont régulièrement mis à jour avec des données de fabrication récentes. Par exemple, la première table que je charge (je la référence comme dt ) comporte des ID de lot, des noms de paramètre pour différents paramètres de CQ, des résultats de mesure et des unités de mesure dans des colonnes séparées. Je le divise par nom de paramètre QC (et référence la sortie comme dt2 , fermeture dt ). Ensuite, par exemple, je charge une autre table qui croise les ID de lot avec les lieux de fabrication (que je référence comme dt3 ). Après cela, je peux rejoindre dt2 avec dt3 , création dt4 et ainsi de suite, jusqu'à ce que j'aie un tableau contenant toutes les informations dont j'estime avoir besoin avant de procéder à une quelconque analyse. Dans certains scripts, je traite près de 10 tables, toutes référencées comme dt(n) . C'est ce que mon niveau actuel me permet.
J'ai un plan à moyen terme pour utiliser un tel script pour la carte de contrôle. Pour le moment, je n'évalue que visuellement les tendances et j'envoie des captures d'écran ou des graphiques exportés au format HTML aux différentes parties prenantes.
Ce que je retiens de cette conversation, c'est d'utiliser des références de table plus descriptives. Ce sont aussi ce qu'on appelle des poignées?
Re : Question sur les références de table (de Russel)Les noms descripteurs/de référence descriptifs vous aideront (ou quelqu'un d'autre qui doit modifier votre code) à un moment donné. Cela facilite également l'impression de débogage, lorsque vous pouvez utiliser Show(dt_batchid_loc); par exemple pour voir le nom des tables créées.
Il peut également être utile d'utiliser la table de sortie ("nom de la table") lors de la création de tables. Cela vous aidera si vous (quand vous) devez déboguer le code. Si vous ne le faites pas (j'ai tendance à sauter cela et cela me hante de temps en temps), il est beaucoup plus facile de voir quelle table est ouverte à partir d'un nom comme "BatchID_with_Loc" par rapport à "Untitled 3041 summary by QC , Loc" ou quelque chose comme ça.
Re : Question sur les références de table (de Russel)Il y a aussi la possibilité de faire la manipulation de table dans la base de données (définition de la requête par exemple par Query Builder ou en SQL natif). Ceci est avantageux pour les grands ensembles de données, car vous évitez le trafic et chargez lourdement le serveur. Ensuite, vous devez également gérer moins de tables dans JMP.
Re : Question sur les références de table (de Russel)J'ai déjà essayé d'utiliser le générateur de requêtes. Il était incroyablement lent et n'arrêtait pas de planter constamment. J'ai donc contacté le support technique SAS, mais ils n'ont pas pu résoudre le problème. En conséquence, je me suis contenté de gérer des tables individuelles dans un script, ce qui ; compte tenu des performances lamentables du générateur de requêtes ; est beaucoup plus pratique et efficace. Il se peut que cela soit dû au fait que les tables que je charge ont plus de 100 000 lignes - c'était au moins la conclusion du support technique. Hélas, je n'ai pratiquement nulle part où me tourner que ces tables "massives".
De plus, je pense que je dois de toute urgence me familiariser avec le débogage. Bien que je parvienne à « brouiller » quelques lignes de code utiles, je ne considère pas l'architecture, l'esthétique ou ; en réalité; comment construire un script qui peut être débogué. Malheureusement, c'est encore un concept étranger pour moi.
