Je fais suite, désolé du hachage !
Bien évidemment, c'est très facile de saucissonner cela dans un quelconque programme AutoIt (ou tout autre langage d'ailleurs du fait de l'incroyable portabilité de SQLite, aussi bien du code de la biblithèque que des bases elles-mêmes).
L'emploi d'un formidable outil comme Expert permet de se cuisiner une base aux petits oignons sans avoir à écrire une seule ligne de code, ce qui fait gagner 70% du temps de développement (sans rire !) quand on ne s'appuie pas sur une analyse exhaustive.
J'ai mis à jour la base à télécharger (il manquait une colonne vitale et j'avais fait une faute de frappe). Utiliser
le même lien.
Pour démontrer qu'il n'est aucunement rédhibitoire de faire une requête complexe, ouvrir la base dans Expert, choisir un onglet SQL et coller ceci :
Code : Tout sélectionner
select Mot,
motlatin "Mot(s) latin(s)",
snippet(citations, '▶', '◀', '…', 0, 10) "Citation",
oeuvre "Ouvrage d'origine",
auteurlatin "Auteur latin",
Manuel,
edition "Édition",
Page,
manuelauteur "Auteur",
editeur "Éditeur"
from Mots
natural join citations
natural join oeuvres
natural join auteurslatins
natural join manuels
natural join auteursmanuels
natural join editeurs
where texte match 'fts4 NEAR/3 module'
puis faire F5 ou cliquer sur le bouton Execute SQL.
En bref, je veux la traduction et les références connues où figurent les mots FTS4 et modules séparés d'au plus 3 mots. Je donne aux colonnes des titres parlant.
Pour une requête de traduction simple, ouvrir un second onglet SQL et coller cette requête (bidon, je l'accorde) :
Code : Tout sélectionner
select motlatin "Mot latin", mot Traduction from mots where motlatin = 'moduli'
Pour une validation de traduction avec toutes références, dans un autre onglet SQL :
Code : Tout sélectionner
with
trad ("Mot latin", Traduction)
as
(select motlatin, mot from mots where motlatin = 'moduli')
select motlatin "Mot(s) latin(s)",
Mot,
snippet(citations, '▶', '◀', '…', 0, 10) "Citation",
oeuvre "Ouvrage d'origine",
auteurlatin "Auteur latin",
Manuel,
edition "Édition",
Page,
manuelauteur "Auteur",
editeur "Éditeur"
from Mots
join trad on motlatin = "mot latin"
natural join citations
natural join oeuvres
natural join auteurslatins
natural join manuels
natural join auteursmanuels
natural join editeurs
where texte match traduction
Cette dernière requête emploie une CTE (common table expression) introduite récemment avec la clause WITH, ce qui permet de tout grouper dans une seule requête.
Donc mis à part la relative rugosité du langage SQL, il n'y a rien de magique là-dedans.
On dispose aussi de possibilités offertes directement par le moteur et qui pourraient apporter un sérieux plus, par exemple lister le thésaurus des mots latins cités par un auteur donné, faire des statistiques d'occurence de mots, de termes proches les uns des autres (embryon de contexte sémantique), lister le thésaurus commun à Virgile, Esope et Lucrèce qui n'est employé par aucun autre auteur latin, etc. Les possibilités sont infinies et ne demandent pas une ingénierie extraordinaire, si l'on accepte de tâter l'eau et de s'y plonger (même si elle peut sembler frisquette au début, je sais).
Les définitions dans cette base "jouet" assurent l'intégrité des données. On ne peut rentrer une citation que si les éléments qu'elle référence existent préalablement (clés étrangères ou Foreign Keys). Si l'on modifie ou supprime une entité de base, par exemple un éditeur, alors toutes les données qui y font référence seront modifiées ou supprimées.
Même dans cet état de squelette et sans aucun contrôle de vraisemblance au niveau des données, le moteur SQL assure déjà bien cette cohérence de base. Il serait énormément plus difficile d'aboutir au même niveau de robustesse avec des fichiers texte ou une table unique. Ainsi, le nom d'un auteur ou d'un éditeur ne figure qu'une fois ce qui met à l'abri de fautes de saisie qu'il serait impossible d'éviter en pratique si l'on devait saisir de nouveau ces données à chaque citation.
Je suis bien conscient d'avoir fait ici une longue parenthèse (trop ?) orientée SQL par rapport au contexte initial, mais j'espère qu'elle ouvrira des portes.
Ne pas oublier qu'on peut formater directement en SQL avec l'opérateur de concaténation || le résultat d'une requête pour qu'elle soit immédiatement collable dans les éléments d'une listview.
A titre d'exemple ultra-simple, on peut faire (cas de | utilisé en séparateur de colonnes pour la listview) :
Code : Tout sélectionner
_SQLite_GetTable($hDB, "select manuel || '|' || manuelauteur || '|' || editeur from manuels natural join auteursmanuels natural join editeurs", $aRows, $iRows, $iCols)
Essayer avec Expert : le tableau 1D obtenu (la première rangée comporte le titre et est à ignorer) contient des chaînes susceptibles de peupler une listview. Là encore, zéro code ou si peu.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Je ne maîtrise pas suffisamment sqlite. Je vais sans doute succomber à la tentation de 