On Friday 24 November 2006 18:47, Marc SCHAEFER wrote: > 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).
OK. Toutefois, ce ne sont plus les tables MERGE qui m'interessent (car trop lourd a gerer avec beaucoup de tables sur une grosse base), mais bien cette notion de PARTITION. Le gros avantage des partitions est la facilite de gestion automatique des toutes partitions et l'optimisation des requetes par la selection de la partition appropriee. C'est vraiment le seul moyen de gerer de tres grosses bases sans perdre de performances avec des indexes de plusieurs GB. Mon soucis est d'etre sure de ne pas developpe/utiliser quelque chose sous MySQL qui n'a pas d'equivalent sous PostgreSQL. Il semble que ce soit un peu le cas en ce moment avec les partitions de MySQL, mais gageons que PostgreSQL ne va pas tarder a proposer quelque chose d'equivalent. Ca me parait trop important pour les tres grosses bases. > Dans le cas de PostgreSQL l'insertion peut se faire sur la table de > base, s'il on écrit les triggers/rules ad-hoc. Oui, mais il faut quand meme les ecrire sois-meme... c'est un peu plus lourd a gerer sur le long terme. > 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. Ou, au pire, les differences sont insignifiantes. Mis a part le fait les *dbm sont essentiellements 'orientes' interrogations alors que les gestions des indexes des DB tiennent plus compte de cette notion d'update/insert. Les objectifs etant differents, il se peut que les methodes different un peu. Plus on essaie d'etablir un compromis, moins il y a de differences :-) dc _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
