Discussion :

[PadaBen]

Hello tous,

Je cherche le moyen de faire ressortir des résultats par ip avec une recherche STricte.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT COUNT(id) FROM p_rate_types WHERE used_ips LIKE '%127.0.0.1%' AND id_article = '138' AND id_object = '74';

la requète fonctionne sauf que elle me renvoie aussi les résultats pour 127.0.0.12
ALors je suppose qu'il est peu probable qu'un utilisateur sur la toile est les 3 premiers groupes de caractères identiques mais sait on jamais.

j'ai tenté de faire un MATCH AGAINST ! mais du coup je ne parvenais pas à avoir de résultat car je ne connais pas le nombre exact de caractères de ma chaine.
Ah oui j'oubliais important : je cherche l'ip dans un serialize
à savoir de la forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
'a:3:{i:0;s:13:"82.254.155.71";i:1;s:13:"82.254.155.72";i:2;s:13:"82.344.155.72";}'

j'ai regardé les REGEXP, et les options de like... mais je ne parviens pas à trouver la syntaxe exacte !

avez vous des idées ?
merci du coup de pouce

B

[CinePhil]

Inutile d'entourer les valeurs numériques d'apostrophes !

recherche STricte.

Alors utilise = plutôt que LIKE !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT COUNT(id) 
FROM p_rate_types 
WHERE used_ips = '127.0.0.1' 
	AND id_article = 138 
	AND id_object = 74;

Une requête correctement indentée et aérée est plus facile à lire, à comprendre, à débugguer.

[Fred_34]

Pourquoi n'ajoutes-tu pas les guillemets ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LIKE '%"127.0.0.1"%'

[CinePhil]

Pourquoi n'ajoutes-tu pas les guillemets ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LIKE '%"127.0.0.1"%'

Je n'avais pas fait attention à cette partie du message :

Ah oui j'oubliais important : je cherche l'ip dans un serialize

Faut dire aussi que stocker un serialize, c'est tellement peu relationnel !

[PadaBen]

Je n'avais pas fait attention à cette partie du message :



Faut dire aussi que stocker un serialize, c'est tellement peu relationnel !

Hello à vous,

encore une fois oublié de demander "notification instantanée..." je confonds avec d'autres forums où c'est par défaut...
bref

Le script que j'utilise stocke en serialize les ip des votants. pour faire un check si déjà voté !

Alors ma question serait, vaut il mieux faire 1 entrée par ip ? sachant que j'ai par ip un nombre X conséquent d'entrée de votes ?
car outre le nombre d'entrées, cela augmenterai considérablement la taille de la bdd . pour 1 votant, il y aurait un nombre grandissant d'entrées !

Donc ma requête à utiliser pour un serialize serait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT COUNT(id) FROM p_rate_types WHERE used_ips LIKE '%"127.0.0.1"%' AND id_article = '138' AND id_object = '74';

Alors oui, je crois avoir essayé, mais je ne me souviens plus.
je vais ressayer et reviens vers vous

merci de l'aide et des conseils .
^^

[CinePhil]

D'après ce que je comprends, tu as, conceptuellement, une association ternaire :
ip -0,n----voter----0,n- article
objet -0,n---|

Tu devrais donc avoir une table associative qui ressemblerait à ça :
vote (vot_id_ip, vot_id_article, vot_id_objet, vot_valeur)

Comme les id sont en principe des entiers et qu'ils seront indexés puisque ce sont des clés étrangères, la recherche sera beaucoup plus rapide que d'aller chercher une IP dans une chaîne de caractères, ce qui n'utilisera jamais d'index.

Le script que j'utilise stocke en serialize les ip des votants. pour faire un check si déjà voté !

Si c'est juste pour savoir si l'utilisateur a déjà voté pour combinaison article objet qu'il a sous les yeux, tu inclus ça dans la requête qui récupère les informations qui permettent d'afficher le couple article objet. Pas besoin d'avoir tous les votants dans un serialize !

Ce n'est pas l'application qui doit commander l'architecture des données mais l'application qui doit s'adpter au modèle de données défini de manière rigoureuse au préalable !

[PadaBen]

D'après ce que je comprends, tu as, conceptuellement, une association ternaire :
ip -0,n----voter----0,n- article
objet -0,n---|

Tu devrais donc avoir une table associative qui ressemblerait à ça :
vote (vot_id_ip, vot_id_article, vot_id_objet, vot_valeur)

Comme les id sont en principe des entiers et qu'ils seront indexés puisque ce sont des clés étrangères, la recherche sera beaucoup plus rapide que d'aller chercher une IP dans une chaîne de caractères, ce qui n'utilisera jamais d'index.

Si c'est juste pour savoir si l'utilisateur a déjà voté pour combinaison article objet qu'il a sous les yeux, tu inclus ça dans la requête qui récupère les informations qui permettent d'afficher le couple article objet. Pas besoin d'avoir tous les votants dans un serialize !

Ce n'est pas l'application qui doit commander l'architecture des données mais l'application qui doit s'adpter au modèle de données défini de manière rigoureuse au préalable !

pour l'historique, j'ai pris un script présent sur le net et très utilisé que j'ai adapté à mes besoins; j'ai toujours eu un doute sur la gestion des ip, mais faut de mieux, et autres parties du code à gérer...
mais ça y est le sujet est levé

voilà ma table qui récupère les ip

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TABLE IF NOT EXISTS `p_rate_types` (
  `id` smallint(4) NOT NULL,
  `id_article` smallint(4) NOT NULL,
  `id_object` smallint(4) NOT NULL,
  `total_value` int(11) NOT NULL DEFAULT '0',
  `total_votes` int(11) NOT NULL,
  `used_ips` longtext,
  KEY `id_article` (`id_article`),
  FULLTEXT KEY `used_ips` (`used_ips`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

c'st en MyISAM car j'ai fait test de recheche avec FULLTEXT... pas concluant. mais comme j'ai lu que si il y a des select est insert majoritairement, le MyISAM est beaucoup plus rapide.

Donc je continue :
avec cette table, je supprime le used_ips
et je crée une table du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
CREATE TABLE IF NOT EXISTS `p_rate_ip` (
  `id` smallint(4) NOT NULL,
  `used_ips` int(11) NOT NULL,
  INDEX `used_ips` (`used_ips`),
  KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

où id sera id_object et non plus id_types.

qu'en penses tu ?

Correction used_ip pas en unique...mais en index , mieux non ?

[CinePhil]

Reviens aux bases, c'est à dire à la modélisation des données, en commençant par l'écriture des règles de gestion des données. Si c'est vraiment une ternaire, c'est un peu plus compliqué mais au moins tu auras le principe en lisant mon article sur le sujet.

Donc je continue :
avec cette table, je supprime le used_ips
et je crée une table du genre :

Oui peut-être, c'est un peu le principe auquel je pensais mais il manque alors une table associative pour associer les ip au reste.

Quelle est la nature de la table "p_rate_types" ? Sémantiquement, qu'est-elle censée contenir ?

[PadaBen]

Reviens aux bases, c'est à dire à la modélisation des données, en commençant par l'écriture des règles de gestion des données. Si c'est vraiment une ternaire, c'est un peu plus compliqué mais au moins tu auras le principe en lisant mon article sur le sujet.


Oui peut-être, c'est un peu le principe auquel je pensais mais il manque alors une table associative pour associer les ip au reste.

Quelle est la nature de la table "p_rate_types" ? Sémantiquement, qu'est-elle censée contenir ?

je ne pense pas qu'il y aie besoin de créer un table de laison, puisque l'id dans cette table est l'id qui fera la liaison.
la table rate_types contient la note et le nombre de vote pour tous les trios : Article / Objet / Type
mais la référence pour déterminer cela est l'objet, l'id de l'objet est UNIQUE en tout le site

pour cela au lieu d'enregistrer les ip en fonction du type, je l'enregistre en fonction de l'objet, j'ai ainsi moins de fois une ip (car un objet contient 4 à 6 types environ)

et la jointure se fera sur l'id de p_rate_ip avec l'id_objet de p_rate_types.

ça me semble jouable ainsi, non ?

ton article est bien fait, les commentaires sont instructifs. merci
je ne suis pas familiarisé du tout avec l'écriture MCD. et je t'avoue que je n'ai pas le temps , comme je l'ai déjà dit dans un autre post où tu as participé, nous devons parfois faire l'impasse sur l'approfondissement de certains domaines.
je suis conscient que de ne pas apprendre plus sur cette base de travail peut me porter à confusion, la preuve en est, si j'avais réalisé ce travail au début de ce projet, je ne serai sans doute pas au point de devoir recoder une partie du code pour que son fonctionnement soit meilleur...

en l'occurrence là, si un pro comme toi m'oriente , comme tu le fais très bien , et me dit que x solution n'est pas optimale, mais celle ci oui... alors je fais confiance aveuglément... bien sûr il y a contexte pour... t'es Modo !

Merci de tes conseils et de ta patience.
P

[CinePhil]

je ne pense pas qu'il y aie besoin de créer un table de laison, puisque l'id dans cette table est l'id qui fera la liaison.
la table rate_types contient la note et le nombre de vote pour tous les trios : Article / Objet / Type
mais la référence pour déterminer cela est l'objet, l'id de l'objet est UNIQUE en tout le site

pour cela au lieu d'enregistrer les ip en fonction du type, je l'enregistre en fonction de l'objet, j'ai ainsi moins de fois une ip (car un objet contient 4 à 6 types environ)

et la jointure se fera sur l'id de p_rate_ip avec l'id_objet de p_rate_types.

ça me semble jouable ainsi, non ?

Euh... j'ai du mal à comprendre !
Comme quoi des règles de gestions bien écrites et un bon MCD sont plus clairs !

ton article est bien fait, les commentaires sont instructifs. merci

De rien. C'est fait pour aider.

je ne suis pas familiarisé du tout avec l'écriture MCD. et je t'avoue que je n'ai pas le temps , comme je l'ai déjà dit dans un autre post où tu as participé, nous devons parfois faire l'impasse sur l'approfondissement de certains domaines.

Je peux comprendre ça, je viens de me faire allumer hier parce que j'ai posé une question sans avoir pris le temps de faire un tuto sur le PL/SQL annoncé pour 2 jours de durée !

je suis conscient que de ne pas apprendre plus sur cette base de travail peut me porter à confusion, la preuve en est, si j'avais réalisé ce travail au début de ce projet, je ne serai sans doute pas au point de devoir recoder une partie du code pour que son fonctionnement soit meilleur...

Si tu en as pris conscience, c'est déjà pas mal. Investit un peu de temps, tu verras que tu en gagneras beaucoup plus ensuite.
Surtout que c'est moins dur à mon avis que le PL/SQL et les spécificités du SQL d'Oracle !

en l'occurrence là, si un pro comme toi m'oriente , comme tu le fais très bien , et me dit que x solution n'est pas optimale, mais celle ci oui... alors je fais confiance aveuglément...

Ne jamais faire confiance aveuglément !
Les conseils n'engent que ceux qui les écoutent !
Écouter, lire, analyser, tester et adopter... ou pas !

bien sûr il y a contexte pour... t'es Modo !

Je suis un forumeur comme un autre avant tout !

[PadaBen]

Euh... j'ai du mal à comprendre !

je ne pense pas qu'il y aie besoin de créer un table de liaison, puisque l'id dans cette table est l'id qui fera la liaison.
la table rate_types contient la note et le nombre de vote pour tous les trios : Article / Objet / Type
mais la référence pour déterminer cela est l'objet, l'id de l'objet est UNIQUE en tout le site

pour cela au lieu d'enregistrer les ip en fonction du type, je l'enregistre en fonction de l'objet, j'ai ainsi moins de fois une ip (car un objet contient 4 à 6 types environ)

et la jointure se fera sur l'id de p_rate_ip avec l'id_objet de p_rate_types.

ça me semble jouable ainsi, non ?

Je suis un forumeur comme un autre avant tout !

pour ta spécificité, on a pas le même niveau quand même, clairement...
chacun ses compétences

Pour ce que tu ne saisis pas , si je te demande : Pourquoi penses-tu qu'il soit nécessaire de faire une autre table de jointure ?
vu que l'id_objet de la table p_rate_types sera reprise en id dans la table p_rate_ip ?
la jointure se faire direct ...

mais pour répondre à la question essentielle :
il est préférable donc d'avoir une autre table avec 1 ligne par ip, même si cette ligne/ip est répétée pour chaque vote d'objet ?
que de laisser en serialize ?

merci à toi
jamais à l'aveuglette, je suis d'accord, surtout sur internet, c'est aussi pr cela que je suis sur forum pro entre autre et non sur d'autres forums où tout et n'importe quoi est dit !

a te lire

[tse_jc]

Bonjour,

Une petite précision si vous me le permettez. Sous MySQL, pour faire les choses d'une manière optimisée, une adresse IPv4 se défini comme un entier INT.

Ainsi la requête deviendrait

Code MySQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT COUNT(id) FROM p_rate_types WHERE used_ips = INET_ATON('127.0.0.1') AND id_article = '138' AND id_object = '74';

Rappel du Manuel MySQL : CALCUL de l'adresse IP 209.207.224 par la fonction INET_ATON: 209*256^3 + 207*256^2 + 224*256 +40
Ce qui corresponds à un entier défini sur 4 ou 8 octets

Ce qui est beaucoup plus performant de faire une égalité sur un entier, d'autant plus s'il est indexé.
Mais bon stocker la persistance d'une classe dans MySQL, à mon humble avis, il doit y avoir du Zend la dessous. Histoire sans paroles.

++

[PadaBen]

Hello,


effectivement cette fonction php semple intéressante
ça évite de sérialiser ainsi ?

mais du coup si j'utilise cela, est il tout de même préférable que je crée une autre table avec id_object et 1 ip par ligne ?
et si il y a 10000 entrées ? cela sera t il toujours efficient ?
mieux qu'un sérialize ??

ce sont des questions que je me pose, et pour le moment un avis de personne avisée serait le bienvenu !

merci de l'aide

[tse_jc]

effectivement cette fonction php semple intéressante

INET_ATON n'est pas une fonction PHP mais MySQL.

ça évite de sérialiser ainsi ?

A mon humble avis, sérialiser une clase dans une bd, n'a de réelle pertinence que dans un contexte de brouillard de saisie temporaire et sur des données que l'on a pas besoin de requêter spécifiquement. L'enregistrement final des données devant se faire toujours dans un contexte fortement normalisé. On peut donc dire que dans 99% des cas, il vaut mieux éviter de stocker la persistence d'une sérialisation en BD et fortement normaliser son stockage, besoin d'autant plus nécessaire avec une volumétrie certaine/croissante.

[PadaBen]

INET_ATON n'est pas une fonction PHP mais MySQL.

A mon humble avis, sérialiser une clase dans une bd, n'a de réelle pertinence que dans un contexte de brouillard de saisie temporaire et sur des données que l'on a pas besoin de requêter spécifiquement. L'enregistrement final des données devant se faire toujours dans un contexte fortement normalisé. On peut donc dire que dans 99% des cas, il vaut mieux éviter de stocker la persistence d'une sérialisation en BD et fortement normaliser son stockage, besoin d'autant plus nécessaire avec une volumétrie certaine/croissante.

Donc tu me conseilles de faire 1 bd avec 1 ligne par entrée d'ip normalisée par INET_ATON ?

et donc la fonction INET_NTOA(expr) pour faire l'inverse.
d'après http://dev.mysql.com/doc/refman/5.0/...functions.html

Donc dans mon cas j'aurai une table supplémentaire avec Id_Objet et ip
dois-je mettre une clé particulière sur l'ip ? je penserai un index?

et j'enregistre une ligne par validation ?

merci de ta réponse.

[tse_jc]

Quand j'ai repris ta requête il est vrai que j'ai recopié le reste sans faire aucune correction. Comme te l'a conseillé cinephil évite de mettre les valeurs numériques entre simple quotes, c'est contre productif d'obliger le moteur de recaster implicitement et inutilement tes paramètres. Pour éviter des erreurs dans ton code PHP, il te suffit tout simplement de retyper tes variables numériques au préalable comme suit.

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$param=intval($myvalue);
//ensuite tu peux l'introduire dans ta requête comme suit
$query="SELECT * FROM MYTABLE WHERE id=$param "; // en evitant *

Ensuite, ma boule de cristal est en panne, vu que l'on a pas les informations suffisantes pour pouvoir t'aider à ce niveau, et la bonne méthodologie pour répondre à ta question de modélisation t'a été donnée par cinephil.