Forum d'entraide PHPFrance

Hello,

voila je cherche s'il n'y a pas d'équivalent à un str_replace(',9', '', $chaine); de php en mysql.

j'ai un champ qui contient des chiffre séparé par des virgules.
j'aimerais supprimer un(plusieurs) chiffre(s) et la(les) virgules(s) qui va(vont) avec si possible sur plusieurs enregistrement différent.


merci.

Ce que je te conseille plutôt c'est de séparer tous ces nombres et les placer dans une table. Par exemple, au lieu d'avoir (id, nombres) égal à (1, '1,2,3'), tu as une table avec (id) où id est la clé primaire, et une autre table avec trois enregistrements (id, nombre) (1,1), (1,2) et (1,3) avec un index sur id et même un second sur nombre s'il t'arrives régulièrement de faire des requête là dessus.

Avec un tel schéma, toutes les opérations de mise à jour sont simplifiées. Ce procédé s'appelle la normalisation et c'est un principe de base dans le domaine. Et si tu veux supprimer un ou plusieurs "nombre" rien n'est plus simple, par exemple: En plus, je t'offre pour le même prix la modification de ta requête SELECT ! (sous MySQL) Avant: après: De cette façon, tu n'as rien à changer dans ton application. (et si tu ne te sers par de la liste de nombre évite de joindre la table pour rien, hein )

le but étant en fait de faire un pseudo cache si je puis dire, en fait j'ai déjà une table qui contient une liste d'id.

en gros considère que tua s des arbre, dans al table contenant les id on a tel id est dans tel branche de l'arbre..

dans la table sur lequel je veux supprimer le nombre et la virgule (la table avec le pseudo cache) on a ce un étage de l'arbre avec en pseudo cache ce qu'il y a au dessus et en dessous...

donc le but étant de simplifier.... le nombre de requête sql ....

je sais pas si je suis clair ...

Ce qui est illogique dans ton raisonnement, c'est que pour une modif, celà entraine des tas de modifs

Je pense qu'un base de données correctement normalisée et optimisée peut permettre des recherches plus rapide que via un pseud cache comme tu compte le faire

disons que je suis occupé à me rendre comtpe que ce que tu dis est effectivement vrai au départ j'ai pas trop réfléchi ( heureusement qu'il n'y pas pas bcp de code pour le moement...)

ce qu'il y a c'est que lire tout les membre d'un abre devra être fait souvent donc rapidement si possible....

mais apapremtn si j'ai bien vu et imaginer aisni que compris ce qui à été dit cela revient au même il n'y aura pas de requete sql en plus et lors de l'ajout cela se fera rapidement.... tout comme à la supprétion....
mais normalement le fait de supprimer un arbe est rare donc pour moirare = cela me dérange pas de faire des calcul (raisonable)...

le but étant en fait de faire un pseudo cache

Tu aurais dû commencer par ça ! j'avais justement une discussion à ce sujet un peu plus tôt sur le forum

La règle d'or c'est de ne jamais opérer sur les données du cache. Si tu gères un arbres, soit tu utilises un système de liste d'adjascence (pas très sûr de la traduc, basé sur l'auto-jointure) soit un système de représentation intervallaire. Ce sont sur ces données et sur ces données seulement que tu dois travailler. Le résultat de ces opérations peut ensuite être mis en cache si tu le souhaites. Le plus simple à mon sens, est de mettre les données en cache sous forme sérialisée (voir serialize()) et à chaque mise à jour de la table contenant les données originales, effacer le cache en le remplaçant par une chaîne vide. De cette façon, tu peux rapidement vérifier si l'arborescence de chaque objet est en cache lors de la récupération des données:

if ($row['cache'] == '')
{
   // calculer_arborescence() calcule l'arborescence de l'objet,
   // met à jour la base de données et renvoie l'arborescence
   $row['cache'] = calculer_arborescence($row['id']);
}

génial l'article je vais lire ca avec passion...

enfin il faut dire que d'habitude je réfléchi un peu plus avant de coder cette fois ci me suis lancer trop vite ...


merci pour tout ...

edit:
vraiment parfait merci à tous .