Discussion :

[redoran]

salut ; l'intervention de rayek dans erreur de suppression me pousse à posé cette question :
est ce que la méthode locate sur un champ indexé a le même effet qu'une requête sur un nombre d'enregistrement consequant ( > 20 000 ou ++++) ?

[SergioMaster]

en temps de réponse ? Certainement pas , la palme revient sans nul doute à SQL .

Pour faire un locate , il faut que toute la table soit "chargée en mémoire" !!
y a pas photo surtout sur un réseau , encore plus lorsque le réseau est 'déporté' (postes connecté via internet ou réseau spécialisé)

Imagines :
Locate pour faire le locate tu ouvres une table , tu récupères la table entière et enfin tu fais une recherche =>trafic réseau intense

SQL tu fais la demande , le serveur de données cherche l'enregistrement , tu reçois l'enregistrement demandé et c'est tout => trafic réseau réduit

de plus dans le cas d'un réseau le locate cherche sur une 'photo' de la table si elle a été modifiée depuis .... misère

[Rayek]

Pour faire un locate , il faut que toute la table soit "chargée en mémoire" !!

Je ne dirais pas "Toute la table" car le locate fonctionne aussi sur les Query (oui je sais je pinaille ) sinon tout à fait d'accord pour le reste

Un TxxxTable n'est ni plus ni moins que l'équivalent d'un

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Select * from La_Table

[ShaiLeTroll]

Il ne faut pas confondre les Choses
Locate = Fonction Delphi côté Client
SQL = Fonctionnalité du SGBD côté Serveur

Attention avec BDE, l'ouverture d'une Table, ce n'est pas un SELECT *, ça dépend en plus du Driver, il ouvre un curseur sur la Table (directement en fichier pour Paradox, DBF, ... et via un tampon pour ORACLE ou MSSQL qui limite le nombre d'enregistrement récupéré !)

Apollo pour DBF a le même comportement, l'ouverture est instantanée !

Par contre, pour des libs purement SQL comme UniDAC, ADO, DBExpress, il faut voir les possibilités de limitation des RecordSet, de connexion Asynchrone ou utiliser les fonctions spécifiques comme TOP, LIMIT, ...

Après, tout dépend ce que l'on considère comme conséquent, je sais que Paradox BDE pour trouver qu'un Code Barre n'existe pas, il lui faut une petite µs par ligne si on stocke le CB en Chaine, c'est 2 à 3 plus rapide si l'on utilise 2 Champ Entier Indexé au lieu d'une chaine ! Donc ça devient pénible au dela des 200 000 lignes avec MySQL ça devient un peu long après 10 000 000 de lignes, je dis "long" lorsque cela dépasse les 100ms

le SQL va être rapide pour trouver les enregistrements mais va être long si il y a beaucoup car il doit les stocker en local, les mettre sur le réseau, le client doit les stocker à son tour en mémoire, ensuite le serveur libère les ressources allouées (ce qui prend du temps aussi)

Pour cela, les pratiques Web comme la génération de page pour les listings est une bonne école pour ne pas faire des choses inutiles comme récupérer un listing de 20000 lignes dans un DBGrid alors qu'une Page en affiche 30 au mieux !

Ensuite, on ne parle même pas des Jointures, là selon comment la DB a été designé cela peut être rapide comme extrément pourri !