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. _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
