Discussion :

[kilroyFR]

Pour jouer avec une techno les projets open source c'est tres pratique mais des que ca se concretise en un vrai projet je n'ai jamais rencontré un client qui se contente de la version open source; il demande toujours la version payante. Ce n'est pas ca qui greve les budgets (meme les licences Oracle, on a +80% de reduction sur les prix donc sur des projets de plusieurs millions d'euros ce n'est pas la qu'on gagne de l'argent, ce sont des miettes).
Pour le rassurer il prefere toujours payer un support (que ce soit pour BDD ou pour OS - meme linux).
Les MAJ regulieres (automatiques dans certains cas) pour du nouveau fonctionnel mais surtout pour les patches de securité etc. ca rassure et c'est inevitable pour des projets serieux.

Donc Open Source = Oui et Payant = Oui (faut savoir si on veut que le projet soit maintenu dans la duree ou pas).
Pour nous c'est Linux ou Windows en payant et Oracle en payant (pour le multiplateforme).
SqlServer en payant etait aussi cher qu'oracle (offre hebergée) mais sans le multiplateforme et PostGreSql non iso fonctionnel avec oracle (meme en version payante) malgre les leurres de portage de plsql (qui est bidon).

[esperanto]

Le gars qui n'y connais rien, ça fait peur.

On ne parle pas de système de fichier Oracle ou autre... et la fragmentation (sur un SGBD digne de ce nom) n'a rien à voir avec le système de fichier support !

J'ai parlé de partition dédiée, pas de système de fichiers. Je crois comprendre (visiblement ici utiliser le mode indicatif signifie que l'on prétend être un expert) qu'Oracle peut utiliser une partition exactement comme si c'était un fichier (bon, en même temps sous Unix cette équivalence fichier/partition existe via le répertoire /dev, donc je ne vois pas trop ce que ça change) donc sans qu'elle soit formatée en EXT3 ou quoi que ce soit d'autre.
Par contre comme tu dis il faut prévoir la taille à l'avance, ce qui n'est hélas pas toujours évident.

2) Oracle et SQL Server ne passent pas par l'OS pour accéder au disque. Ainsi, ils peuvent se réserver une priorité suppérieur à cette de l'OS pour travailler..

J'ai un peu de mal à comprendre comment un OS digne de ce nom (ce qui exclut évidemment Windows ) peut accepter qu'un processus puisse s'approprier une priorité supérieure à celle de l'OS lui-même.
Parce que si maintenant plusieurs applications (ou simplement deux instances Oracle) commencent à se battre pour la priorité, j'imagine déjà le massacre...

je n'ai jamais rencontré un client qui se contente de la version open source; [...]Pour le rassurer il prefere toujours payer un support (que ce soit pour BDD ou pour OS - meme linux).

Oui, mais tu le dis toi-même, c'est pour se rassurer, en ayant un responsable à blâmer si jamais le projet foire: rien à voir avec les fonctions disponibles seulement dans la version payante et que 80% des projets n'utilisent jamais!

[MaitrePylos]

Trop fort, j'en ai eu un comme ça au boulot, le mec mettait 3 semaines à te sortir une vue avec trois jointures, parce qu'il ne la livrait pas avant d'avoir testé toutes les formes d'optimisation possibles et imaginables (et tant pis pour les développeurs qui ne pouvaient rien faire entre temps).

J'ose espérer que ce genre de personnage à été licencié sur le champs, quelle outrecuidance, de vouloir faire son boulot de façon correcte.

C'est vraiment dommage que les serveurs SGBD orientés objet aient été détruits par des gars comme SQL Pro qui les jugeaient peu performants parce qu'ils comparaient une appli Oracle ultra-optimisée avec un simple programme de test sur l'autre serveur. C'est pour ça que j'espère qu'il aura au moins la décence de donner assez de détails pour qu'on puisse refaire le test...

C'est sûr qu'Oracle, IBM, Microsoft ont tous écouté SQLPro comme le messie et lui ont dit 'tu as raison pour les DB objet', il n'y avait pas cours d'histoire informatique dans vos cursus ?

[esperanto]

J'ose espérer que ce genre de personnage à été licencié sur le champs, quelle outrecuidance, de vouloir faire son boulot de façon correcte.

Vu que le projet en question a été annulé après six mois de retard, oui il y avait de quoi.
Et désolé mais non, faire attendre ceux qui dépendent de vous plusieurs semaines, ce n'est pas une façon correcte de développer. La moindre des choses aurait été de produire quelque chose d'utilisable au moins pour les développeurs (surtout qu'ils travaillent avec un petit jeu de données en général) et essayer d'optimiser après, en essayant de ne pas changer la liste des colonnes en sortie.
Optimiser une requête c'est bien, mais encore faut-il être sûr qu'elle constitue réellement le goulot d'étranglement du projet (passer plusieurs semaines sur une requête appelée une fois tous les six mois, ça fait cher l'optimisation). Pour moi ce genre d'optimisation se fait après la première phase de test: la fonctionnalité est là mais les utilisateurs l'ont trouvée lente, on cherche à savoir pourquoi.

C'est sûr qu'Oracle, IBM, Microsoft ont tous écouté SQLPro comme le messie et lui ont dit 'tu as raison pour les DB objet', il n'y avait pas cours d'histoire informatique dans vos cursus ?

Désolé d'être suffisamment âgé pour avoir connu la courte période où on enseignait l'utilisation d'un SGBD objet, donc un peu tôt pour avoir appris à l'école pourquoi ils ont disparu. Par contre j'ai lu plus tard des articles sur le sujet et ce que s'apprête à faire SQLPro ressemble bien au même procédé.

[al1_24]

Moui enfin, dans les casseroles du monsieur tu as également le fait qu'il soutient mordicus que générer des requêtes SQL depuis une application cliente d'un SGBD est une hérésie et qu'elles ne devraient que faire appel à des vues ou des procédures stockées écrites par un dba, donc son incompétences ne se limite pas aux dbs autres que Sql server, y a des sérieuses lacunes dans le développement applicatif aussi.

Si les développeurs de l'application sur laquelle je travaille actuellement avaient accepté de se conformer à cette règle, ils n'en seraient pas aujourd'hui à devoir réécrire un certain nombre de programmes parce qu'une modification réglementaire à imposé une modification de structure de la base de données.

[Sodium]

Par contre je ne soutiens pas pour autant l'usage des ORM, qui génèrent un code SQL qui, même pour moi qui ne suis pas un DBA, paraît franchement peu optimisé. C'est vraiment dommage que les serveurs SGBD orientés objet aient été détruits par des gars comme SQL Pro qui les jugeaient peu performants parce qu'ils comparaient une appli Oracle ultra-optimisée avec un simple programme de test sur l'autre serveur. C'est pour ça que j'espère qu'il aura au moins la décence de donner assez de détails pour qu'on puisse refaire le test...

C'est un peu plus compliqué que ça les ORM. Ca récupère beaucoup d'informations par défaut, ce qui peut paraître un peu crétin. Sauf que dans une application du monde réelle, tu ne sais pas forcément de quelle donnée tu vas avoir besoin à quel moment dans la vue. Tiens au moment du rendu j'ai besoin de telle entité jointe à une autre, faudrait refaire une jointure... sauf que tiens l'ORM l'a déjà en mémoire parce qu'elle l'a récupérée à un autre moment sur une requête qui n'avait rien à voir. Ajoutes à ça une mise en cache intelligente et automatique. Sur la plupart des pages des sites que j'ai développé, avec une hiérarchie récursive totalement dynamique sur 4 à 8 niveau avec chaque élément ayant ou non des liens avec des données de plusieurs autres table, j'ai trois à quatre requête très simples grand max exécutées en 4ms.

Ne jamais oublié également qu'un ORM permet de simplifier énormément son code, son écriture et sa maintenance. Donc besoin de moins de temps de développement, moins de gens, et le temps humain coûtera toujours moins cher que de prendre un serveur un peu plus puissant.

Si les développeurs de l'application sur laquelle je travaille actuellement avaient accepté de se conformer à cette règle, ils n'en seraient pas aujourd'hui à devoir réécrire un certain nombre de programmes parce qu'une modification réglementaire à imposé une modification de structure de la base de données.

C'est que les mecs étaient incompétents, ce qui n'a rien à voir. Quand on passe son temps à se conformer à des sacro-saintes règles, on ne fait rien et on se retrouve avec des logiciels qui ont 15 ans de retard et il faut six mois pour faire la moindre modification demandée par les utilisateurs.

[MaitrePylos]

Vu que le projet en question a été annulé après six mois de retard, oui il y avait de quoi.
Et désolé mais non, faire attendre ceux qui dépendent de vous plusieurs semaines, ce n'est pas une façon correcte de développer. La moindre des choses aurait été de produire quelque chose d'utilisable au moins pour les développeurs (surtout qu'ils travaillent avec un petit jeu de données en général) et essayer d'optimiser après, en essayant de ne pas changer la liste des colonnes en sortie.
Optimiser une requête c'est bien, mais encore faut-il être sûr qu'elle constitue réellement le goulot d'étranglement du projet (passer plusieurs semaines sur une requête appelée une fois tous les six mois, ça fait cher l'optimisation). Pour moi ce genre d'optimisation se fait après la première phase de test: la fonctionnalité est là mais les utilisateurs l'ont trouvée lente, on cherche à savoir pourquoi.
.

En même temps, si les dev, ne savent pas ce que cela va retourner, il y a un souci dans la gestion de projet.
Donc j'imagine que l'échec, n'est pas entièrement de la faute du DBA.

Désolé d'être suffisamment âgé pour avoir connu la courte période où on enseignait l'utilisation d'un SGBD objet, donc un peu tôt pour avoir appris à l'école pourquoi ils ont disparu. Par contre j'ai lu plus tard des articles sur le sujet et ce que s'apprête à faire SQLPro ressemble bien au même procédé.

Donc vous l'avez vécu, l'échec des SGDBRO dans les années 80 et la disparition du concept fin des années 90.
C'est l'application qui doit se conformer aux données et pas l'inverse. J'imagine le dev qui arrive chez Google en leurs disant, on va jeter vos données, car cela correspond pas à mon application.

[Sodium]

Donc si un truc a échoué il y a 30 ans et que c'est passé de mode entre-temps ça veut dire qu'il ne faut jamais essayer de faire évoluer les technos ? C'est marrant car justement, je me suis intéressée de plus près aux fonctions avancées de SQL récemment et je me rends compte que j'étais totalement ignorante d'à quel point ce langage est primitif et tordu pour le moindre traitement simple des données avant le retour

Je disais que c'était l'assembleur des bases de données, mais c'est vraiment ça en fait, on multiplie les manipulations primitives pour arriver à un résultat qui prendrait deux instructions en programmation.

[walfrat]

Faire N+1 requête en ORM ça prend aussi deux lignes, comme bien des choses en infos. Je ne suis donc pas sur que ton exemple soit le plus pertinent.

Le SQL est un langage qui est construit d'une façon stricte et il est possible de faire certaines choses de façon puissance et rapide.
D'autres, bien que possible en SQL sont tout de même moins adaptés, faire du post-traitement de données par exemple n'est effectivement pas ce qui me vient le plus à l'esprit quand j'en fais.

[Sodium]

Pas quand tu ne sais pas combien de N tu as, et je parlais plutôt de manipulations de strings, de comparaisons etc. D'ailleurs c'est souvent comme ça en SQL, quand tu sais exactement ce que tu veux récupérer, quels cas traiter précisément, sur combien de niveaux, combien de relations... quand tu ne sais pas ben non c'est le bordel.

[Pomalaix]

...le risque qu'on est prêt à courir - si le site de veepee.com tombe pendant 2h c'est pas le même impact que si c'est jaimelestulipes.com...

Tout à fait ! Jamais entendu parler de veepee.com, en revanche, jaimelestulipes, c'est mon site de prédilection, mon havre, mon refuge, et je serais fort marri qu'il restât en quenouille pendant 7200 longues secondes !

[MaitrePylos]

Donc si un truc a échoué il y a 30 ans et que c'est passé de mode entre-temps ça veut dire qu'il ne faut jamais essayer de faire évoluer les technos ? C'est marrant car justement, je me suis intéressée de plus près aux fonctions avancées de SQL récemment et je me rends compte que j'étais totalement ignorante d'à quel point ce langage est primitif et tordu pour le moindre traitement simple des données avant le retour

Je disais que c'était l'assembleur des bases de données, mais c'est vraiment ça en fait, on multiplie les manipulations primitives pour arriver à un résultat qui prendrait deux instructions en programmation.

Nop, je dis juste que si les plus grand acteurs de DB ne l'implémente plus, c'est qu'il y a une bonne raison, maintenant, si tu as dans tes cartons, un SGBDRO qui me permet de flushé mon entité et en ressortir un objet dans n'importe quelles applications, je suis preneur de tester.

Au fait, je suis au Fosdem ce wk (pas loin de chez toi donc), je suis dispo pour une démo et être convaincu.

[esperanto]

En même temps, si les dev, ne savent pas ce que cela va retourner, il y a un souci dans la gestion de projet.
Donc j'imagine que l'échec, n'est pas entièrement de la faute du DBA.

Ben oui justement on ne savait pas parce quand on demandait au chef de projet il répondait "demandez au DBA", lequel refusait de répondre tant qu'il n'avait pas testé 256 solutions et choisi celle qui lui plaisait le plus...

C'est l'application qui doit se conformer aux données et pas l'inverse. J'imagine le dev qui arrive chez Google en leurs disant, on va jeter vos données, car cela correspond pas à mon application.

Vrai si les applications sont écrites bien après que les données ou au moins leur schéma soient créés depuis longtemps. Mais si tout est fait en même temps, si on part d'une feuille blanche, alors au nom de quoi le DBA a-t-il priorité sur les développeurs?

Je disais que c'était l'assembleur des bases de données, mais c'est vraiment ça en fait, on multiplie les manipulations primitives pour arriver à un résultat qui prendrait deux instructions en programmation.

Si on se restreint aux bases de données relationnelles, l'assembleur, s'il existait, serait plutôt à base de projections, de produits cartésiens et de sélections. Ça s'apelle l'algèbre relationnelle et on enseigne encore ça à la fac.
SQL, c'est plutôt le COBOL des bases de données, conçu pour que des gens du business puissent aussi écrire des requêtes, d'où parfois une syntaxe très verbeuse parce que proche de l'anglais comme Cobol. Hélas comme c'est souvent le business qui fait la loi...

Nop, je dis juste que si les plus grand acteurs de DB ne l'implémente plus, c'est qu'il y a une bonne raison,

Mais la raison est bien connue: les DBA Oracle se sont donné le mot pour "prouver" que le modèle objet était plus lent à coup de benchmarks biaisés où on comparait d'un côté une base Oracle ultra-optimisée et de l'autre une base objet créée à la va-vite.
Alors je soupçonne SQL Pro de vouloir appliquer la même méthode pour casser du PostgreSQL, mais s'il a un peu de bonne foi, il donnera au moins assez de détails pour qu'un expert PostgreSQL puisse essayer de répondre et trouver des optimisations plus spécifiques. On verra alors qui a raison.

[kilroyFR]

Oui, mais tu le dis toi-même, c'est pour se rassurer, en ayant un responsable à blâmer si jamais le projet foire: rien à voir avec les fonctions disponibles seulement dans la version payante et que 80% des projets n'utilisent jamais!

Tu prends bien une assurance maison/voiture ? pourquoi le fais tu alors ? pour te rassurer ?
C'est pareil pour ces logiciels. nos clients ne veulent pas prendre le risque de se retrouver avec quelque chose plus maintenu ou pour lesquels les delais de reactions ne sont pas en phase avec les delais d'intervention en cas de problemes.
Pas une histoire de responsable a blamer ou pas, completement a cote ta remarque.

Et non, pas du tout d'accord quand tu annonces qu'on paie des licences pour 80% de fonctionnalités qu'on n'utilise pas.
On choisit justement les versions (sans se precipiter sur les dernieres sorties) en fonction des fonctionnalités recherchées qui a elles seules justifient le prix.
Ce n'est pas parce que tu survoles un logiciel qu'il faut croire que tout le monde fonctionne comme ca.
Mais ca ne me surprend pas, vues tes remarques assez virulentes et comme souvent chez certains developpeurs obtus qui ne savent que baver sur un DBA alors qu'il ne connait pas le 1/10 de ce qu'il utilise (le developpeur).
Je suis dba et a la fois developpeur (pas seulement BDD) donc je ne comprends meme pas cette façon de baver sur une profession que tu survoles.
Tu fais partie de ces gens qui codent des requetes SQL en equivalent c# imbittable et immaintenable.
Il y a des layatolas comme ca dans toutes les boites.

[calvaire]

Tu prends bien une assurance maison/voiture ? pourquoi le fais tu alors ? pour te rassurer ?

Non, parce que c'est obligatoire. Ma voiture je l'assure au minimum.

[esperanto]

Tu prends bien une assurance maison/voiture ? pourquoi le fais tu alors ? pour te rassurer ?
C'est pareil pour ces logiciels. nos clients ne veulent pas prendre le risque de se retrouver avec quelque chose plus maintenu ou pour lesquels les delais de reactions ne sont pas en phase avec les delais d'intervention en cas de problemes.

En dehors de la raison légale (merci Calvaire de l'avoir rappelé) je n'ai pas dit que c'était une mauvaise raison. Si le DSI veut absolument utiliser Red Hat ou PostgreSQL en version payante plutôt que "sans support", dans la mesure où ça permet à ces entreprises de vivre, eh bien tant mieux.
Par contre choisir toujours le moteur le plus cher parce qu'il doit forcément avoir plus de fonctions (utiles seulement si on les utilise, sinon elles allourdissent le truc) voire pire parce qu'une plus grosse boîte offre plus de "sécurité", ne venez pas vous plaindre après si vous devez payer des prix astronomiques.

Pas une histoire de responsable a blamer ou pas, completement a cote ta remarque.

Dommage pour toi, parce que si tu avais lu ce que j'avais écrit tu aurais vu que je rapportais une remarque d'un collègue... qui en l'occurence était un de tes chers DBA.

Tu fais partie de ces gens qui codent des requetes SQL en equivalent c# imbittable et immaintenable.

En l'occurence non, complètement raté: d'abord c# n'est pas mon langage principal (j'ai juste fait une remarque sur un des projets où je l'utilise) et surtout, quand je veux faire une requête SQL je n'utilise ni Linq ni un ORM (décidément tu ne lis que ce qui t'arrange) j'essaie de les coder moi-même dans des chaînes de caractères. Après si je vois qu'une d'entre elles est lente, je suis tout à fait prêt à aller voir le DBA pour savoir s'il voit une optimisation potentielle. Par contre je refuse d'être bloqué pendant trois semaines parce que toutes les tables sont cachées et que le DBA met autant de temps pour produire la vue qui me permet d'avoir dans mon projet l'abstraction sur les données qui me convient bien, même s'il ne me laisse accéder qu'à une toute petite partie de la base.

[Invité]

Nop, je dis juste que si les plus grand acteurs de DB ne l'implémente plus, c'est qu'il y a une bonne raison, maintenant, si tu as dans tes cartons, un SGBDRO qui me permet de flushé mon entité et en ressortir un objet dans n'importe quelles applications, je suis preneur de tester.

Au fait, je suis au Fosdem ce wk (pas loin de chez toi donc), je suis dispo pour une démo et être convaincu.

J'y serais aussi, dispo pour la démo également

[MaitrePylos]

J'y serais aussi, dispo pour la démo également

Ok, je note, je reste à la cafet tout le samedi

[Sodium]

Arrêtez de jouer au ***, je ne dis pas que j'ai une solution clé en main, je dis qu'il serait sérieusement temps que les développeurs se sortent les doigts du fondement et fassent évoluer une techno tellement vieille qu'on va bientôt pouvoir l'exposer dans des musées. C'est comme si en développement on en était resté au basic, et encore, une version très primitive du basic.

Ouep effectivement, peut-être qu'ils ont essayé d'améliorer le truc dans les 80's, ça a foiré, les systèmes n'étaient probablement pas prêts niveau hardware comme software, ça ne veut pas dire qu'il faut abandonner tout notion même de progrès.

Je n'écarterais pas non plus l'idée que les dba sont tout simplement plus réfractaires au changement et moins prompts à sortir de leurs acquis. C'est assez évident dans ce que je constate, ici comme IRL.

[walfrat]

Et en quoi le fait qu'une techno est vieille est un argument pertinent ? En plus tu as déjà plein d'alternatives du côté des "Not only SQL".

Le C est encore plus vieux et reste aujourd'hui un langage pertinent. Les DBA sont formés pour avoir une connaissance pointus sur les SGBDR, si tu remplaces ça par autre chose, c'est pas avec une formation de deux semaines qu'ils vont être aussi compétent sur les nouveaux systèmes que les anciens, ce n'est donc pas étonnant qu'ils y soient réfractaires. Même une projet de migration d'un SGBDR à un autre n'est pas simple si, pour tes besoins, tu as déjà dû beaucoup pousser le SGBDR actuel.

Les SGBDR et le SQL répondent à une série de besoins spécifiques et de par leur façon d'y répondre, entraîne un certain nombre de contrainte. Si ça ne te va pas, tu as déjà plein d'alternatives qui existent.