Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jerome PAULIN
J-F Portala wrote:
BOnjour, je travaille actuellement avec mysql php et apache.
Je voudrais migrer vers fierbird (en remplacement de mysql).
Quelqu'un a t il une experience sur ce type de migration ou plus simplement sur l'utilisation de firebird avec php.
Merci de vos reponses. Jeff
Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les sous requetes, les triggers, les transactions et les procedures stockées). Tu vas grandement simplifier ton code PHP (séparation de la logique metier et de l'affichage) et y gagner en performance (il n'y a aucune comparaison possible, tant l'ecart est grand, entre un traitement sequentiel des données (remplacement d'une sous requetes en MySQL) et la même chose via une procédure stockée).
gg
J-F Portala wrote:
BOnjour,
je travaille actuellement avec mysql php et apache.
Je voudrais migrer vers fierbird (en remplacement de mysql).
Quelqu'un a t il une experience sur ce type de migration ou plus simplement
sur l'utilisation de firebird avec php.
Merci de vos reponses.
Jeff
Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc
pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers
Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une
partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les
sous requetes, les triggers, les transactions et les procedures
stockées). Tu vas grandement simplifier ton code PHP (séparation de la
logique metier et de l'affichage) et y gagner en performance (il n'y a
aucune comparaison possible, tant l'ecart est grand, entre un traitement
sequentiel des données (remplacement d'une sous requetes en MySQL) et la
même chose via une procédure stockée).
BOnjour, je travaille actuellement avec mysql php et apache.
Je voudrais migrer vers fierbird (en remplacement de mysql).
Quelqu'un a t il une experience sur ce type de migration ou plus simplement sur l'utilisation de firebird avec php.
Merci de vos reponses. Jeff
Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les sous requetes, les triggers, les transactions et les procedures stockées). Tu vas grandement simplifier ton code PHP (séparation de la logique metier et de l'affichage) et y gagner en performance (il n'y a aucune comparaison possible, tant l'ecart est grand, entre un traitement sequentiel des données (remplacement d'une sous requetes en MySQL) et la même chose via une procédure stockée).
gg
J-F Portala
Merci de ta réponse. J'ai consulté la doc PHP et il semble que les mêmes fonctions soient utilisées pour Firebird et Interbase.
Qu'entends tu par séparation logique métier et affichage?
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une requête séquentielle en Mysql et une procédure stockée en firebird. (Est ce que la notion de sous requete correspond au découpage d'une requête en plusieurs?)
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai pas été convaincu par InnoDB). (Lorsque j'archive une partie des tables dans des tables d'archivage, je suis obligé de faire plusieurs requêtes, tester la validité de la requête et revenir en arrière si une requête n'a pu s'effectuer. Cela devient rapidement tres lours à gérer. Normalement, les transactions devraient pouvoir simplifier tout cela.
J'ai une dernière question concernant les jointures. Je me suis aperçu que Mysql était un peu lent sur les jointures. J'utilise des tables avec des codes représentant des noms. Sur certaines requêtes, je devais d'abord faire les calculs sur la table avec les codes (entiers) dans une table temporaire, puis j'utilise une autre requête avec des jointures pour obtenir les noms. Qu'en est il avec Firebird? (peut -être y a t il des possibilites d'optimisation dans Mysql que je ne maîtrise pas).
Encore merci de ton aide Jeff
Jerome PAULIN a écrit dans le message : cma7af$c6t$
J-F Portala wrote: > BOnjour, > je travaille actuellement avec mysql php et apache. > > Je voudrais migrer vers fierbird (en remplacement de mysql). > > Quelqu'un a t il une experience sur ce type de migration ou plus
simplement
> sur l'utilisation de firebird avec php. > > Merci de vos reponses. > Jeff > > Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les sous requetes, les triggers, les transactions et les procedures stockées). Tu vas grandement simplifier ton code PHP (séparation de la logique metier et de l'affichage) et y gagner en performance (il n'y a aucune comparaison possible, tant l'ecart est grand, entre un traitement sequentiel des données (remplacement d'une sous requetes en MySQL) et la même chose via une procédure stockée).
gg
Merci de ta réponse.
J'ai consulté la doc PHP et il semble que les mêmes fonctions soient
utilisées pour
Firebird et Interbase.
Qu'entends tu par séparation logique métier et affichage?
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une
requête séquentielle en Mysql et une procédure stockée en firebird.
(Est ce que la notion de sous requete correspond au découpage d'une requête
en plusieurs?)
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai
pas été convaincu par InnoDB).
(Lorsque j'archive une partie des tables dans des tables d'archivage, je
suis obligé de faire plusieurs requêtes, tester
la validité de la requête et revenir en arrière si une requête n'a pu
s'effectuer. Cela devient rapidement tres lours à gérer.
Normalement, les transactions devraient pouvoir simplifier tout cela.
J'ai une dernière question concernant les jointures. Je me suis aperçu que
Mysql était un peu lent sur les jointures.
J'utilise des tables avec des codes représentant des noms. Sur certaines
requêtes, je devais d'abord faire les calculs
sur la table avec les codes (entiers) dans une table temporaire, puis
j'utilise une autre requête avec des jointures pour obtenir les noms.
Qu'en est il avec Firebird? (peut -être y a t il des possibilites
d'optimisation dans Mysql que je ne maîtrise pas).
Encore merci de ton aide
Jeff
Jerome PAULIN <jerome.paulin.no_spam.please@groupe-emi.fr> a écrit dans le
message : cma7af$c6t$1@s5.feed.news.oleane.net...
J-F Portala wrote:
> BOnjour,
> je travaille actuellement avec mysql php et apache.
>
> Je voudrais migrer vers fierbird (en remplacement de mysql).
>
> Quelqu'un a t il une experience sur ce type de migration ou plus
simplement
> sur l'utilisation de firebird avec php.
>
> Merci de vos reponses.
> Jeff
>
>
Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc
pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers
Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une
partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les
sous requetes, les triggers, les transactions et les procedures
stockées). Tu vas grandement simplifier ton code PHP (séparation de la
logique metier et de l'affichage) et y gagner en performance (il n'y a
aucune comparaison possible, tant l'ecart est grand, entre un traitement
sequentiel des données (remplacement d'une sous requetes en MySQL) et la
même chose via une procédure stockée).
Merci de ta réponse. J'ai consulté la doc PHP et il semble que les mêmes fonctions soient utilisées pour Firebird et Interbase.
Qu'entends tu par séparation logique métier et affichage?
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une requête séquentielle en Mysql et une procédure stockée en firebird. (Est ce que la notion de sous requete correspond au découpage d'une requête en plusieurs?)
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai pas été convaincu par InnoDB). (Lorsque j'archive une partie des tables dans des tables d'archivage, je suis obligé de faire plusieurs requêtes, tester la validité de la requête et revenir en arrière si une requête n'a pu s'effectuer. Cela devient rapidement tres lours à gérer. Normalement, les transactions devraient pouvoir simplifier tout cela.
J'ai une dernière question concernant les jointures. Je me suis aperçu que Mysql était un peu lent sur les jointures. J'utilise des tables avec des codes représentant des noms. Sur certaines requêtes, je devais d'abord faire les calculs sur la table avec les codes (entiers) dans une table temporaire, puis j'utilise une autre requête avec des jointures pour obtenir les noms. Qu'en est il avec Firebird? (peut -être y a t il des possibilites d'optimisation dans Mysql que je ne maîtrise pas).
Encore merci de ton aide Jeff
Jerome PAULIN a écrit dans le message : cma7af$c6t$
J-F Portala wrote: > BOnjour, > je travaille actuellement avec mysql php et apache. > > Je voudrais migrer vers fierbird (en remplacement de mysql). > > Quelqu'un a t il une experience sur ce type de migration ou plus
simplement
> sur l'utilisation de firebird avec php. > > Merci de vos reponses. > Jeff > > Salut,
Firebird est grandement compatible avec Interbase, tu devrais donc pouvoir utiliser le client Interbase de PHP.
Il n'y a pas de soucis majeur pour migrer les données de mySQL vers Firebird (du moins, dans mon cas il n'y a pas eu de soucis).
A mon avis, il ne faut pas simplement migrer les données, mais aussi une partie de l'applicatif PHP (en gros, tout ce qui te sert a simuler les sous requetes, les triggers, les transactions et les procedures stockées). Tu vas grandement simplifier ton code PHP (séparation de la logique metier et de l'affichage) et y gagner en performance (il n'y a aucune comparaison possible, tant l'ecart est grand, entre un traitement sequentiel des données (remplacement d'une sous requetes en MySQL) et la même chose via une procédure stockée).
gg
Jerome PAULIN
J-F Portala wrote:
Merci de ta réponse.
De rien, je suis bien content quand on me repond, du coup j'essaye de repondre quand je peux
Qu'entends tu par séparation logique métier et affichage?
J'essaye de coder la logique métier (les traitements) sur mon serveur (sous forme de procedures stockées dans mon cas), du coup le programme client ne s'occupe plus que de la présentation des données (formatage, controles de coherence). Ca permet de facilement ecrire plusieurs versions du programme client (par exemple, un programme en Delphi pour l'utilisation sur le réseau local et un autre simplifié en php pour les clients web), tout en facilitant la maintenance (pour mofifier un traitement, j'ai juste besoin de modifier une procedure stockée).
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une requête séquentielle en Mysql et une procédure stockée en firebird. (Est ce que la notion de sous requete correspond au découpage d'une requête en plusieurs?)
exemple : je souhaite imprimer des etiquettes UC (carton), et j'ai besoin des N° des etiquettes pour imprimer un recap de ma palette.
Si j'ai besoin de faire 100 etiquettes, il faut que je fasse 200 requetes en MySQL (100 requetes pour creer l'etiquette + 100 requeteq pour recuperer le numero), donc 200 aller/retour entre mon serveur et mon serveur MySQl.
Avec Firebird, j'ai créé une procedure cree_etiquette(reference) qui cree l'etiquette et retourne le numero d'etiquette. J'ai ensuite cree une seconde procedure cree_serie_etiquette(nonbre_etiq,reference) qui appelle cree_etiquette(reference) autant de fois qu'il le faut et qui retourne la liste des etiquettes qui ont ete créées. Ainsi en 1 aller retour, j'ai cree et recupere tout ce qu'il me faut, sans que cela ne depende de la puissance de mon poste (ou de mon serveur php).
Sur une base en reseau local ce n'est pas tres significatif, pas contre sur une base distante (via une LS a 256 Kb/s dans mon cas), c'est la nuit et le jour (facteur de gain de l'ordre de 100)!!!
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai pas été convaincu par InnoDB). (Lorsque j'archive une partie des tables dans des tables d'archivage, je suis obligé de faire plusieurs requêtes, tester la validité de la requête et revenir en arrière si une requête n'a pu s'effectuer. Cela devient rapidement tres lours à gérer. Normalement, les transactions devraient pouvoir simplifier tout cela.
Les transactions sont faites pour ca (commit pour valider, rollback pour annuler les modifications). Je ne peux pas te parlet de INNODB, j'ai jamais utilisé.
J'ai une dernière question concernant les jointures. Je me suis aperçu que Mysql était un peu lent sur les jointures. J'utilise des tables avec des codes représentant des noms. Sur certaines requêtes, je devais d'abord faire les calculs sur la table avec les codes (entiers) dans une table temporaire, puis j'utilise une autre requête avec des jointures pour obtenir les noms. Qu'en est il avec Firebird? (peut -être y a t il des possibilites d'optimisation dans Mysql que je ne maîtrise pas).
Je ne trouve pas MySQL specialement lent dans le jointures, le tout est de mettre en place des index pertinents. Du coté Firebird, je n'ai rien constaté d'anormalement lent.
Encore merci de ton aide
De rien, si ca peut t'aider.
gg
J-F Portala wrote:
Merci de ta réponse.
De rien, je suis bien content quand on me repond, du coup j'essaye de
repondre quand je peux
Qu'entends tu par séparation logique métier et affichage?
J'essaye de coder la logique métier (les traitements) sur mon serveur
(sous forme de procedures stockées dans mon cas), du coup le programme
client ne s'occupe plus que de la présentation des données (formatage,
controles de coherence). Ca permet de facilement ecrire plusieurs
versions du programme client (par exemple, un programme en Delphi pour
l'utilisation sur le réseau local et un autre simplifié en php pour les
clients web), tout en facilitant la maintenance (pour mofifier un
traitement, j'ai juste besoin de modifier une procedure stockée).
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une
requête séquentielle en Mysql et une procédure stockée en firebird.
(Est ce que la notion de sous requete correspond au découpage d'une requête
en plusieurs?)
exemple : je souhaite imprimer des etiquettes UC (carton), et j'ai
besoin des N° des etiquettes pour imprimer un recap de ma palette.
Si j'ai besoin de faire 100 etiquettes, il faut que je fasse 200
requetes en MySQL (100 requetes pour creer l'etiquette + 100 requeteq
pour recuperer le numero), donc 200 aller/retour entre mon serveur et
mon serveur MySQl.
Avec Firebird, j'ai créé une procedure cree_etiquette(reference) qui
cree l'etiquette et retourne le numero d'etiquette. J'ai ensuite cree
une seconde procedure cree_serie_etiquette(nonbre_etiq,reference) qui
appelle cree_etiquette(reference) autant de fois qu'il le faut et qui
retourne la liste des etiquettes qui ont ete créées. Ainsi en 1 aller
retour, j'ai cree et recupere tout ce qu'il me faut, sans que cela ne
depende de la puissance de mon poste (ou de mon serveur php).
Sur une base en reseau local ce n'est pas tres significatif, pas contre
sur une base distante (via une LS a 256 Kb/s dans mon cas), c'est la
nuit et le jour (facteur de gain de l'ordre de 100)!!!
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai
pas été convaincu par InnoDB).
(Lorsque j'archive une partie des tables dans des tables d'archivage, je
suis obligé de faire plusieurs requêtes, tester
la validité de la requête et revenir en arrière si une requête n'a pu
s'effectuer. Cela devient rapidement tres lours à gérer.
Normalement, les transactions devraient pouvoir simplifier tout cela.
Les transactions sont faites pour ca (commit pour valider, rollback pour
annuler les modifications). Je ne peux pas te parlet de INNODB, j'ai
jamais utilisé.
J'ai une dernière question concernant les jointures. Je me suis aperçu que
Mysql était un peu lent sur les jointures.
J'utilise des tables avec des codes représentant des noms. Sur certaines
requêtes, je devais d'abord faire les calculs
sur la table avec les codes (entiers) dans une table temporaire, puis
j'utilise une autre requête avec des jointures pour obtenir les noms.
Qu'en est il avec Firebird? (peut -être y a t il des possibilites
d'optimisation dans Mysql que je ne maîtrise pas).
Je ne trouve pas MySQL specialement lent dans le jointures, le tout est
de mettre en place des index pertinents.
Du coté Firebird, je n'ai rien constaté d'anormalement lent.
De rien, je suis bien content quand on me repond, du coup j'essaye de repondre quand je peux
Qu'entends tu par séparation logique métier et affichage?
J'essaye de coder la logique métier (les traitements) sur mon serveur (sous forme de procedures stockées dans mon cas), du coup le programme client ne s'occupe plus que de la présentation des données (formatage, controles de coherence). Ca permet de facilement ecrire plusieurs versions du programme client (par exemple, un programme en Delphi pour l'utilisation sur le réseau local et un autre simplifié en php pour les clients web), tout en facilitant la maintenance (pour mofifier un traitement, j'ai juste besoin de modifier une procedure stockée).
J'ai un peu de mal à comprendre l'écart qu'il pourrait y avoir entre une requête séquentielle en Mysql et une procédure stockée en firebird. (Est ce que la notion de sous requete correspond au découpage d'une requête en plusieurs?)
exemple : je souhaite imprimer des etiquettes UC (carton), et j'ai besoin des N° des etiquettes pour imprimer un recap de ma palette.
Si j'ai besoin de faire 100 etiquettes, il faut que je fasse 200 requetes en MySQL (100 requetes pour creer l'etiquette + 100 requeteq pour recuperer le numero), donc 200 aller/retour entre mon serveur et mon serveur MySQl.
Avec Firebird, j'ai créé une procedure cree_etiquette(reference) qui cree l'etiquette et retourne le numero d'etiquette. J'ai ensuite cree une seconde procedure cree_serie_etiquette(nonbre_etiq,reference) qui appelle cree_etiquette(reference) autant de fois qu'il le faut et qui retourne la liste des etiquettes qui ont ete créées. Ainsi en 1 aller retour, j'ai cree et recupere tout ce qu'il me faut, sans que cela ne depende de la puissance de mon poste (ou de mon serveur php).
Sur une base en reseau local ce n'est pas tres significatif, pas contre sur une base distante (via une LS a 256 Kb/s dans mon cas), c'est la nuit et le jour (facteur de gain de l'ordre de 100)!!!
Je souhaite aussi migrer vers une base possédant des transactions (je n'ai pas été convaincu par InnoDB). (Lorsque j'archive une partie des tables dans des tables d'archivage, je suis obligé de faire plusieurs requêtes, tester la validité de la requête et revenir en arrière si une requête n'a pu s'effectuer. Cela devient rapidement tres lours à gérer. Normalement, les transactions devraient pouvoir simplifier tout cela.
Les transactions sont faites pour ca (commit pour valider, rollback pour annuler les modifications). Je ne peux pas te parlet de INNODB, j'ai jamais utilisé.
J'ai une dernière question concernant les jointures. Je me suis aperçu que Mysql était un peu lent sur les jointures. J'utilise des tables avec des codes représentant des noms. Sur certaines requêtes, je devais d'abord faire les calculs sur la table avec les codes (entiers) dans une table temporaire, puis j'utilise une autre requête avec des jointures pour obtenir les noms. Qu'en est il avec Firebird? (peut -être y a t il des possibilites d'optimisation dans Mysql que je ne maîtrise pas).
Je ne trouve pas MySQL specialement lent dans le jointures, le tout est de mettre en place des index pertinents. Du coté Firebird, je n'ai rien constaté d'anormalement lent.
