Conseils Model Core Data
JoshuaTree
Membre
Bonjour à tous,
Je soumets ici une question relative à CoreData, à la fois en termes de codage et de performance, qui porte sur la conception d'un datamodel d'un logiciel de saisie et d'analyse d'entretiens.
L'enjeu est de pouvoir réaliser des recherches croisées " à la volée " (l'intégration de chaque nouveau critère par l'utilisateur réactualise les résultats, à la manière des SearchFields qui filtrent en temps réel une tableView, par exemple)
Voici l'organisation du datamodel tel que je l'envisage pour l'instant (les entités sont indiquées en majuscules) :
Un ENTRETIEN contient une succession de paragraphes. Chaque PARAGRAPHE est caractérisé par le texte en lui-même et par la PERSONNE qui en est l'auteur (une même personne peut exister dans plusieurs transcriptions, c'est-à -dire être interrogé à plusieurs occasions).
Là , ça se complique un peu : l'enjeu est de pouvoir répertorier des extraits thématisés. Un EXTRAIT serait donc caractérisé par une thématique et par un début et une fin au sein d'un entretien. Les extraits s'affranchissent du découpage par paragraphes : un extrait peut parfaitement commencer au milieu d'un paragraphe (une personne parle) et finir au milieu d'un autre (dit par une autre personne).
Pour essayer d'être clair, voici un petit exemple avec le Cid...
DON DIàˆGUE (§1)
Rodrigue, as-tu du coe“ur ?
DON RODRIGUE (§2)
Tout autre que mon père
L'éprouverait sur l'heure.
DON DIàˆGUE (§3)
Agréable colère !
Digne ressentiment à ma douleur bien doux !
Je reconnais mon sang à ce noble courroux ;
Ma jeunesse revit en cette ardeur si prompte.
Viens, mon fils, viens, mon sang, viens réparer ma honte ;
Viens me venger.
DON RODRIGUE (§4)
De quoi ?
DON DIàˆGUE (§5)
D'un affront si cruel,
Qu'à l'honneur de tous deux il porte un coup mortel :
D'un soufflet. L'insolent en eût perdu la vie ;
Mais mon âge a trompé ma généreuse envie ;
Et ce fer que mon bras ne peut plus soutenir,
Je le remets au tien pour venger et punir.
La base contient donc :
1 entretien (ici intégralité du texte)
5 paragraphes (ici tous rattachés au même entretien et indiqués entre parenthèses après le nom de la personne)
2 personnes
Sur ce même entretien, voici à présent le découpage par extraits, indiqués sous forme de balises HTML (<a> </a>, <b> </b>, etc.).
DON DIàˆGUE (§1)
Rodrigue, as-tu du coe“ur ?
DON RODRIGUE (§2)
Tout autre <a>que mon père
L'éprouverait sur l'heure.
DON DIàˆGUE (§3)
Agréable colère !
Digne ressentiment à ma douleur bien doux !
Je <b> reconnais mon sang à ce noble courroux ;
Ma jeunesse revit en cette ardeur si <c>prompte.
Viens, mon fils, viens, mon sang, viens réparer ma honte ;
Viens me venger.
DON RODRIGUE (§4)
De quoi ?
DON DIàˆGUE (§5)
D'un affront </b> si cruel,
Qu'à l'honneur de tous deux il porte un coup mortel :
D'un soufflet. L'insolent en eût perdu la vie ;
Mais mon âge a trompé ma </c> généreuse envie ;
Et ce fer que mon bras ne peut plus soutenir,
Je le remets au </a> tien pour venger et punir.
Non seulement les extraits sont indépendants des personnes, mais ils peuvent également s'entrecroiser (une portion de texte peut ainsi être associée à de nombreux extraits : l'intégralité du paragraphe 4 [" De quoi ? "] est ainsi à la fois répertoriée dans les thématiques a, b, et c).
Revenons à la question du début : l'objectif est de pouvoir chercher de façon rapide des portions de texte (pas forcément des extraits entiers !) selon des critères du type
Trouver le texte " bidule " :
" présent dans les entretiens A ou B ou C
" dit par les personnes J, K, L
" associé aux thématiques X, Y, Z
Ma question porte en fait sur la façon de concevoir le modèle : dans quelle entité vaut-il mieux stocker le texte ?
–Vaut-il mieux stocker l'intégralité de l'entretien dans l'entité ENTRETIEN (entre 50 et 100 pages par entretien) ? Le stockage des paragraphes contiendrait alors simplement le numéro de paragraphe et le stockage des extraits contiendrait les numéros de caractère correspondants au début et à la fin.
–Vaut-il mieux stocker chaque texte de paragraphe dans l'entité PARAGRAPHE, et reconstituer un ENTRETIEN par la concaténation des paragraphes associés ?
Sur le plan du codage, les deux sont parfaitement possibles, je m'interroge juste sur la meilleure pratique
" En termes de simplicité de codage. Par exemple, le logiciel est aussi un outil de saisie des entretiens, qui enchaà®ne dans un même NSTextView une succession de paragraphes.
–En termes de performance : quels sont les impacts de ces choix sur la performance des requêtes, ce qui est pour moi un peu une boà®te noire ?
Merci de vos lumières et conseils !
Josh
[OSX 10.11; Xcode 7; Swift; ]
Réponses
Hello,
présente-toi s'il te plaà®t dans la section présentation des membres, afin que l'on sache quel est ton niveau, tes connaissances, etc.
Dans ton modèle, qu'est-ce qu'une THà‰MATIQUE ?
Je serais tenté naturellement de prendre la solution 2, mais pour la saisie des entretiens, la solution 1 paraà®t plus simple : imagine que finalement celui qui saisit le texte veuille fusionner deux paragraphes.
Pour les performances, je n'ai pas de réponse à te donner. Il est important de déterminer quels sont les cas d'usage où la rapidité est importante. Si c'est en saisissant du texte ? Ou en copiant/collant des grands textes ? Etc.
Bonjour Colas,
Merci pour ta réponse.
Une thématique est plus ou moins le sujet abordé par la portion de texte en question. L'objectif est par exemple de pouvoir retrouver rapidement tous les extraits correspondant à la thématique "Jalousie" ou "Trahison" par exemple (dans le cas du Cid), dans tout un ensemble d'entretiens...
La seconde solution trouvait aussi mes faveurs, mais plus par instinct que véritable réflexion.
Pour la saisie des entretiens, il ne faut évidemment pas que ce soit problématique et j'explore en ce moment les possibilités offertes par la classe NSTextView.
L'idéal serait d'aboutir à faciliter le plus possible la saisie (par exemple, à chaque saut de paragraphe, proposer à l'utilisateur un menu local avec complétion pour saisir rapidement les premiers caractères de la personne. L'appui sur la touche Entrée permettrait de rajouter une nouvelle instance de paragraphe. Mais en effet, il faut gérer tous les copier-coller potentiels, les glisser-déposer, etc...
Mais je me dis que de toute façon, il faut bien indiquer quelque part qui est la personne qui parle. Et si c'est saisi "en dur", dans le flot du texte, ça risque d'être encore plus difficile de faire des recherches...
Josh
PS: j'ai (un peu) mis à jour ma présentation...
Tu peux te présenter dans la section "Présentation des membres".
Pense à décorréler ton modèle et ta View de saisie des infos.
Fais simple pour commencer.
Pense à qui va saisir les infos. Pense aux cas d'utilisation (copier coller, etc.), etc.
Pense YAGNI (googleise ce mot magique)
Idée pour la saisie des noms des intervenants : un raccourci-clavier pour ajouter une entrée ? Avec une fenêtre pour choisir ou créer le nom. Et le thème aussi ?
Idée pour la View : NSStackView ? (mais uniquement avec les versions récentes de macOS ≥ 10.9)
Colas
Merci pour tous ces conseils et le YAGNI spirit...
Pour l'instant, j'implémente des petits projets brouillons, plus pour me familiariser avec Swift qu'autre chose. L'objectif est justement de stabiliser une v1 du projet qui soit simple, robuste et fonctionnelle: une appli de retranscription et de recherche de texte dans les entretiens. La partie gestion audio des entretiens est déjà implémentée et c'est la partie "saisie" en tant que telle qui m'occupe ces jours-ci.
C'est pour cela que j'essaye de stabiliser vraiment mon datamodel, pour ne pas avoir à faire marche arrière une fois le projet commencé, même si tout le volet recherche dynamique (au sein des entretiens, des personnes, des thématiques) ne viendra que dans un second temps (on en sera déjà à Swift 4 !! ;-)
Pour les NSStackViews, je dois avouer que je ne maitrise pas vraiment l'objet et du coup ne vois pas bien ton conseil: tel que présenté (du moins dans les vidéos WWDC que j'ai regardées), c'est surtout un palliatif théoriquement plus rapide qu'AutoLayout . J'ai fait quelques essais, d'ailleurs peu concluants...
Qu'avais-tu en tête exactement?
Deuxième point, plus théorique, sur la déconnexion entre model et view. J'ai toujours ça en tête mais me rends compte que c'est toujours un peu difficile de séparer aussi clairement les deux. Si tu as des conseils méthodo, je suis preneur aussi !
Josh
La deuxième solution ne semble résoudre aucun problème de plus que la 1ere.
Donc Un seul fichier texte par entretien et un stockage des zones dans la base. Tout cr que tu décris peut être ramené à des zones avec un début, une fin et un type. Y compris les éléments de dialogue.
Pour la saisie et l'affichage, je regarderai du côté des NSAttributedString et des custom attributes pour pouvoir gérer la création des zones et leur déplacement quand l'utilisateur modifie son texte. Mais Je ne sais pas si la NSTextView conserve les attributs custom des NSAttributedString, à vérifier...
Pour la transcription, il existe des API de dictation qui peuvent peut-etre faciliter le travail.
T'as des références ?
Pour les NSStackView : mon idée c'était d'empiler des VCs qui se succèdent et qui correspondent chacun à des paragraphes.
Pour le paragraphe courant, tu aurais un VC où tu peux saisir du texte.
Pour les autres, ce ne serait que de l'affichage.
Quand tu crées un nouveau §, tu crées un nouveau VC et tu demandes le nom et éventuellement le thème.
En fait, ça dépend vraiment de tes cas d'usage, de à qui tu destines le logiciel.
Je pensais à NSSpeechRecognizer mais en fait je viens de voir que c'est basé sur un dictionnaire pré-configuré donc cela ne colle pas avec le cas décrit ici.
Sinon il y a une API chez Nuance et une API chez Google en beta.
Merci à tous les deux pour ces précisions.
Je pense que je vais y aller progressivement: comme j'aimerais arriver à finaliser une v0 de la partie retranscription dans 15 jours, je vais partir sur le scénario 1: mettre tout le texte dans l'entité Transcription (et non un fichier texte, KFDEV: tout est géré dans une base CoreData). à‰videmment plus simple à implémenter... J'essayerai de voir dans un second temps, notamment à partir des problèmes rencontrés, si la solution 2 présente d'autres avantages...
En tout cas, dans la perspective du choix 2, l'idée des nsstackviews est en effet à creuser. D'autant que ça me forcera à explorer un peu la doc là -dessus...
Pour la reconnaissance vocale, j'y pensais à un moment (moi-même ayant dû retranscrire nombre de ces entretiens et c'est long!!). J'avais expérimenté Dragon, le logiciel de Nuance, en tant qu'utilisateur. Je ne savais pas qu'ils avaient mis à disposition une API. Merci pour l'info!
Joshua
Si l'utilisateur doit sélectionner du texte à travers des paragraphes pour définir un thème, je ne vois pas comment faire avec des stackviews.
Une seule vue contenant tout le texte permet également de faciliter les copier/coller de textes issu d'autres logiciels.
Le pire dans une GUI, c'est d'imposer des limites à l'utilisateur en fonction de choix de conception inadaptés.
Donc, bien réfléchir aux interactions possibles.
Finement vu, le coup de la sélection de plusieurs paragraphes...
ça donne à réfléchir... :-)
Merci
Josh