Reprise du message précédent :
que dire sinon que tes competences en SGBD depassent totalement les miennes
sans etre aussi calle je n'ai pas l'impression que MySQL puisse etre qualifie de produit de merde pour toutes les raisons que tu as evoque.
En revanche je suis d'accord qu'un jugement objectif ammene a la conclusion qu Access est un produit de merde

 
j'espère que tu choisis pas le SGBD en fonction de sa syntaxe LOL  
 
pour info : http://fadace.developpez.com/sgbdcmp/

Ben le seul souci, c'est qu'en plusieurs points, Access surpasse MySQL. Le principal défaut d'Access, en plus d'un moteur merdique je l'accorde, c'est qu'il est trop simple d'utilisation et que des personnes non compétentes bossent avec n'importe comment (même reproche à VB qui est pour moi un langage tout à fait honorable).
 
Nan, moi ce qui m'énerve le plus avec MySQL, c'est ce que j'ai dit à propos des bugs rémanants.
Heureusement, ils ont su éviter le truc stupide de PHP qui consiste à avoir 25 fonctions sans règle de nommage identifiables qui font toutes la même chose mais en prenant des paramètres différents. Avec MySQL il n'y a que des synonymes ou des variantes dont les différences de syntaxe restent faibles. Quant aux règles de nommage, ce sont principalement les noms des fonctions du SQL92 donc y'a pas de problème.

megadub > non, je ne choisi pas un sgbd en fonction de sa syntaxe. ceci dit, la syntaxe en dit généralement long sur le moteur qui est derrière.

 
bon tu as repris le flambeau que tu m'avais donné de la remarque la plus idiote je crois...
 
qq remarques :
- bilou est l'h le plus riche de la planete aux denieres nouvelles
- seul windows & office rapportent des sous à ms, les autres devs sont fait à pertes en attente de retour sur investissements (qui n'arriveront jms dans de nbeux domaines). Ms peut se permettre financièrement de financer 1000 développeurs à bosser sur un projet qui ne leur rapportera pas de quoi faire vivre 1000 développeurs.
 
et perso je lui reproche pas d'avoir réussi sa vie, je lui reproche juste sa manière d'avoir réussi sa vie (monopole, rachats), mais c'est une autre question, ton discours me fait peur, je retourne coder moi...
 
ps :
 pour ceux qui sont arrivé en retard et qui n'ont pas eu leur 10 min de rigolade aujourd'hui :

elle est bien bonne non ?  

 
c'est peut être aberrant quand on ne connait pas le contexte du truc, mais pour moi la priorité de rapidité est à l'enregistrement des données et non à la sélection, ou la rapidité à moins d'importance.
Or enregistrer des des infos sous forme d'arbre, c'est gourmand, très gourmand même dans mon cas

 
hein ??? Mouais... la syntaxe dépend surtout de l'éditeur et c'est loin d'être un gage de qualité... m'enfin

 
n'importe quoi... .Net et SQL Server sont TRES loin d'être anecdotique. Pour info SQL Server et le 2° plus gros SGBD (ou 1° selon les études) après Oracle... alors ça métonnerait que ça rapporte rien.
 
Renseigne toi un minimum avant d'avancer de telles choses

Sinon, je viens de lire (très rapidement) l'article que tu as posté.
 
J'ai juste un truc à dire au niveau du "y'a pas de trigger before".
En effet, mais au contraire, y'a mieu, y'a "instead of", qui est spécifique à SQL Server. Il permet de remplacer intégralement le comportement du INSERT (le BEFORE ne modifiant pas l'insertion finale).
Sinon, dans les avantages, ils ont oublié un sacré packet, genre le support de requêtage à partir de fichiers XML, la génération automatisée de pages HTML / XML à partir d'un template et d'un fichier d'instructions, la consultation / modification de tables d'un autre SGBD directement à partir d'une requête, etc. Y'en a une pagaille de trucs dans SQL Server qui nécessitent généralement, au mieu, l'installation d'un package indépendant (et souvent payant) chez les concurents.
 
Ceci dit, pour MySQL, ils se sont arrêtés à une ancienne version, la liste des inconvénients est plus courte maintenant. Mais niveau avantages, il n'a pas ceux que je viens d'indiquer pour SQL Server donc...
 
Ceci dit, ça donne une bonne idée de la chose, et ça met bien en avant un point très souvent oublié : la gratuité des version "lite" de SQL Server, qui sont très largement suffisantes dans 90% des utilisations qu'on fait des bases de données (2 CPU et 2 Go pour la taille de la base, c'est pas courant qu'on dépasse l'un des deux)

 
Objectivement, Access est très bien Suffit de savoir s'en servir Par contre, on fait très vite de la merde, faut bien faire gaffe

 
Bien sûr que le BEFORE permet de modifier l'insert... en tout cas Oracle le fait... INSTEAD t'oblige à retaper la requête en entier, c'est complétement crétin comme truc
 

 
Ca c'est clair, mais c'est pas du tout les mêmes ambitions et il y a d'autre outils pour le parsing XML
 

 
2Go c'est bite fait quand même

 
Et il faut éviter les accés concurrents et il faut éviter les grosses bases à part ça c'est pas mal

 
je t'attends :
- capital initial investi par ms ("rachat d'une boite" )
- combien de développeurs payés pendant combien d'années avant d'être rentable ?
 
je ne dis pas qu'aujourd'hui SQLServer ne gagne pas de l'argent, mais si au départ il n'y avait pas eu le géant MS derrière, ça aurait été impossible... donc je dis que FORCEMENT quand on propose un SGBD LIBRE GRATUIT et qui s'est monté SEUL comme un grand, en étant rentable dès le départ, il est PLUS DIFFICILE de proposer toutes les fonctionnalités des concurrents qui n'ont pas eu les mêmes histoires.

 
Pour avoir construit/gere puis porte vers MySQL une base Access de pres de 600MO je reitere que Access est de la merde (tout du moins pour cet usage)
 
D'autre part l'article de comparaison des SGBD n'est pas a jour du tout

Ouais enfin une base de 600 Mo, c'est sûr que c'est pas pour Access

Petite correction : au niveau des systèmes ordinaires (Serveurs à base de x86 et Alpha)
 
Pour ce qui est des gros systèmes genre ceux qu'on trouve dans les banques ou les éditeurs de statistiques (INSEE, etc.), Oracle et SQL Server, c'est deux petit shareware développés dans une cave en tchétchénie

C'est en effet ce que je disais. Mise à par un moteur plutôt limité, le gros problème d'Access (tout comme VB) c'est sa simplicité d'emplois et de programmation : n'importe qui peut pisser un bout de code en quelques minutes sans rien comprendre à ce qu'il fait et du coup ben... on fait vite de la merde. Si d'entrée de jeu on fait un truc propre, Access ou VB sont des produits tout à fait honorable (mais bon, pas comparables au C++/Java/.NET et SQL Server/Oracle, etc.)

Ben faire un "insert into latable select * from inserted" c'est quand même pas la mort
 
Par contre, le "BEFORE", même si tu vide la table temporaire "inserted", le INSERT sera réellement effectué (avec rien, donc ça n'écrira rien), mais du coup, tu va déclencher d'autres trigger s'il y en a d'autres sur la table. Le INSTEAD OF permet de contourner l'insertion, y compris ne pas la faire du tout, ne levant ainsi pas les autres triggers.
 
Ils sont plus ou moins équivalents, mais je trouve le INSTEAD OF un peu plus puissant. Dans tous les cas, l'absence de BEFORE n'est pas un inconvénient en soit.

 
Bah pour l'insee j'en sais rien mais pour les banques et assurances t'es complétement à coté de la plaque... je bosse actuellement pour une très grosse banque (install Oracle appli) et il y a pleins de bases Oracle (des filiales de cette banque aussi d'ailleurs), ma femme bosse pour une autre grosse banque, Oracle aussi, j'ai passé un entretien dans une 3° banque et un pote a bossé dans encore 2 autres banques -> 5 banques françaises sous Oracle
 
Et j'ai fait une assurance aussi

 
ce serait bien de faire les remarques au resp SGBD ou à l'auteur pour faire évoluer l'article parce qu'ici je pense que ça sert pas à grand chose

 
quand tu as un insert de 60 colonnes ça devient plus chiant sans compter que tu as 2 ordres insert à maintenir. Sinon, évidemment qu'en BEFORE tu peux "aborter" le trigger, suffit de faire un RAISE.
 
Enfin peu importe... tout ça pour dire que de ne pas avoir le BEFORE c'est pas forcément intelligent

 
c'est pas trop une remarque pour l'auteur qui a fait un travail remarquable (a l'epoque) mais plutot pour celui qui ramene des sources obsoletes
 

salo
 
j'pense que l'auteur serait quand même heureux de remettre à jour

hmmm... t'es sûr que même les bases centrales sont sous Oracle ?
En tout cas, Oracle Application, sûr et certain, c'est impossible, les banques ne font aucun changement majeur dans leur système central, et surtout pas avec un produit aussi peu éprouvé : Oracle Application n'a que 4 ou 5 ans, à raison d'un patch correctif par jour si ce n'est plus.
 
J'ai assisté de loin au déploiment de cette daube chez General Electric (toutes les filliales de GE avaient pour ordre formel de passer à Oracle Application avant fin 2004). Ce que j'ai pu voir, c'est que chaque filliale a claqué des centaines de milliers de $ (si ce n'est des millions) pour migrer leurs systèmes existants, et ça s'est soldé par trois cas de figure :
- Productivité en chute libre et besoin de revoir tous les process à cause de lacunes de cet ERP trop récent
- Abandon pur et simple de la migration et retour à l'ancien système
- Passage dans la foulée à un autre ERP répondant à leur besoins (toute une branche est passée sous SAP, au grand Damn de la direction centrale qui espérait avec Oracle Application arriver à une homogénéité parfaite de leurs SI)
 
Donc mise à part pour les guichets et autres, je doute très grandement que les banques déploient cet ERP au niveau central.

Tu vas me dire ce que je fais peut-être... Si je te le dis tu peux me croire, l'AS400 c'est fini pour pas mal de boite. Et ça fait 7 ans que je bosse sur OA alors t'es 4-5 ans ça me fait bien mourir de rire LOL :-D
 

 
J'ai participé à 4 déploiements dont le plus réussi chez un des leader de l'électroménager, tout le SI sous OA de la gestion des appels clients, à la compta en passant par la logistique. C'était pendant leur rachat par un autre groupe et pourtant tout fonctionne à merveille... je serais tenté de penser que c'était pas l'ERP qui était en cause
 
C'était une base de 400Go au démarrage je te laisse imaginer après 3 ans de fonctionnement
 
Bref... je crois qu'on parle effectivement pas des memes choses
 
Edit : au fait, c'est effectivement 2 ans de boulot une migration de SI mais faut voir un peu le taff aussi... et ça quelque soit le type de migration :-/

passer de OA à SAP... En effet, c'est un bel exemple de raté

Quand je pense qu'on était partie d'une simple question ...

Pour info, Oracle a développé un module spécifique pour les banques françaises : GL Bank
 
Comme quoi c'est loin d'être anecdotique
 
madkane -> c'est pas plus mal d'élevé un peu le débat non ?

Même si je ne mets pas spécialement en doute ta parole, je suis plutôt étonné par ce que tu nous dit là.
 
7 ans pour OA, soit. Pour moi c'est plus Oracle Forms qui a cette age là mais bon. Dans tous les cas, 7 ans pour un produit de ce type, c'est petit. D'ailleurs quand on parle de Microsoft qui est capable de faire bosser 10 000 développeurs à perte, Oracle se pose là, en quelques mois, ils ont réussi à pondre un ERP, chose qui prends en temps normal des années (et c'est plus proche de la décénie que de l'année pour arriver à un truc qui a un périmètre fonctionnel correct). Mais bon, ç'est pas dans le débat actuel.
 
Sinon, General Electric, contrairement à ce que pas mal de monde croit, ce n'est pas un contructeur de lampes et de câbles électriques. C'est la plus grande capitalisation boursière au monde, c'est plus de 1000 filliales, des centaines de milliers de produits au catalogue (ça passe du réacteur de B747 en passant par l'appareil de biopsie mamère sans oublier les produits financiers).
Niveau volume, ressources informatiques, ça dépasse, de très loin (encore un peu plus, là-bas derrière la coline, oui c'est ça) ce que pourrait se permettre BNP Paribas par exemple.
 
Pourtant, quelques points étonnants :
- Les migrations sous OA, qui sont commencées depuis plus de 3 ans maintenant, ont déjà échouées à hauteur de 50%.
- J'ai travaillé sur un autre ERP, toujours chez GE. J'étais dans une filliale qui n'était pas un leader de l'"électro-ménager, mais c'était quand même le leader européen de fournitures médicales. Et la base ben... elle atteinds poussivement les 8 Go. Pourtant, y'a pas un seul hopital ni médecin qui leur échappe, qu'il soit en Europe, en Afrique, en Asie ou en Océanie (pour les américains, l'Europe s'est tout sauf les deux continents américains, c'est simple). Pour tout dire, on s'est même fendu la poire un jour alors qu'un gourou du Sénégal demandait un devis pour "des appareils qui feraient bien et très professionel dans mon cabinet", signe que c'est la référence incontournable si on est médecin et qu'on veut des lingettes, un stétoscope ou un négatoscope.
 
Bref. Les constructeurs d'appareils d'électro-ménager ne traîtant jamais directement avec le public pour des raisons évidentes (et ça j'en sais quelque chose, j'ai travaillé pendant longtemps pour SEB qui est le leader européen, et qui est sur SAP soit dit en passant). Du coup, ton volume de 400 Go, je ne vois pas d'où il sort, même si tu gères peut-être la chaîne de production, que n'avait pas à faire la boîte ou j'étais. Ou alors c'est bien encore un point sur lequel OA est vraiment pourri. 40 Go je conçois, 400, nan, pas pour ce type de métier.
 
Sinon, va falloir que je vérifie mes sources pour les systèmes bancaires (et je ne parlais pas non plus d'AS400, je ne me souvient plus du tout du nom dont on m'avait parlé, mais des trucs totalement spécifiques aux banques).
Dans tous les cas, je reste parfaitement persuadé que les guichets ne sont pas gérés par le même système que les transactions réelles. Alors Oracle GL Bank, je ne sais pas ce que c'est, mais ça me semble plus être un frontal que le système lui-même (d'ailleurs, faire des transactions monnétaire, c'est tellement spécifique que je ne vois pas à quoi ça servirait de mettre OA dessus : il sait faire infiniment trop de choses, et le peu dont on a besoin, il le fera mal, car pas du tout prévu pour traîter des millions de transactions concurrentes de portant sur des traîtements simple. Même le moteur du SGBD lui-même est complètement mis en péril avec ce type de traîtement.
 
Enfin bon, c'est un domaine que je ne maîtrise pas du tout, la seule fois que j'ai bossé pour "une banque", il s'agissait d'une association de caution, et outre un petit système AS400, le frontal tournait avec VB5 et Access 2.0 donc on peut pas vraiment dire que ce soit un cas d'école

 
Tu n'as pas compris... ça fait 7 que moi je bosse, Oracle appli est bien plus vieux. Ca a commencé en version caractère début 80 je crois (sous Oracle 6), ensuite il y a eu la 10.5 et la 10.5 NC qui a vu apparaitre les 1° écrans clients/serveur et aujourd'hui la 11i (11.5.10) en version web. J'ai pas les dates mais je pense que OA a au moins 20 ans. C'est pas compliqué, c'est le concurrent direct de SAP (et feu JDEdwards ) et est donc aussi vieu
 

 
Tu connais les volumes de la BNP ? Pour info, aujourd'hui c'est 1.5 To de données qui sont prévues UNIQUEMENT pour la compta général : Oracle Finacial option GL Bank... c'est là que je bosse
 
 

 
Et le SAV ? Chez Brandt le SAV est géré par Brandt d'où le déploiement du module CRM chez Oracle. C'était le plus gros de la volumétrie
 

 
Entre la liste des clients, les nomenclatures (tu peux me croire, un four ou une machine à laver c'est un paquet de piéces référencés), les fournisseurs, les écritures comptables etc... 400 Go c'est pas de trop pour démarrer
 

 
 
Bon, là je ne peux pas le certifié parce que c'est pas dans ces environnements que je travaille mais à la Caisse d'Epargne et peut-être bien à la BNP c'est bel et bien du Oracle derrière d'après ce que j'ai compris. Ce serait quoi selon toi ? Même les relevés de compte sont fait sous Reports au Crédit Agricole... donc encore Oracle
 

 
Visiblement tu ne connais absolument pas Oracle. Avec SQL Server c'est le SGBD le plus robuste pour gérer les transactions concurrentes. Savez-tu que la distribution des cartes SIM ou des jeux pour portables étaient gérées sous Oracle ? Tu imagines le nombre de demandes que ça représente ? Plus impressionnant encore, la gestion des péages de ASF est sous Oracle... va sur les autoroutes du sud de la France en été et alors tu comprendras à quel point c'est robuste
 
OA est séparé en module : facturation client, facturation fournisseur, CRM, RH, etc... GL Bank est l'un de ces modules pour gérer entre autres les particularités sur les taux de changes et autres subtilités du genre. Quand à le faire mal, on est pas leader du marché en vendant de la merde
 

 
Visiblement il n'y a pas que ça que tu ne connais pas... je ne sais pas ce que tu fais mais si tu n'es pas DBA je comprends ta méprise et alors va voir tes collégues et ils t'expliqueront
Sinon... bah je sais pas où tu as bossé mais visiblement c'était pas dans de bonnes conditions

tiens un autre exemple, tout le SI de la Française des jeux est sous Oracle. Lorsque tu valides un ticket flash pour le Loto, c'est Oracle derrière

Pour info, c'est de l'Oracle aussi chez Bouygues Telecom
 
Et il me semble qu'ils ont en gros 400 millions d'appels par mois, et qu'ils conservent en base 3 mois d'historique, ça donne une idée de la taille de la base
 
Je vais bosser sur une mise à jour de leur système bientôt, car je suis dans la boîte qui l'édite

 
ouch... bon courage

Bah, je m'en fais pas, je viens de bosser sur une migration bien complexe pour Romtelecom, l'équivalent de France Telecom en Roumanie ... 41 régions différentes utilisant en tout 3 systèmes de facturation, à migrer vers un nouveau système (sous Oracle là encore).

Mouais. C'est zarb, ça va à l'encontre de tout ce qu'on m'avais dit à propos d'Oracle Application et les banques.
 
Pour OA, c'est peut-être les modules dont GE avait besoin qui étaient récents alors.

peut-être, les releases majeurs (3° digit : 11.5.4, 11.5.10, etc...) ont des périodes de rodages un peu difficile. Mais l'accompagnement du support Oracle est exemplaire.
 
Ceci étant, il faut quand même mitigé le jugement : parait-il que SAP est complexe à mettre en place mais une fois que c'est fait ça tourne comme une horloge alors qu'OA nécessite beaucoup de paramétrage et de développement spécifiques qui générent des effets de bord parfois désastreux. Au bout du compte j'ai encore jamais vu de mécontent d'OA quand l'install est stabilisé
 
Beegee -> avec une bonne organisation on fait des miracles

Quand je pense que tout ceci partait d'une simple question...

oui on a compris

je trouve très désagréable le comportement de ces gens qui croient tout savoir, sans oser se remettre en question. Quelle tristesse.

si tu parles de moi, je ne connais fort heureusement pas tout et si tu parles Arjuna, il a admis ses lacunes (difficilement il est vrai lol) donc no soucy

je parle d'arjuna, dont je trouve le comportement vraiment très désagréable, hautain et fier, je n'aime pas du tout ce genre d'attitudes...
enfin nous ne sommes pas là pour faire de la psychologie