J'ai vu dans le sujet " J'y comprend rien !!!! ", la remarque ci-dessous :
" Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà
l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il
existe, parce que la base de données est PREVUE POUR LE GERER"
Or, c'est actuellement ce que je fais : un SELECT systématique pour
choisir ensuite INSERT ou UPDATE.
Que je faut-il que je fasse :
- Un UPDATE systématique ?
- Autre chose ? mais quoi ?
J'ai vu dans le sujet " J'y comprend rien !!!! ", la remarque ci-dessous : (pour la prochaine fois : pose ta question dans ce thread, au lieu d'en
commencer un)
" Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER" Je confirme, vu que c'est ma prose.
Or, c'est actuellement ce que je fais : un SELECT systématique pour choisir ensuite INSERT ou UPDATE. Ca prouve que tu ne comprends pas à quoi sert une clef primaire/clef
unique. Et en plus si tu ne fais pas un BEGIN TRANSACTION avant le SELECT, en plus, tu ne comprends pas ce que sont les accès concurrentiels instantanés : rien n'empêche que ton zozo s'excite sur le bouton refresh et que tu exécutes 2 ou 3 ou 4 fois le même bout de code au même moment...
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ?
Lisez les FAQ les enfants, lisez les FAQs...
http://faqfclphp.free.fr/#rub4.5
D'ailleurs, selon la probabilité de l'existence du rang, on peut aussi faire l'insert en premier et si la clef primaire/unique explose en duplicate key violation, c'est qu'il existe déjà donc on fait l'update. Le choix de l'ordre optimal n'est qu'une question de probabilités lié à l'application.
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme de traitement d'un gestionnaire de statistiques de visites simple qui te donne, pour chaque page de ton site, le nombre de requêtes (get ou post on s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour par page, pas plus de détails (même si on pourrait généraliser avec le navigateur etc...). Moi il me faut deux requêtes et je te garantis que s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
a++; JG
Bonjour,
J'ai vu dans le sujet " J'y comprend rien !!!! ", la remarque ci-dessous :
(pour la prochaine fois : pose ta question dans ce thread, au lieu d'en
commencer un)
" Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà
l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il
existe, parce que la base de données est PREVUE POUR LE GERER"
Je confirme, vu que c'est ma prose.
Or, c'est actuellement ce que je fais : un SELECT systématique pour
choisir ensuite INSERT ou UPDATE.
Ca prouve que tu ne comprends pas à quoi sert une clef primaire/clef
unique. Et en plus si tu ne fais pas un BEGIN TRANSACTION avant le SELECT,
en plus, tu ne comprends pas ce que sont les accès concurrentiels
instantanés : rien n'empêche que ton zozo s'excite sur le bouton refresh
et que tu exécutes 2 ou 3 ou 4 fois le même bout de code au même moment...
Que je faut-il que je fasse :
- Un UPDATE systématique ?
- Autre chose ? mais quoi ?
Lisez les FAQ les enfants, lisez les FAQs...
http://faqfclphp.free.fr/#rub4.5
D'ailleurs, selon la probabilité de l'existence du rang, on peut aussi
faire l'insert en premier et si la clef primaire/unique explose en
duplicate key violation, c'est qu'il existe déjà donc on fait l'update.
Le choix de l'ordre optimal n'est qu'une question de probabilités lié à
l'application.
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme
de traitement d'un gestionnaire de statistiques de visites simple qui te
donne, pour chaque page de ton site, le nombre de requêtes (get ou post on
s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour
par page, pas plus de détails (même si on pourrait généraliser avec le
navigateur etc...). Moi il me faut deux requêtes et je te garantis que
s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
J'ai vu dans le sujet " J'y comprend rien !!!! ", la remarque ci-dessous : (pour la prochaine fois : pose ta question dans ce thread, au lieu d'en
commencer un)
" Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER" Je confirme, vu que c'est ma prose.
Or, c'est actuellement ce que je fais : un SELECT systématique pour choisir ensuite INSERT ou UPDATE. Ca prouve que tu ne comprends pas à quoi sert une clef primaire/clef
unique. Et en plus si tu ne fais pas un BEGIN TRANSACTION avant le SELECT, en plus, tu ne comprends pas ce que sont les accès concurrentiels instantanés : rien n'empêche que ton zozo s'excite sur le bouton refresh et que tu exécutes 2 ou 3 ou 4 fois le même bout de code au même moment...
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ?
Lisez les FAQ les enfants, lisez les FAQs...
http://faqfclphp.free.fr/#rub4.5
D'ailleurs, selon la probabilité de l'existence du rang, on peut aussi faire l'insert en premier et si la clef primaire/unique explose en duplicate key violation, c'est qu'il existe déjà donc on fait l'update. Le choix de l'ordre optimal n'est qu'une question de probabilités lié à l'application.
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme de traitement d'un gestionnaire de statistiques de visites simple qui te donne, pour chaque page de ton site, le nombre de requêtes (get ou post on s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour par page, pas plus de détails (même si on pourrait généraliser avec le navigateur etc...). Moi il me faut deux requêtes et je te garantis que s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
a++; JG
John GALLET
Bonjour,
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ? pas vraiment lié à php mais bon...
Limite en effet, car lié à tout algorithme de traitement client-server sgbd, entre autres php...
en mysql, Ou dans tout autre sgbdr.
on peut faire un update systematique et voir combien de "affected rows" on obtient si 0, on fait l'insert
Ou, selon la probabilité de l'existence du rang, on fait l'insert, si la pk signale que le rang existe déjà, on fait l'update. Bien sûr, cette méthode met face à leurs responsabilités les gens qui mettent des autoincrement/syb_indentity etc... partout sans contrainte unique sur la vraie clef primaire fonctionnelle de la table.
pas besoin de select donc, en effet Et c'est comme ça qu'on gagne en performances, en supprimant ce qui ne
sert à rien. Le code le plus rapide, c'est celui qu'on exécute pas.
a++; JG
Bonjour,
Que je faut-il que je fasse :
- Un UPDATE systématique ?
- Autre chose ? mais quoi ?
pas vraiment lié à php mais bon...
Limite en effet, car lié à tout algorithme de traitement client-server
sgbd, entre autres php...
en mysql,
Ou dans tout autre sgbdr.
on peut faire un update systematique et voir combien de
"affected rows" on obtient
si 0, on fait l'insert
Ou, selon la probabilité de l'existence du rang, on fait l'insert, si la
pk signale que le rang existe déjà, on fait l'update. Bien sûr, cette
méthode met face à leurs responsabilités les gens qui mettent des
autoincrement/syb_indentity etc... partout sans contrainte unique sur la
vraie clef primaire fonctionnelle de la table.
pas besoin de select donc, en effet
Et c'est comme ça qu'on gagne en performances, en supprimant ce qui ne
sert à rien. Le code le plus rapide, c'est celui qu'on exécute pas.
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ? pas vraiment lié à php mais bon...
Limite en effet, car lié à tout algorithme de traitement client-server sgbd, entre autres php...
en mysql, Ou dans tout autre sgbdr.
on peut faire un update systematique et voir combien de "affected rows" on obtient si 0, on fait l'insert
Ou, selon la probabilité de l'existence du rang, on fait l'insert, si la pk signale que le rang existe déjà, on fait l'update. Bien sûr, cette méthode met face à leurs responsabilités les gens qui mettent des autoincrement/syb_indentity etc... partout sans contrainte unique sur la vraie clef primaire fonctionnelle de la table.
pas besoin de select donc, en effet Et c'est comme ça qu'on gagne en performances, en supprimant ce qui ne
sert à rien. Le code le plus rapide, c'est celui qu'on exécute pas.
a++; JG
Philippe Chaissac
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme de traitement d'un gestionnaire de statistiques de visites simple qui te donne, pour chaque page de ton site, le nombre de requêtes (get ou post on s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour par page, pas plus de détails (même si on pourrait généraliser avec le navigateur etc...). Moi il me faut deux requêtes et je te garantis que s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
Je ferais ainsi, avec Mysql, et en version >=4.1 :
Une table stats possible (pour la page, tout dépend de ce que l'on veut stocker évidemment) :
CREATE TABLE stats ( jour INT (8) not null , page VARCHAR (255) not null , hits INT not null , PRIMARY KEY (jour, page) )
Le code de chaque page :
$page=...(selon ce que l'on veut)...; $query="INSERT INTO stats (jour,page,hits) VALUES ('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
...(exécution du query)...
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme
de traitement d'un gestionnaire de statistiques de visites simple qui te
donne, pour chaque page de ton site, le nombre de requêtes (get ou post on
s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour
par page, pas plus de détails (même si on pourrait généraliser avec le
navigateur etc...). Moi il me faut deux requêtes et je te garantis que
s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
Je ferais ainsi, avec Mysql, et en version >=4.1 :
Une table stats possible (pour la page, tout dépend de ce que l'on veut
stocker évidemment) :
CREATE TABLE stats (
jour INT (8) not null ,
page VARCHAR (255) not null ,
hits INT not null ,
PRIMARY KEY (jour, page)
)
Le code de chaque page :
$page=...(selon ce que l'on veut)...;
$query="INSERT INTO stats (jour,page,hits) VALUES
('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
Tiens, exercice d'illustration. Donner la structure SGBD et l'algorithme de traitement d'un gestionnaire de statistiques de visites simple qui te donne, pour chaque page de ton site, le nombre de requêtes (get ou post on s'en fout) par jour pour chaque jour de l'année. Juste le nombre par jour par page, pas plus de détails (même si on pourrait généraliser avec le navigateur etc...). Moi il me faut deux requêtes et je te garantis que s'il y a N hits par page, je ferai N+1 requêtes SQL, pas une de plus.
Je ferais ainsi, avec Mysql, et en version >=4.1 :
Une table stats possible (pour la page, tout dépend de ce que l'on veut stocker évidemment) :
CREATE TABLE stats ( jour INT (8) not null , page VARCHAR (255) not null , hits INT not null , PRIMARY KEY (jour, page) )
Le code de chaque page :
$page=...(selon ce que l'on veut)...; $query="INSERT INTO stats (jour,page,hits) VALUES ('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
...(exécution du query)...
John GALLET
Re,
Je ferais ainsi, avec Mysql, et en version >=4.1 : Une table stats possible (pour la page, tout dépend de ce que l'on veut stocker évidemment) : Pour ce que je demandais, ça suffit.
CREATE TABLE stats ( jour INT (8) not null , page VARCHAR (255) not null , hits INT not null , PRIMARY KEY (jour, page) ) On est d'accord. Voir entre INT et DATE puisque ça existe en mysql pour le
jour.
$query="INSERT INTO stats (jour,page,hits) VALUES ('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
Ah là tu triches avec un pseudo-trigger :-)))
Blague à part, solution intéressante même si elle est anti-naturelle. Pourrait bien être au total la plus efficace en termes de perfs (il faudrait bencher les 4 solutions pour en être sûr) car on reste dans le sgbd, mais non naturelle à mon sens (si on a N hits sur une même page, combien de fois va-t-on faire le dupvio ?)
a++; JG
Re,
Je ferais ainsi, avec Mysql, et en version >=4.1 :
Une table stats possible (pour la page, tout dépend de ce que l'on veut
stocker évidemment) :
Pour ce que je demandais, ça suffit.
CREATE TABLE stats (
jour INT (8) not null ,
page VARCHAR (255) not null ,
hits INT not null ,
PRIMARY KEY (jour, page)
)
On est d'accord. Voir entre INT et DATE puisque ça existe en mysql pour le
jour.
$query="INSERT INTO stats (jour,page,hits) VALUES
('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
Ah là tu triches avec un pseudo-trigger :-)))
Blague à part, solution intéressante même si elle est anti-naturelle.
Pourrait bien être au total la plus efficace en termes de perfs (il
faudrait bencher les 4 solutions pour en être sûr) car on reste dans le
sgbd, mais non naturelle à mon sens (si on a N hits sur une même page,
combien de fois va-t-on faire le dupvio ?)
Je ferais ainsi, avec Mysql, et en version >=4.1 : Une table stats possible (pour la page, tout dépend de ce que l'on veut stocker évidemment) : Pour ce que je demandais, ça suffit.
CREATE TABLE stats ( jour INT (8) not null , page VARCHAR (255) not null , hits INT not null , PRIMARY KEY (jour, page) ) On est d'accord. Voir entre INT et DATE puisque ça existe en mysql pour le
jour.
$query="INSERT INTO stats (jour,page,hits) VALUES ('".date('Ymd')."','$page',1) ON DUPLICATE KEY UPDATE hits=hits+1";
Ah là tu triches avec un pseudo-trigger :-)))
Blague à part, solution intéressante même si elle est anti-naturelle. Pourrait bien être au total la plus efficace en termes de perfs (il faudrait bencher les 4 solutions pour en être sûr) car on reste dans le sgbd, mais non naturelle à mon sens (si on a N hits sur une même page, combien de fois va-t-on faire le dupvio ?)
a++; JG
oragore
Or, c'est actuellement ce que je fais : un SELECT systématique pour choisir ensuite INSERT ou UPDATE.
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ?
Heuuu ? Oui en efet avec MySql autre chose est bien prevus dans ce cas Au lieu de faire INSERT INTO table VALUES ..... Faire REPLACE INTO ..... REPLACE crée l'enregistrement si la clé n'existe pas deja, ou renplace sa valeur si elle existe. Donc bien parametrer la clé primaire/unique et c'est la fete.
Or, c'est actuellement ce que je fais : un SELECT systématique pour
choisir ensuite INSERT ou UPDATE.
Que je faut-il que je fasse :
- Un UPDATE systématique ?
- Autre chose ? mais quoi ?
Heuuu ?
Oui en efet avec MySql autre chose est bien prevus dans ce cas
Au lieu de faire INSERT INTO table VALUES .....
Faire REPLACE INTO .....
REPLACE crée l'enregistrement si la clé n'existe pas deja, ou renplace sa
valeur si elle existe.
Donc bien parametrer la clé primaire/unique et c'est la fete.
Or, c'est actuellement ce que je fais : un SELECT systématique pour choisir ensuite INSERT ou UPDATE.
Que je faut-il que je fasse : - Un UPDATE systématique ? - Autre chose ? mais quoi ?
Heuuu ? Oui en efet avec MySql autre chose est bien prevus dans ce cas Au lieu de faire INSERT INTO table VALUES ..... Faire REPLACE INTO ..... REPLACE crée l'enregistrement si la clé n'existe pas deja, ou renplace sa valeur si elle existe. Donc bien parametrer la clé primaire/unique et c'est la fete.
