Discussion :

[SQLpro]

A titre personnel le SGBD qui a plus perdu mais parce qu'elle a pas évolué et je me demande si ça va arriver, c'est Mysql. Ceci lié au flou avec Oracle, le faite qu'ils aient abandonné Mysql 6 (Est-ce une bonne nouvelle ?), le faite que les autres aient avancés et eux sont resté sur place. Mysql 5 version stable date de 11 ans, 11 bon sang d'années 11 !!!!!! .

Tout à fait d'accord avec toi... Le problème des gens qui ont voté MySQmerde c'est que généralement il n'ont connu aucun des autres SGBDR.... Mais je confirme. C'est le pire des SGBD... AU royaume des aveugles les borgnes sont rois !

Celui qui a bien évolué est SQL Server, je trouve que Microsoft a fait pas mal de progrès sur leur SGBD même si tout n'est pas top autour comme par exemple leur outil de reporting qui n'est pas parmi les meilleurs.

Comme Microsoft est très à l'écoute de ses utilisateurs, sache qu'il ta personnellement entendu ! La version 2016 sort avec un Reporting Services entièrement refondu.

Mon prochain os que je souhaite ronger c'est PostGresql.

Malgré ses limitations essentiellement administratives et optimisation, c'est un SGBDR que j'aime bien... Malheureusement depuis quelques années il ne suit plus la norme SQL aussi bien qu'avant. Exemple, toujours pas de MERGE mais un imbitable UPSERT !

A +

[SQLpro]

Tu parles de choses qui ne sont utilisées que par toi et peu dans la pratique pour un codeur d'applic.
Les index je sais c'est quoi, c'est pas pour autant qu'on doit indexer tous les champs, c'est juste une constatation.
Comparant Oracle dans la vie de tous les jours, je vois que MariaDb est plus cool au niveau des queries.

Autant de connerie en si eu de mot... C'est rare ! ça mérite une holla !!!!

[LSMetag]

Autant de connerie en si eu de mot... C'est rare ! ça mérite une holla !!!!

Indexer ça coûte pas grand chose, mais quand il n'y en a pas besoin sur certains champ, pas la peine de les mettre. C'est une petite optimisation, si évidemment on s'y connaît en index. Ca décharge un petit peu le SGBD.

MariaDB (version 10+) n'est pas à mettre dans le même sac que Mysql. C'est clair qu'il y a de la marge par rapport à un Oracle, SQL Server ou PostGres. Mais son utilisation est tout à fait appropriée dans bien des cas, et il est loin d'être ridicule. Et c'est vrai qu'il est plus aisé à manipuler qu'Oracle ou PostGres.

Quelques références : https://mariadb.com/blog/mariadb-10-...parison-update

Il faut noter que depuis la version 10.1.9, le InnoDB de Mysql a été abandonné au profit de Percona XtraDB, bien plus performant : https://www.percona.com/doc/percona-...a-XtraDB:start

[Chauve souris]

C'est le point très noir de tous les SGBDR libre !!!! En effet ce sont nullement de vrais sauvegardes mais des "dump". Durée gigantesque par rapport à la même base qui sous SQL Server qui fait des sauvegardes binaires.. Et en plus pas question de mettre à jour des données pendant la sauvegarde...

Tu noteras d'ailleurs une arnaque que j'aime bien...
MySQL propose des sauvegardes binaires à chaud avec la version Enterprise (payante !!! : Oracle)
PostGreSQL propose de sauvegardes binaires à chaud avec la version Enterprise (payante !!! : Enterprise DB)
Donc, c'est pas près de s'arranger, sinon ces deux boites font faillites ! C'est ce que l'on appelle un produit d'appel... Ne pas oublier que tous les développeurs du libre ont un salaire, mais au fait qui les payent ???

En fait ils ont fait le contraire de Microsoft ! Avant MySQL et PostgreSQL étaient intégralement gratuits alors que Microsoft lâchait une version très bridée de sa BDD fétiche. Les précités sont, comme tu dis justement, des produits d'appel (je suis envahi de SPAM de EntrepriseDB, en anglais de surcroît, quand je leur ai laissé mon e-mail juste pour être au courant des vraies nouveautés, un peu comme mon AVAST gratuit qui trépigne que je ne passe pas à la version payante). De l'autre côté Microsoft lâche du lest dans la gratuité et l'Open Source et on dispose d'un SQL Server Express devenu Community très puissant et qui, de surcroît, cause essentiellement français.

[Chauve souris]

Comme Microsoft est très à l'écoute de ses utilisateurs, sache qu'il ta personnellement entendu ! La version 2016 sort avec un Reporting Services entièrement refondu.

Je ne me suis pas beaucoup servi de Reporting Services mais beaucoup de Management Studio. Pourquoi l'ont-ils supprimé ? Zat ize ze couéchione

Yapuka espérer que Microsoft, dans Sa sagesse infinie, écoute mes doléances...

[Pierre GIRARD]

Le meilleur SGBD c'est celui qui répond à ce qu'on lui demande .

Tout à fait, et pour un usage personnel Firebird demeure mon préféré. Je suis en cours de téléchargement de la version 3.0 et j'ai hâte de la tester.

[SQLpro]

Je ne me suis pas beaucoup servi de Reporting Services mais beaucoup de Management Studio. Pourquoi l'ont-ils supprimé ? Zat ize ze couéchione

Yapuka espérer que Microsoft, dans Sa sagesse infinie, écoute mes doléances...

Cette séparation est voulue et mieux vaut qu'elle reste ainsi... En effet, la plupart du temps les développeurs ont pris comme mauvaise habitude d'installer SSMS sur le serveur et faire des requêtes dedans ce qui est d'une haute stupidité !
Cela fait longtemps que SSMS est installable à part dans la version Express. Et c'est mieux comme ça car cela évite l'installation systématique de tous les composants sur un serveur de production, en particulier les outils clients qui n'ont rien à faire sur un serveur !

A +

[escartefigue]

Indexer ça coûte pas grand chose, mais quand il n'y en a pas besoin sur certains champ, pas la peine de les mettre. C'est une petite optimisation, si évidemment on s'y connaît en index. Ca décharge un petit peu le SGBD.

Indexer peut couter beaucoup au contraire, et bien évidemment il ne faut en créer que là où c'est nécessaire.
Par contre dire que c'est "une petite optimisation" certainement pas ! C'est même souvent la seule façon d'obtenir une réponse dans un délai raisonnable dès que les tables contiennent autre chose que quelques centaines de lignes.
Essayez une jointure entre 2 tables contenant quelques millions de lignes, d'une part sur des colonnes non indexées ou avec un prédicat non sargable et d'autre part sur des colonnes indexées et avec un prédicat sargable vous verrez que c'est le jour et la nuit !
Le même test avec des centaines de millions de lignes ou plus n'aboutira même jamais pour la requete non indexée...

[LSMetag]

Indexer peut couter beaucoup au contraire, et bien évidemment il ne faut en créer que là où c'est nécessaire.
Par contre dire que c'est "une petite optimisation" certainement pas ! C'est même souvent la seule façon d'obtenir une réponse dans un délai raisonnable dès que les tables contiennent autre chose que quelques centaines de lignes.
Essayez une jointure entre 2 tables contenant quelques millions de lignes, d'une part sur des colonnes non indexées ou avec un prédicat non sargable et d'autre part sur des colonnes indexées et avec un prédicat sargable vous verrez que c'est le jour et la nuit !
Le même test avec des centaines de millions de lignes ou plus n'aboutira même jamais pour la requete non indexée...

Quand je parle de petite optimisation, c'est quand on choisit de ne pas mettre des index partout, c'est à dire moins d'indexs inutiles.
C'est sûr que l'index pour les jointures ou pour les recherches est une ENORME optimisation !

[Chauve souris]

Cette séparation est voulue et mieux vaut qu'elle reste ainsi... En effet, la plupart du temps les développeurs ont pris comme mauvaise habitude d'installer SSMS sur le serveur et faire des requêtes dedans ce qui est d'une haute stupidité !
Cela fait longtemps que SSMS est installable à part dans la version Express. Et c'est mieux comme ça car cela évite l'installation systématique de tous les composants sur un serveur de production, en particulier les outils clients qui n'ont rien à faire sur un serveur !

A +

OK, OK, j'accepte le principe ! Il faut donc faire rouler sa chaise d'informaticien sur le poste client le plus proche. Mais, à la différence de PgAdmin III ce SSMS est confidentiel, en anglais (et pas autre chose) et, de surcroît ininstallable. Si toi, l'oracle.... de Microsoft a un meilleur lien que celui que j'ai trouvé pour avoir un vrai SSMS, c-à-d installable et en français je suis toutouie.

[berceker united]

ça va, c'est de l'anglais informatique, rien de bien hight level quand même. Moi qui suis anglophone comme une vache alsacienne j'arrive à m'en tirer

[Chauve souris]

Ce n'est pas à moi que ça fait peur ! Des utilitaires en anglais non traduits j'en ai plein mais c'est une question de principe et ça confirme bien la précipitation chez M$ (ils ont le temps de traduire chez PostgreSQL et pas chez M$ ?). Et puis il ne faut pas faire l'impasse sur le principal de mon objection : ce SSMS ne s'installe pas ! Il est bugué car il demande des "trucs" qui n'existe pas même après une installation complète de MS SQL Server 2016 RC3 (et son JRE auquel il tient tant).

Et puis, dans la logique du SSMS séparé et installé dans des postes clients il y a de quoi décourager les utilisateurs avancés qui seraient prêts à bidouiller leurs propres bases si l'utilitaire en question ne sait pas causer français.

[DidiLogic]

Firebird pour moi en raison de mes besoins : applications packagées.
- performant en mode embarqué
- léger et facile à déployer
- très peu de configuration
- totalement gratuit
- gestion des trigger et des udf
- rapide et peu gourmand
En plus la version 3 vient d'être officialisée :-)

[Artemus24]

Salut à tous.

Faut laisser faire... ça donne plus de boulot aux experts

Plus il y a des gens qui se prennent pour des DBA et plus il y aura du boulot pour les experts. C'est juste une simple constatation que je fais, et je voie que tu partage mon opinion.

Donc si t'as les moyens tu vas acheter une magnifique Ferrari pour partir en vacances 15 jours au ski avec ta femme et tes 2 enfants ?

Je ne pense pas qu'une Ferrari a plus de deux places. Mais bon, si tu vas à Couchevel, tu ne seras pas le seul à posséder une Ferrari !

Ben bon courage

Pourquoi ? Tu as déjà essayé ?

Oui, c'est pourquoi on peut surement trouver le meilleur SGBD dans l'absolu, qui sera surement inadapté à la plupart des cas particuliers

Si c'est le meilleur SGBD, il sait traiter la plupart des cas particuliers.
Ce que je voulais dire, c'est que tu n'as pas nécessairement besoin d'avoir le meilleur SGBD pour résoudre tes problèmes.
Cela dépend aussi des autres points qui sont fréquemment négligé, comme l'optimisation et la maintenance, qui ont des coûts élevés.

A titre personnel le SGBD qui a plus perdu mais parce qu'elle a pas évolué et je me demande si ça va arriver, c'est Mysql.

J'ai l'impression d'entendre SQLPRO en parlant de MySQmerde !
En fait, tu compares une 2CV avec une Ferrari et au final, tu dis que la 2CV c'est de la merde parce que tu roules en Ferrari.
Désolé de le dire, mais il y a des gens qui ne peuvent pas se payer autre chose qu'une 2CV ! Et donc selon toi, tous ces gens là sont des imbéciles ?

Mais tout le monde n'a pas les mêmes usages d'un SGBD et ne manipule pas tous les jours des requêtes mettant en œuvre de nombreuses tables liées par des conditions de jointure alambiquées.

Entièrement d'accord avec toi. Ce n'est pas parce qu'il manque à MySql quelques fonctionnalités très utiles, que l'on ne peut pas trouver des solutions de contournements.

En tout cas ce n'est pas explicite (ou j'ai mal cherché) dans la doc.

Ni l'un, ni l'autre. En fait, c'est la stratégie commerciale dite "propriétaire" qui consiste à interdire toute communication avec la concurrence.
Sinon, comment retenir la clientèle quand un SGBD gratuit fait la même chose qu'un SGBD avec licence ?

1 processeur physique veut dire 1 "socket" avec la seconde limite qui est de 4 cœurs...

Tu utilises le terme de "socket" dans le sens de la terminologie matériel (enfin je crois), désignant l'emplacement du processeur sur la carte mère.
Quand on parle de "socket", j'ai souvent en-tête la définition de la communication entre processus, c'est-à-dire une façon particulière de faire de la programmation parallèle.
Je ne comprends pas le sens que tu utilises ici, car si ton processeur possède quatre cœurs, il peut traiter quatre processus en parallèle, et donc faire usage de plusieurs sockets.
Ou alors, il faut comprendre qu'un utilisateur possède qu'un seul processus. Mais ça, c'est déjà le cas de la plupart des SGBD.

Le système fonctionne de manière automatique et autonome, il suffit simplement de recenser dans l'instance principale qu'il y a un nouveau serveur et dans la nuit les objets sont créés automatiquement.

C'est de la réplication dont tu parles. Ton client doit avoir beaucoup d'utilisateurs et de ce fait, en créant des réplications il peut rendre les accès plus fluides.

C'est le point très noir de tous les SGBDR libre !!!! En effet ce sont nullement de vrais sauvegardes mais des "dump". Durée gigantesque par rapport à la même base qui sous SQL Server qui fait des sauvegardes binaires.. Et en plus pas question de mettre à jour des données pendant la sauvegarde...

En effet, il y a un abus de langage autour du terme "sauvegarde", qui selon l'usage que l'on en fait est soit un "dump" ou soit un "backup".
Même si "dump" (vidage logique de la base) ou "backup" (recopie physique du disque dur) sont des solutions dite de sauvegardes, ce ne sont pas des solutions adaptés à la tolérence de panne.
Même la réplication des bases de données sur des disques physiques différents n'est pas parfait car cela ralenti les temps d'exécutions.
Ma préférence va vers la solution matériel qui consiste à utiliser la technologie RAID. Ce n'est pas propre aux SGBD mais à tout système d'exploitation nécessitant une disponibilité 24H/24H.
La grosse différence vient du fait que ce n'est pas de la réplication mais soit de la redondance, soit de la répartition pour améliorer les performances, sur plusieurs disques montés en grappe.

@+

[aserf]

Bonjour,

Les requettes CTE sont quand mêmes utilisé régulièrement, moi même je les utilise de temps en temps. le problème est surtout
si un jour tu en as besoin ? et que ton sgbd ne le fait pas tu fera comment ? tu pourra toujours le faire en algo mais au prix d'un temps d'execution multiplié par 1000 ...
tu te retrouvera a faire tournée des batch la nuit pour générer un résultat dans des tables temporaire ... et la on parle si tu as besoin d'un résultat à des fin de statistique ... tu pourra attendre.
mais si c'est sur une donnée de production que tu doit avoir dans les 5 minutes tu fera comment ?

un petit rappelle, (a vérifier je ne retrouve plus l'articles, mais les chiffres sont de cette ordre) mais je crois que sur les 5 dernières année on est a 90% des volume de base de donnée généré, avec une croissance de plus de 20% par an.

si tu as une base de donnée qui ne peu pas traiter les requettes complexe je ne donne pas cher de ton application dans les 5 années à venir ... et la une requette CTE sa peut être magique à ce moment là !

Tu parles de choses qui ne sont utilisées que par toi et peu dans la pratique pour un codeur d'applic.
Les index je sais c'est quoi, c'est pas pour autant qu'on doit indexer tous les champs, c'est juste une constatation.
Comparant Oracle dans la vie de tous les jours, je vois que MariaDb est plus cool au niveau des queries.

[aserf]

Bonjour,

Si vous basez votre récuperation que sur le raid vous faite comment en cas d'erreur de manipulation de la base qui supprime des donnée ? que faire si vous devez revenir a un état de votre base de donnée a 2 semaine en arrières ?
la backup est la pour sa. et les différentes technologie sont toute la pour palier un problème en particulier, RAID, mirroring, backup doivent toutes être utilisé dans un system d'entreprise.

Pour le socket c'est un terme que tout le monde utilise, surtout maintenant que tout est virtualisé, et que les entreprise commence à vendre des licences au cœur et plus au socket.
bien sur l'unité de mesure pour les application c'est le thread qui souvent tourne sur un coeur. donc pour sql server express, c'est max un processeur, mais au sein de ce processeur max 4 coeurs.
donc si vous avez un processeur avec 8 coeurs ou 16 coeurs, il n'en prendra que 4, et si vous avez 2 processeur 2 coeur dans votre serveur, il ne pourra en utilisé que 2 coeurs, le deuxième étant inaccessible.

[Artemus24]

Salut aserf.

Les requettes CTE sont quand mêmes utilisé régulièrement, moi même je les utilise de temps en temps. le problème est surtout
si un jour tu en as besoin ? et que ton sgbd ne le fait pas tu fera comment ?

Vu la façon dont tu t'exprimes, cela dénote un manque d'expérience dans le domaine des SGBD.

Un CTE (Common table expression) simule une encapsulation de tables temporaires.
Et à l'inverse de ce que l'on peut croire, cela ne va pas vous faire gagner en performance.
C'est juste une façon de simplifier l'écriture d'une requête, en te permettant de faire de la récursivité.

tu pourra toujours le faire en algo mais au prix d'un temps d’exécution multiplié par 1000 ...

Non, pas du tout. Comme je l'ai dit ci-avant, c'est une succession de tables temporaires. Sauf que cela ne traite pas la récursivité.

tu te retrouvera a faire tournée des batch la nuit pour générer un résultat dans des tables temporaire ...

Une table temporaire, comme le nom l'indique, disparaît à la fin de la session.
Que ce soit le CTE, ou les tables temporaires, à la fin de la session, tu perds tout !
Et en général, un CTE ne sert qu'une fois, à l'inverse de la table temporaire que tu peux utiliser plusieurs fois avant la fin de la session.

mais si c'est sur une donnée de production que tu doit avoir dans les 5 minutes tu fera comment ?

Tu soulèves un problème d'organisation dans ta façon de travailler, bien plus que la résolution de ce problème.
Si régulièrement, on te demande de fournir ce genre de résultat, et bien, tu fais un script en lignes de commande.

si tu as une base de donnée qui ne peu pas traiter les requettes complexe je ne donne pas cher de ton application dans les 5 années à venir ... et la une requette CTE sa peut être magique à ce moment là !

Oui, le CTE est un plus, mais en aucune façon un handicape.

@+

[aserf]

J'ai toujours adoré les gens qui me prennent de haut ....

Je me suis mal exprimée sur les tables temporaires, ce ne sont pas des table temporaires au sens sgbd (comme # ou ## dans sql server) mais plutôt des tables normales, qui contiennent des données temporaires qui ont été générées la nuit par exemple. c'est souvent le cas des gros ERP ce qui permet d'avoir des statistiques applaties pour évité de mouliner de grosse requêtes lors de chaque interrogation.

Pour les requêtes CTE je sais ce que c'est, même si je ne les utilise que rarement, elles permettent la récursivité comme tu l'indiques. et dans certain cas je vois mal comment j'aurais pu résoudre certains problèmes sans les CTE.
J'etais tombé une fois sur un cas qui me semblait insoluble sans les CTE, je vais essayer de le retrouver, et si je le retrouve et tu me montres la requête standard je suis preneur.

Pour la performance, il m'est aussi une fois arrivé de faire un requête CTE qui était plus rapide que la requête standard. Je vais également essayer de te retrouver cela. C’était une requête CTE qui effectuait un delete dans une base de données de plusieurs cetaines de millions de ligne, et la requête standard n'arrivait tout simplement pas à s’exécuter.

Évite de prendre les gens de haut dans une conversation. ou de supposer ce que je sais ou ne sais pas. Surtout quand on propose comme solution de backup de faire un RAID ;-)
Merci,

[aserf]

Un exemple d'article qui semble mettre en avant des problèmes que ne semble ce résoudre que avec une CTE.

https://blog.pgeiger.net/2012/08/24/...s-partie-33-2/

je ne sais pas si c'est le cas. je ne suis pas assez Expert sur le sujet (et sans avoir tout regardé peut être que cette exemple est resolvable avec une auto jointure sur la table), mais je pense que des expert Sql viendrons argumenté.

Bonne lecture.

[Pierre GIRARD]

...Je ne pense pas qu'une Ferrari a plus de deux places. ...

Erreur Ferrari 400 la berline façon Ferrari et donc : 4 places