Question efficace sur la base de données mySQL

Question

J'ai une question sur l'efficacité de la base de données.

Voici quelques informations sur ma table:

-table d'environ 500-1000 enregistrements -Enregistre sont ajoutés et supprimés tous les jours. - en général, environ le même montant est ajouté et supprimé chaque jour (la taille des enregistrements actifs reste la même)

Maintenant, ma question est ..... lorsque je supprime des enregistrements, ... devrais-je (A) supprimer l'enregistrement et le déplacer vers une nouvelle table? Ou, ... devrais-je (B) avoir juste et colonne "active" et mettre l'enregistrement à 0 quand il n'est plus actif. La raison pour laquelle je hésite à utiliser B, c'est parce que mon site est basé sur le fait que l'utilisateur puisse filtrer/trier cette table de 500-1000 enregistrements à la volée (en utilisant ajax) .... j'en ai donc besoin être aussi rapide que possible, .. (je devine qu'une table avec plus d'enregistrements serait plus lente à filtrer) ... et j'utilise mySQL InnoDB.

Toute entrée serait génial, Merci

Andrew

Answer 1

En réalité, il ne s'agit pas d'une question d'efficacité de la base de données mais de la latence du réseau et de la quantité de données que vous envoyez sur le réseau. En ce qui concerne MySQL, 1000 lignes ou 100k lignes vont être rapides comme l'éclair, donc ce n'est pas un problème. Cependant, si vous avez une quantité importante de données dans ces lignes, et que vous transmettez tout cela au client via AJAX pour le filtrage, la latence du réseau est votre goulot d'étranglement. Si vous transmettez une poignée d'octets (disons 20) par ligne et votre table reste autour de 1000 enregistrements de longueur, pas un gros problème. D'autre part, si votre table se développe (avec des enregistrements inactifs) à, disons, 20k lignes, vous transmettez maintenant 400k au lieu de 20k. Vos utilisateurs remarqueront. Si les enregistrements sont plus volumineux, le problème sera plus grave à mesure que la table se développera.

Vous devriez vraiment faire le filtrage côté serveur. Laissez MySQL passer 2ms à filtrer votre table avant de passer une seconde entière ou deux à l'envoyer via Ajax.

Answer 2

Cela dépend de ce que vous filtrez/tri et comment le tableau est indexé.

Une troisième option, et non inhabituelle, vous permet d'avoir une approche hybride en désactivant les enregistrements (B) (éventuellement avec un horodatage) et en les archivant périodiquement dans une table séparée (A) l'âge de l'horodatage). De manière réaliste, si votre table est dans l'ordre de 1000 lignes, cela ne vaut probablement pas la peine d'en faire trop (en supposant que l'évolutivité des autres facteurs est connue).

Answer 3

Si vous devez conserver les enregistrements pour un usage futur, je définirais un bit inactif.

Tant que vous disposez d'une clé primaire sur la table, les performances doivent être excellentes lorsque les enregistrements sont enregistrés.

De même, si vous effectuez le filtrage/tri sur le côté client, les enregistrements ne devront être récupérés qu'une seule fois.

Answer 4

~ 1000 enregistrements est un très petit nombre.

Si un enregistrement peut être supprimé et rajouté plus tard, il est peut-être logique d'avoir un indicateur "actif".