Parts de marché : OS X en hausse, Windows en baisse

tampigns a écrit:

taigaIV a écrit:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

Donc à chaque fois tu réinventes la roue?
(encore que j'imagine que vous avez une classe de gestion de données.)

taigaIV a écrit:

tampigns a écrit:

taigaIV a écrit:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

Donc à chaque fois tu réinventes la roue?
(encore que j'imagine que vous avez une classe de gestion de données.)

On a deja eu suffisament de mal avec l eau chaude et le fils a couper le beurre, pour la roue on essais de limiter.

megadub a écrit:
Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

tampigns a écrit:

taigaIV a écrit:

tampigns a écrit:

taigaIV a écrit:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

Donc à chaque fois tu réinventes la roue?
(encore que j'imagine que vous avez une classe de gestion de données.)

On a deja eu suffisament de mal avec l eau chaude et le fils a couper le beurre, pour la roue on essais de limiter.

:kaola:

---

Je vois cependant que :

avantages :
Tu maitrises ton code
=> le jour où la fonction dégage tu l'as toujours
=> tu connais le fonctionnement de ta fonction

Désavantages:
Tu dois développer et maintenir le code
Tu "alourdis" ton application
Tu ne bénéficies pas des optimisation internes à la BDD

Après c'est une question de choix mais les failles ont plus de chance de venir de ton bout de code que de la BDD (du fait du nombre d'utilisateurs) donc sur des applications critiques :/

taigaIV a écrit:

tampigns a écrit:

taigaIV a écrit:

tampigns a écrit:

taigaIV a écrit:

megadub a écrit:

taigaIV a écrit:

Je ne vais pas faire de mal a tes illusions, je vais te laisser tranquillement penser qu'il n y a que ton petit monde qui existe et qu'il n'y a pas d'autres niveaux. Les problematique que tu as avec Oracle ne sont pas automatiquement generique, perso j utilises MySQL, je fais de la replication circulaire et ca marche tres bien.

Plutôt que de buter bêtement c'est pas plus intéressant de discuter ? :heink:

Tu la fais comment ta répli circulaire ? maitre - esclave, maitre - maitre, autre ? J'aimerai comprendre si c'est pas trop demander ? Si tu veux juste troller et asséner TES vérités, effectivement ça sert à rien de répondre...

Sinon, la problématique de conflit c'est pas propre à Oracle :neutre:

---

Pour rappel :

taigaIV a écrit:

megadub a écrit:

Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Des conflits ?

Si tu t'en tapes pourquoi tu poses la question :fou:

Il y a un moment ou discuter devient passablement penible, surtout avec le concours de qui a la plus grosses et un paquet de troll qui trainnent dans le coins.
Dans le cadre de le replication circulaire tu n as pas franchement de notion de maitre et d esclave (disons qu ils sont tous maitre/escalve les uns pour les autres).
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

Donc à chaque fois tu réinventes la roue?
(encore que j'imagine que vous avez une classe de gestion de données.)

On a deja eu suffisament de mal avec l eau chaude et le fils a couper le beurre, pour la roue on essais de limiter.

:kaola:

---

Je vois cependant que :

avantages :
Tu maitrises ton code
=> le jour où la fonction dégage tu l'as toujours
=> tu connais le fonctionnement de ta fonction

Désavantages:
Tu dois développer et maintenir le code
Tu "alourdis" ton application
Tu ne bénéficies pas des optimisation internes à la BDD

Après c'est une question de choix mais les failles ont plus de chance de venir de ton bout de code que de la BDD (du fait du nombre d'utilisateurs) donc sur des applications critiques :/

En t organisant bien (surtout les donnees et l appli) ce n est finalement pas si complique que ca.

gentoux a écrit:
Moi je trouve taigaIV beaucoup plus convaincant que megadub. C'est évident que megadub a picoré au hasard des concepts d'administration de BD pour ensuite "dire" qu'ils étaient "mieux" sur oracle.
ex :

megadub a écrit:
Pour moi, ce qui fait la différence c'est :
- gestion du partitionnement et sous-partitionnement avec un parallélisme adapté
- clusterisation et haute-dispo
- gestionnaire de sauvegarde qui ne sauve que les blocs de données modifiés
- console d'administration centralisée
- robustesse de la base de données
- compatibilité SQL-92
- présence d'ordonnanceur et gestion des triggers avancé

Je constate aussi que megadub m'a cité des uses-cases oracle pour des systèmes d'information d'entreprise (la plupart étaient des solutions de partenaire d'oracle).

La belle affaire, mysql c'est souvent des applications ad-hoc confrontées au monde réel (internet) : www.mysql.com...
C'est en ça que mysql est bien plus puissant qu'oracle.

taigaIV a écrit:
Il n y a pas de notion de conflit avec My, tu auras une erreur de replication lorsqu'il ce retrouve dans une situation incoherente. La replication MySQL est tres simple, tu rejous tes requetes des maitres sur les esclaves une fois que tu le sais tu gere les problemes au niveau applicatif.

gentoux a écrit:
C'est évident que megadub a picoré au hasard des concepts d'administration de BD pour ensuite "dire" qu'ils étaient "mieux" sur oracle.

gentoux a écrit:
Je constate aussi que megadub m'a cité des uses-cases oracle pour des systèmes d'information d'entreprise (la plupart étaient des solutions de partenaire d'oracle).

gentoux a écrit:
La belle affaire, mysql c'est souvent des applications ad-hoc confrontées au monde réel (internet) : www.mysql.com...
C'est en ça que mysql est bien plus puissant qu'oracle.

jwfsmbl69 a écrit:
Mac c'est vraiment de la bombe. Mon macbook est pour moi le Meilleur portable que j'ai eu.

gentoux a écrit:

La belle affaire, mysql c'est souvent des applications ad-hoc confrontées au monde réel (internet) : www.mysql.com...
C'est en ça que mysql est bien plus puissant qu'oracle.

Franck a écrit:

gentoux a écrit:

La belle affaire, mysql c'est souvent des applications ad-hoc confrontées au monde réel (internet) : www.mysql.com...
C'est en ça que mysql est bien plus puissant qu'oracle.

:MDR trop gros, passera pas. :lol:
Tu sous-entends qu'Oracle c'est pour ceux qui font mumuse sur un coin de table :heink:

catseye a écrit:

Franck a écrit:

gentoux a écrit:

La belle affaire, mysql c'est souvent des applications ad-hoc confrontées au monde réel (internet) : www.mysql.com...
C'est en ça que mysql est bien plus puissant qu'oracle.

:MDR trop gros, passera pas. :lol:
Tu sous-entends qu'Oracle c'est pour ceux qui font mumuse sur un coin de table :heink:

Oracle c'est juste un skin d'Access.. :o

gentoux a écrit:
Moi je savais juste (préalablement a toutes ces palabres) que yahoo et google utilisent mysql pour toutes leurs applications en ligne. Rien a voir avec la paye tranquillou du mois...

megadub a écrit:

gentoux a écrit:
Moi je savais juste (préalablement a toutes ces palabres) que yahoo et google utilisent mysql pour toutes leurs applications en ligne. Rien a voir avec la paye tranquillou du mois...

bah c'est con... Yahoo c'est sous Oracle :paf:

www.wintercorp.com...

Et Google il me semblait que c'était un SGBD de leur jus [:paysan]

megadub a écrit:

Edit : apparemment c'est bien pur jus mais développé à partir de MySQL et juste quelques applis sous MySQL