[gull] MySQL table partitions

Marc SCHAEFER schaefer at alphanet.ch
Fri Nov 24 18:47:27 CET 2006


On Fri, Nov 24, 2006 at 10:31:01AM +0100, Daniel Cordey wrote:
> > à quoi servent les tables MERGE?  sont-ce simplement des VIEW actives ?
> 
> Je ne connais pas les VIEW, mais une table MERGE est le regroupement de N 
> tables sementiquement identiques, permettant de faire un SELECT global sur 
> l'ensemble des tables "groupees" dans la table MERGE. Cela evite simplement 
> l'emploi des JOIN. Les update/insert doivent continuer a se faire sur les 
> tables initiales car la table MERGE n'a pas d'indexes et se repose sur celles 
> des tables "grtoupees".

Ok, donc dans ce cas, je pense que l'on pourrait passer par héritage (un
SELECT sur la table de base montre toutes les valeurs des tables
filles), ou par une simple VIEW passive (sans avantage de performance).

Dans le cas de PostgreSQL l'insertion peut se faire sur la table de
base, s'il on écrit les triggers/rules ad-hoc.

> l'adjonction de nouveaux elements. Si mes souvenirs sont bons, dbm ne doit-il 
> pas re-evaluer son hash-domain a chaque insertion ?

Excellente question: l'insertion est effectivement lente; dans mes
souvenirs il me semble qu'il y a un caching de hâchage, la table de
hâchage étant étendue toutes les N insertions, et non pas à chaque
insertion.

Il faudrait comparer les techniques offertes par les *dbm modernes ainsi
que par le indexes de bases de données, j'aurais tendance à penser,
comme ça, que les techniques sont les mêmes aujourd'hui.




More information about the gull mailing list