Discussion :

[Ekimasu]

bonjour,


si on considère une base de données contenant des millions d'enregistrements répartis dans 30 tables.

1ere question/hypothèse

Si toutes les tables ont des noms à rallonge genre "xdsds1231346454797897987987987987978789" pour un souci de confidentialité.
Et si ses noms de champs sont aussi codés comme "fsdgdfg1231g321321gfd".

Est-ce que ça va entrainer des ralentissements de requetes ?


2eme question/hypothèse

Si les noms et l'ordre de création des tables sont par exemple :
a,b,c,d,e et que la table E est celle qui contient le plus d'information ou celle qui nécessite le plus de requêtes.
Est-ce qu'il vaudrait pas mieux faire en sorte que la table la plus appelé ou la plus grosse soit créée et positionnée en premier dans la base de données ?

Je sais que c'est très étrange comme question sur l'optimisation de base de données mais je n'ai pas trouvé de travaux à ce sujet.
Et je pense que les résultats peuvent être intéressants pour une base de données de millions d'enregistrements.

merci de vos idées.

[al1_24]

Ce serait vraiment le comble si l'ordre du nom des tables devait influer sur les performances du SGBD.
Qu'éventuellement, dans le contexte d'un dictionnaire de données déjà très encombré de nom d'objets, les opérations de définition de données avce des noms d'objets longs et très similaires puissent être ralenties dans un environnement matériel peu optimisé... Mais j'en doute.
En tout cas, je n'ai jamais rencontré de problèmes de cet ordre dans les environnements VLDB sur lesquels je travaille.

[Ekimasu]

bonjour,

oui c'est étrange mais techniquement possible car la premiere table créer aura un certain emplacement sur le disque dur, donc un positionnement plus rapide de lecture et écriture.
Et dans le cadre d'une 'énorme' basde de millions d'enregistrement, la taille de la base jouera, donc la position des tables aussi je pensais....
imaginez une base de données de 50Go ou la table la plus utilisée sera en fin de disque dur....
Je ne pense pas que ma question soit si bête que ça.
Disons juste que je cherche les derniers recours d'optimisation juste avant des solutions matérielles donc onéreuses.
Le SQL est optimisé, la taille des champs aussi, la structure relationnel aussi, la config serveur aussi.
De plus une table ayant nu nom à rallonge et des champs à rallonge va demander en chaine de caractère côté langage (PHP par exemple) une certaine taille qui prendre plus de temps aussi à être interprêtée par Apache/Php.
Une requête avec des champs codées ainsi pourrait faire 10 lignes au lieu de 1 si les champs étaient normaux...
En plus ça demande aussi de la mémoire au serveur Web...

c'est pour ça que je cherche des études , tests, opinions...

[al1_24]

1. Une base de 50 Go est une petite base de données.
2. Le nom de la table n'a pas d'incidence sur la position physique des données.
3. Le serveur de données n'est sans doute pas optimisé si de telles considérations influent sur les performances du SGBD
4. Pour les questions d'incidence de la taille des messages sur les transferts, les réponses se trouveront plutôt sur le foum PHP

[ukanoldai]

deux choses qui me viennent a l'esprit directement.

Pour les noms de tables je ne pense pas que cela change quelque chose, si l'on prend le cas d'oracle, ils sont limités a 30(ou 32 je ne sais plus), a tous les coups les différents endroits ou seraient stocké l'information d'une table est en fait dans une structure du sgbd donc probablement du char et non pas du varchar, le stockage est probablement le même.
De même pour le parsing de la requête dans le temps global cela ne changera absolument rien car elle est compilée et hashcodée, donc 3-4 caratères en plus ce n'est pas ca qui va changer le temps global de ton traitement.


Pour les disques dur il faudrait d'abord que quelqu'un confirme que:
1) les premières données sur un disque dur s'écrive bien a l'extérieur du plateau, qui est la partie la plus rapide.
2) que l'extérieur de tous les plateaux est écrit en premier et qu'au fur et a mesure l'écriture se fasse en même temps sur la même profondeur de tous les plateaux.