pour une utilisateur donné, j'associe une liste de valeur.
Cette liste peut varier en longueur.
Je dois ensuite stocker cette liste dans une table MySQL.
Pour faire ceci, j'utilise un array, auquel :
- j'empêche d'ajouter un doublon avec in_array (plutôt que d'utiliser
array_unique à la fin)
- j'ajoute des éléments par array_push
- je supprime une valeur donnée d'abord en la cherchant avec
array_search puis en l'effaçant avec unset (j'ai pensé à array_filter
également).
Puis je 'serialize' le tableau pour le placer dans un champ MySQL.
Ca me parait bizarre comme façon de faire et comme mon niveau en php
n'est pas brillant, je voulais savoir comment mieux faire (sans utiliser
d'array ? en utilisant mieux MySQL ? SQLite (mais bof parce que pas
facilement dispo) ?).
- La solution proposée est facile à mettre en oeuvre et à déboguer. Il suffit d'un simple echo pour voir la chaîne avant et après. - La solution proposée n'impose pas de changement de forme de représentation (on n'a pas besoin de faire: extraire de la base SQL, transformer en array, faire le traitement, transformer de nouveau en chaîne, insérer dans la base SQL).
Avec un schéma normalisé, il n'y a aucun des ces traitements à faire. Et on a une base utilisable sans devoir passer par du code PHP.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Beauregard wrote:
- La solution proposée est facile à mettre en oeuvre et à déboguer.
Il suffit d'un simple echo pour voir la chaîne avant et après.
- La solution proposée n'impose pas de changement de forme de
représentation (on n'a pas besoin de faire: extraire de la base
SQL, transformer en array,
faire le traitement, transformer de
nouveau en chaîne, insérer dans la base SQL).
Avec un schéma normalisé, il n'y a aucun des ces traitements à faire. Et
on a une base utilisable sans devoir passer par du code PHP.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
- La solution proposée est facile à mettre en oeuvre et à déboguer. Il suffit d'un simple echo pour voir la chaîne avant et après. - La solution proposée n'impose pas de changement de forme de représentation (on n'a pas besoin de faire: extraire de la base SQL, transformer en array, faire le traitement, transformer de nouveau en chaîne, insérer dans la base SQL).
Avec un schéma normalisé, il n'y a aucun des ces traitements à faire. Et on a une base utilisable sans devoir passer par du code PHP.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Bruno Desthuilliers
Olivier Masson wrote:
Et UPDATE, ça sert à quoi ?
C'est jouer sur les mots ; bien évidemment, il était question d'UPDATE.
Si ton schema est correct, tu ne devrais pas voir la différence.
Alors là, c'est moi qui me permets de te corriger sur le même cas de figure que tu envisages : aujourd'hui, je ne verrais pas la différence. Mais si demain j'ai 1000 requêtes/seconde, entre un simple traitement de chaine et un UPDATE, je peux déjà te dire - pour avoir fait des benchmark là-dessus - que je gagnerais *beaucoup* en vitesse à passer par la variable.
Tu gagnerais aussi beaucoup à remplacer PHP par du C ou de l'assembleur !-)
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le traitement complet de la requête HTTP) *et* des enjeux (pour la personne/société utilisant ce code), est-ce que cette différence est critique au point de justifier la dénormalisation du schema ? Si oui, alors la bonne solution est certainement à chercher ailleurs (choix du SGBDR et du hardware), et il y aura certainement les moyens nécessaires pour mettre en place cette solution. Comme disait l'autre, "premature optimisation is the root of all evil".
Ai-je dis que c'était atroce ? Je ne parles pas de la représentation de tes données en PHP durant l'exécution de ton script, mais du schema de la base relationelle.
Là ok, mais ce n'était pas vraiment le but de ma question. Savoir à quoi peut servir un SGBDR et comment l'utiliser, c'est une question que j'aurais posée sur f.c.a.sgbd.
Excuse-moi, mais : """ (...) je voulais savoir comment mieux faire (sans utiliser d'array ? en utilisant mieux MySQL ? (...) """
Une base relationelle est bien plus qu'un moyen de persistence.
Oui, et alors ? Puisque, en l'occurrence, je n'ai et n'aurai besoin que de ça.
Tu n'en a pas besoin actuellement. Quant à affirmer que tu n'en *aura* pas besoin, ça contredit largement mon expérience...
Comme tu le dis, 'Pour le moment...',
!-)
mais il suffisait de donner ça comme argument, pas de m'expliquer qu'une base de données, c'est mieux qu'une variable (alors que ça n'a aucun rapport).
Tu peux me préciser à quel endroit de quel thread j'"explique" une chose pareille ?
Et là, ça me fait réfléchir.
Je pourrais utiliser des fichiers, mais je n'aime pas ça.
Pourquoi ?-)
Parce que j'ai toujours considéré ça comme trop long et pas assez sûr. Mais je me trompe probablement.
Dépends du cas d'utilisation... En lecture, j'ai pas encore vu mieux qu'une bête page statique !-) Mais si tu dois gérer des accès concurrents en écriture, le filesystem, c'est effectivement un poil limité...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Olivier Masson wrote:
Et UPDATE, ça sert à quoi ?
C'est jouer sur les mots ; bien évidemment, il était question d'UPDATE.
Si ton schema est correct, tu ne devrais pas voir la différence.
Alors là, c'est moi qui me permets de te corriger sur le même cas de
figure que tu envisages : aujourd'hui, je ne verrais pas la différence.
Mais si demain j'ai 1000 requêtes/seconde, entre un simple traitement de
chaine et un UPDATE, je peux déjà te dire - pour avoir fait des
benchmark là-dessus - que je gagnerais *beaucoup* en vitesse à passer
par la variable.
Tu gagnerais aussi beaucoup à remplacer PHP par du C ou de l'assembleur !-)
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le
traitement complet de la requête HTTP) *et* des enjeux (pour la
personne/société utilisant ce code), est-ce que cette différence est
critique au point de justifier la dénormalisation du schema ? Si oui,
alors la bonne solution est certainement à chercher ailleurs (choix du
SGBDR et du hardware), et il y aura certainement les moyens nécessaires
pour mettre en place cette solution. Comme disait l'autre, "premature
optimisation is the root of all evil".
Ai-je dis que c'était atroce ? Je ne parles pas de la représentation de
tes données en PHP durant l'exécution de ton script, mais du schema de
la base relationelle.
Là ok, mais ce n'était pas vraiment le but de ma question.
Savoir à quoi peut servir un SGBDR et comment l'utiliser, c'est une
question que j'aurais posée sur f.c.a.sgbd.
Excuse-moi, mais :
"""
(...) je voulais savoir comment mieux faire (sans utiliser d'array ? en
utilisant mieux MySQL ? (...)
"""
Une base relationelle est bien plus qu'un moyen de persistence.
Oui, et alors ? Puisque, en l'occurrence, je n'ai et n'aurai besoin que
de ça.
Tu n'en a pas besoin actuellement. Quant à affirmer que tu n'en *aura*
pas besoin, ça contredit largement mon expérience...
Comme tu le dis, 'Pour le moment...',
!-)
mais il suffisait de donner ça
comme argument, pas de m'expliquer qu'une base de données, c'est mieux
qu'une variable (alors que ça n'a aucun rapport).
Tu peux me préciser à quel endroit de quel thread j'"explique" une chose
pareille ?
Et là, ça me fait
réfléchir.
Je
pourrais utiliser des fichiers, mais je n'aime pas ça.
Pourquoi ?-)
Parce que j'ai toujours considéré ça comme trop long et pas assez sûr.
Mais je me trompe probablement.
Dépends du cas d'utilisation... En lecture, j'ai pas encore vu mieux
qu'une bête page statique !-) Mais si tu dois gérer des accès
concurrents en écriture, le filesystem, c'est effectivement un poil
limité...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
C'est jouer sur les mots ; bien évidemment, il était question d'UPDATE.
Si ton schema est correct, tu ne devrais pas voir la différence.
Alors là, c'est moi qui me permets de te corriger sur le même cas de figure que tu envisages : aujourd'hui, je ne verrais pas la différence. Mais si demain j'ai 1000 requêtes/seconde, entre un simple traitement de chaine et un UPDATE, je peux déjà te dire - pour avoir fait des benchmark là-dessus - que je gagnerais *beaucoup* en vitesse à passer par la variable.
Tu gagnerais aussi beaucoup à remplacer PHP par du C ou de l'assembleur !-)
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le traitement complet de la requête HTTP) *et* des enjeux (pour la personne/société utilisant ce code), est-ce que cette différence est critique au point de justifier la dénormalisation du schema ? Si oui, alors la bonne solution est certainement à chercher ailleurs (choix du SGBDR et du hardware), et il y aura certainement les moyens nécessaires pour mettre en place cette solution. Comme disait l'autre, "premature optimisation is the root of all evil".
Ai-je dis que c'était atroce ? Je ne parles pas de la représentation de tes données en PHP durant l'exécution de ton script, mais du schema de la base relationelle.
Là ok, mais ce n'était pas vraiment le but de ma question. Savoir à quoi peut servir un SGBDR et comment l'utiliser, c'est une question que j'aurais posée sur f.c.a.sgbd.
Excuse-moi, mais : """ (...) je voulais savoir comment mieux faire (sans utiliser d'array ? en utilisant mieux MySQL ? (...) """
Une base relationelle est bien plus qu'un moyen de persistence.
Oui, et alors ? Puisque, en l'occurrence, je n'ai et n'aurai besoin que de ça.
Tu n'en a pas besoin actuellement. Quant à affirmer que tu n'en *aura* pas besoin, ça contredit largement mon expérience...
Comme tu le dis, 'Pour le moment...',
!-)
mais il suffisait de donner ça comme argument, pas de m'expliquer qu'une base de données, c'est mieux qu'une variable (alors que ça n'a aucun rapport).
Tu peux me préciser à quel endroit de quel thread j'"explique" une chose pareille ?
Et là, ça me fait réfléchir.
Je pourrais utiliser des fichiers, mais je n'aime pas ça.
Pourquoi ?-)
Parce que j'ai toujours considéré ça comme trop long et pas assez sûr. Mais je me trompe probablement.
Dépends du cas d'utilisation... En lecture, j'ai pas encore vu mieux qu'une bête page statique !-) Mais si tu dois gérer des accès concurrents en écriture, le filesystem, c'est effectivement un poil limité...
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Olivier Masson
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le traitement complet de la requête HTTP) *et* des enjeux (pour la personne/société utilisant ce code), est-ce que cette différence est critique au point de justifier la dénormalisation du schema ? Si oui, alors la bonne solution est certainement à chercher ailleurs (choix du SGBDR et du hardware), et il y aura certainement les moyens nécessaires pour mettre en place cette solution. Comme disait l'autre, "premature optimisation is the root of all evil".
Oui, tu as raison. Ta phrase en anglais représente tout ce que j'essaie de faire... Faudrait donc que je commence à être plus sérieux :)
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le
traitement complet de la requête HTTP) *et* des enjeux (pour la
personne/société utilisant ce code), est-ce que cette différence est
critique au point de justifier la dénormalisation du schema ? Si oui,
alors la bonne solution est certainement à chercher ailleurs (choix du
SGBDR et du hardware), et il y aura certainement les moyens nécessaires
pour mettre en place cette solution. Comme disait l'autre, "premature
optimisation is the root of all evil".
Oui, tu as raison. Ta phrase en anglais représente tout ce que j'essaie
de faire... Faudrait donc que je commence à être plus sérieux :)
Sérieusement; compte tenu de tout ce qui rentre en jeu (dans le traitement complet de la requête HTTP) *et* des enjeux (pour la personne/société utilisant ce code), est-ce que cette différence est critique au point de justifier la dénormalisation du schema ? Si oui, alors la bonne solution est certainement à chercher ailleurs (choix du SGBDR et du hardware), et il y aura certainement les moyens nécessaires pour mettre en place cette solution. Comme disait l'autre, "premature optimisation is the root of all evil".
Oui, tu as raison. Ta phrase en anglais représente tout ce que j'essaie de faire... Faudrait donc que je commence à être plus sérieux :)
Bruno Desthuilliers
Olivier Masson wrote:
(snip)
Oui, tu as raison.
Toujours !
... Sauf quand j'ai tort, bien sûr !-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Olivier Masson wrote:
(snip)
Oui, tu as raison.
Toujours !
... Sauf quand j'ai tort, bien sûr !-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
