"Anticiper la suite" c'est d'abord mettre une clé primaire sur ta table. Il faut que tu puisses identifier une ligne facilement sans te baser sur "form" qui plus est est au format TEXT.
Pour les index c'est simple: un sur form, un sur searchfreq.
Après, les INTEGER c'est très bien, par contre les TEXT ca l'est moins. Si tu peux éviter, évite, ou remplace les au moins par des VARCHAR si leur contenu ne dépasse pas qqs centaines de caractères.
Je ne sais pas ce que ta table va contenir, mais par exemple, si la colonne context contient souvent la même chose, crée plutôt une table contexts (context_id INTEGER, context VARCHAR) que tu pourras référencer dans ta table forms.
# Re:
Posté par apkwa . En réponse au message table SQL à optimiser. Évalué à 2.
Salut,
"Anticiper la suite" c'est d'abord mettre une clé primaire sur ta table. Il faut que tu puisses identifier une ligne facilement sans te baser sur "form" qui plus est est au format TEXT.
Pour les index c'est simple: un sur form, un sur searchfreq.
Après, les INTEGER c'est très bien, par contre les TEXT ca l'est moins. Si tu peux éviter, évite, ou remplace les au moins par des VARCHAR si leur contenu ne dépasse pas qqs centaines de caractères.
Je ne sais pas ce que ta table va contenir, mais par exemple, si la colonne context contient souvent la même chose, crée plutôt une table contexts (context_id INTEGER, context VARCHAR) que tu pourras référencer dans ta table forms.