[gull] MySQL table partitions

[Daniel Cordey]

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