(Courriels de diversion: <revaloriserez@remmeniez-consternee.com> <tinterent@ossements-posterite.com> <substitues@justificative-biner.com> <replet@petrins-allongerez.com> <economisent@reservistes-affinerais.com> <referait@embrayerais-phonologique.com> <appela@brilleront-hispanophone.com> <clopiner@pal-retombez.com> <confirmes@impunie-propageons.com> <geniale@demaquillerait-purgeons.com> )
Le Jeudi 14 Décembre 2006 12:00, Alvarez a écrit : > patrick a écrit : > > Le Jeudi 14 Décembre 2006 08:42, Jean-Pierre Nicolin a écrit : > >>>> Je n'ai pas encore exploré la méthode proposée par Cédric. > >>> > >>> une proposition dérivée de la sienne : > >>> create table as select count(ref_livre) nb, ref_livre > >>> from MA_table > >>> group by ref_livre > >>> having count(ref_livre) = 1 > >> > >> Je pense aussi que la solution la plus simple est effectivement > >> d'utiliser les 'aggregates' et une table intermédiaire. Tout dépend des > >> valeurs "redondantes" Veux tu en conserver une ou pas du tout ?. > > > > Si je peux, oui. > > > >> Je ferais donc pour le select interne : > >> select 1 , (tous les autres champs identiques par groupe) from matable > >> group by (tous les autres champs identiques par groupe); > > > > Dans l'immédiat j'ai basculé sur la table avec un champ 'unique' sur le > > titre pour éviter les doublons. Ca fonctionne très bien. > > Il ne me reste plus qu'à restituer les enregistrements de l'ancienne > > table dans la nouvelle. > > > > (merci pour votre aide) > > Bonjour > > Pour des problèmes isolés de ce type et si on ne maîtrise pas les > subtilités SQL, Je me reconnais dans cette description. :-) > si l'on n'a pas de langage procédural associé à la > base(transactSQL/M$, PLSQL/Oracle) Il manque Postgresql ! (disponible chez free.fr) > , et pour les petites bases, il y la > méthode bestiale (pas très gnou ;-) : > > - On fait un export de la base. (voir phpMyAdmin chez free) > - On se retrouve avec un script SQL de création / remplissage de > base (pratique pour déménager / sauvegarder la base d'un site) > - On édite l'export avec son éditeur favori*, > - On vire / corrige à la main ou on fait des macros / scripts pour > toiletter sa base (avec une base propre, on se sent mieux ;-) > - On ré-importe le résultat avec phpMyAdmin* J'y ai pensé. Mais maintenant que c'est archivé et stabilisé, je préfère trouver une méthode réutilisable. J'ai renommé la table car je devais limiter les dégâts. ;-) > * : dans le cas qui nous intéresse, il peut penser qu'il suffit de > réimporter seulement la table concernée, et en principe, dans le script > produit par phpMyAdmin il y a les instructions pour vider la table avant > de charger les nouvelles données. Attention s'il y a des relations vers > cette table cela peut poser des problèmes de clés étrangères. A défaut > d'une bonne maîtrise du problème je conseille d'être bestial, de garder > le script complet et de tout recréer dans la base. Les données ne sont pas critiques. Je cherche un compromis entre la méthode propre et la méthode dite bestiale. De plus je suis tenté par migrer vers postgresql. Cordialement. -- http://www.april.org/association/adhesion.html#hesiter ? -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>