IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

Pourquoi personne ne paie pour un logiciel de base de données open source ?


Sujet :

Décisions SGBD

  1. #81
    Membre expérimenté

    Homme Profil pro
    Retraite
    Inscrit en
    Octobre 2005
    Messages
    477
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraite
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2005
    Messages : 477
    Points : 1 332
    Points
    1 332
    Billets dans le blog
    1
    Par défaut
    Intéressante certaine discutions, mais ou le sujet de base Open-Source .....

  2. #82
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par Sodium Voir le message
    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.
    Oui, ou c'est comme si aujourd'hui, en 2020, on mangeait encore avec un couteau et une fourchette, vieux respectivement de 25 et 2 millénaires et qu'on l'on trouve déjà par ailleurs dans les musées.

    Sachez que, contrairement à ce que vous dites, le SQL évolue. Par exemple, la norme de 1999 a introduit la possibilité de faire des requêtes récursives, qui pourrait répondre au besoin de votre site. et ce n'est qu'un exemple

    Certes, il n'y a pas des évolutions majeures tous les jours, mais des évolutions pertinentes : c'est quand même stupide d'inventer la roue carrée pour la simple et unique raison que la roue ronde existe depuis plus de 5000 ans et est donc has been et inefficace

  3. #83
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    716
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 716
    Points : 2 702
    Points
    2 702
    Par défaut héritage
    Citation Envoyé par aieeeuuuuu Voir le message
    Sachez que, contrairement à ce que vous dites, le SQL évolue. Par exemple, la norme de 1999 a introduit la possibilité de faire des requêtes récursives,
    Bizarrement en tant que développeur, de SQL 1999 (ou SQL 3) je retiens surtout l'ajout des fonctionnalités orientées objet (en fait relationnel/objet), or je n'ai jamais vu un DBA produire un schéma avec héritage.
    Sans compter qu'Oracle ne supporte même pas l'héritage de tables, pourtant clairement inscrit dans SQL 3
    Résultat, les ORM ne peuvent pas utiliser l'héritage de table non plus étant donné qu'en se voulant indépendants du SGBD, ils prennent toujours le plus petit dénominateur commun, un peu comme AWT en Java qui ne contenait que des composants existant sur toutes les plateformes et renonçaient donc à des composants importants tels qu'une combobox.

    Notez que l'héritage de tables et de type, ce n'est pas la même chose. La première implique la seconde. Oracle n'implémente que la seconde.
    A ce niveau, PostgreSQL est plus proche de SQL 3 qu'Oracle du coup. Alors évidemment certains vont dire que l'héritage entre tables est utilisé pour le partitionnement, sauf que moi je l'utilise pour bien d'autres choses et qu'entre temps PostgreSQL a un nouveau système de partitionnement qui n'a rien à voir avec l'héritage, ce qui permet de réserver ce dernier à ce qui aide vraiment les programmeurs.

  4. #84
    Membre émérite
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    895
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 895
    Points : 2 794
    Points
    2 794
    Par défaut
    La prise en compte du standard SQL est à mon avis beaucoup plus difficile que celle par exemple du HTML/CSS (qui reste sans aucun doute au dessus de mon niveau). Les acteurs prennent donc avant tout ce qu'ils trouvent le plus pertinent. Et même en tant que DBA.

    Car il faut parvenir à ajouter les nouveaux éléments non seulement sans casser le reste, mais en garantissant toujours des performances dignes de ce nom, en particulier au niveau du moteur d’interprétation SQL et de calcul du plan de la requête, des index,....

  5. #85
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    716
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 716
    Points : 2 702
    Points
    2 702
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    Certes, il n'y a pas des évolutions majeures tous les jours, mais des évolutions pertinentes : c'est quand même stupide d'inventer la roue carrée pour la simple et unique raison que la roue ronde existe depuis plus de 5000 ans et est donc has been et inefficace
    Une roue carrée serait adaptée sur des routes ayant la forme d'un toît en tôle ondulée. Tant que de telles routes n'existent pas la roue ronde convient parfaitement, mais qui sait si on aura pas un jour de très bonnes raisons de faire autrement.
    A l'inverse la roue ronde serait inadaptée sur des routes qui ne sont pas à peu près planes
    Plusieurs usages, plusieurs besoins, plusieurs produits. Le mieux est de choisir ce qui est adapté, pas de copier bêtement le voisin.

    Citation Envoyé par walfrat Voir le message
    Car il faut parvenir à ajouter les nouveaux éléments non seulement sans casser le reste, mais en garantissant toujours des performances dignes de ce nom, en particulier au niveau du moteur d’interprétation SQL et de calcul du plan de la requête, des index,....
    Sans doute, mais puisque certains ici viennent nous expliquer que les SGBD commerciaux ont plein de fonctions en plus par rapport aux SGBD libres, je voulais surtout montrer que parfois, l'inverse est vraie aussi.

  6. #86
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Nom : 11219347_10208118767993563_6437827098038190051_n.jpg
Affichages : 566
Taille : 55,8 Ko

  7. #87
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Mrsky Voir le message
    Il me semblait avoir lu (il y a longtemps) que la différence de performances entre Oracle, SQL Server & co. et PostgreSQL MySQL & co. est principalement due au fait que les uns codent des accès disques sur mesure et les autres utilisent les fonctions de l'OS sous-jacent ce qui est bien plus lent. N'étant pas un expert en BDD et vu qu'il y a des gens qui ont l'air de savoir de quoi ils parlent ici c'est info ou intox ?
    S'il n'y avait que cela ! Et même avec cela il y a des bugs sous PG toujours pas résolus...
    https://www.developpez.com/actu/2457...u-FOSDEM-2019/
    Pour rappel aucune solution, juste un correctif qui permet de mieux mettre en évidence que le système n'arrive pas à faire des écritures !!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #88
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par esperanto Voir le message
    ... 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...
    Les SGBD OO ont disparu par darwinisme. Il est possible d'indexer des données scalaires atomiques par un simple tri des valeurs organisées par dichotomie (arbre de recherche). Ceci est déjà plus difficile pour des éléments à plusieurs composantes (exemple indexation spatiale, moins efficace car 2 cordonnées). C'est impossible pour des objets ayant de multiples attributs qui ne sont pas situé au même niveau hiérarchique... Tout simplement !

    Et si les performances d'un SGBD OO sont inférieur à un simple accès à un fichier ISAM, alors il n'y a aucune intérêt à payer cher quelque chose d'inutilisable !


    A -
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #89
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    716
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 716
    Points : 2 702
    Points
    2 702
    Par défaut Indexes
    Citation Envoyé par SQLpro Voir le message
    Il est possible d'indexer des données scalaires atomiques par un simple tri des valeurs organisées par dichotomie (arbre de recherche). Ceci est déjà plus difficile pour des éléments à plusieurs composantes (exemple indexation spatiale, moins efficace car 2 cordonnées).
    Donc selon toi les indexes couvrant plusieurs colonnes, comme ici, sont inefficaces?

    Citation Envoyé par SQLpro Voir le message
    C'est impossible pour des objets ayant de multiples attributs qui ne sont pas situé au même niveau hiérarchique... Tout simplement !
    Pourtant je vois un moyen très simple de le faire, c'est de créer un index fonction.
    Si je considère l'accès au champ x.y.z comme une fonction, alors cette fonction est déterministe et donc éligible à l'indexation.
    Le seul cas où je pourrais éventuellement voir un problème, c'est si certains champs peuvent exister pour certaines lignes et pas d'autres, ce qui pourrait arriver par héritage.

    Au passage, les SGBD relationnels ont déjà des attributs hiérarchiques, par exemple les RECORD en Oracle, qui peuvent eux-même contenir d'autres RECORD, ou l'usage de REF. Et il y a aussi l'héritage de type. Mais peut-être qu'on ne peut pas les indexer?

    Note que je fais ici des recherches pour pouvoir citer Oracle, que j'utilise rarement, pour que tu ne puisses pas venir dire que j'ai sorti du chapeau une fonction spécifique à un SGBD que je connais mieux. Mais je n'ai pas lu tout ce que j'ai trouvé en détail, donc si tu me dis que tout ce que j'ai trouvé est inefficace, je peux le croire.

    Citation Envoyé par SQLpro Voir le message
    Il est possible d'indexer des données scalaires atomiques par un simple tri des valeurs organisées par dichotomie (arbre de recherche).
    Pas besoin que le type soit scalaire pour ça, il suffit qu'il ait une relation d'ordre total correctement définie.
    En programmation on crée souvent des arbres de recherche en mémoire, sans forcément y penser (par exemple, les types TreeMap et TreeSet en Java). Si tu regardes la spécification de ces types, tu verras qu'on n'impose pas que la clé soit scalaire, on impose seulement qu'elle ait une relation d'ordre valide.

    Et quand bien même, comme tu parles de coordonnées comme un exemple de donnée scalaire non atomique, je vois bien un moyen de les rendre scalaires, au moins pour les nombres entiers: utiliser un entier long pour coder l'abscisse sur les octets de poids fort et l'ordonnée sur les octets de poids faible. Au final le type entier long est un scalaire atomique. Avec des flottants on pourrait jouer sur les octets aussi mais plus difficilement, c'est vrai.

    Heureusement d'ailleurs, parce qu'au sens strict, on pourrait considérer que le type "chaîne de caractères" n'est pas vraiment un scalaire atomique dès lors qu'il a une longueur variable. Pourtant il n'y a aucun problème à indexer des chaînes car on a déjà un ordre qui était utilisé bien avant l'invention de l'informatique: l'ordre alphabétique!!!

  10. #90
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Évidemment qu'un index peut porter sur plusieurs colonnes !

    Rien à voir avec la problématique des données spatiales.

    Si tu crées un index (X,Y), comment fais-tu pour trouver tous les points qui sont à moins de 5 km d'un point donné ?
    Pas d'autre solution que de lire l'ensemble des points !
    Si tu crées un second index (Y,X), tu doubles la quantité de données indexées (donc le stockage, la mémoire et les temps de mise à jour sont rallongés d'autant).
    Ensuite, il va falloir faire du bounding box à la main en complexifiant le traitement de recherche afin de bénéficier de l'un ou l'autre des index... en fonction des données lues... compliqué.
    Et là je parle de chercher des points à une distance donnée d'un autre point... Maintenant, à partir du tracé des frontière d'un pays (polygone de quelques milliers de sommets) trouve l'ensemble des points qui sont contenus dedans.

    Elle est là, la problématique d'indexer des données non scalaires.

    Là on parle de deux point... je te laisse imaginer avec des objets complexes (sans parler de polymorphisme ou d'héritage, on n'en est pas encore là).

    Sinon, le RECORD d'Oracle est à mon sens un truc qui doit commencer à dater et doit apporter plus de lourdeur qu'autre chose.
    Cependant, Oracle et SQL Server permettent d'utiliser des représentations d'objets (XML ou JSON notamment) avec tout ce qu'il faut pour accéder aux attributs des objets.
    Sous SQL Server les index XML s'en sortent à peut près, mais restent très en deçà des performances qu'on peut espérer en stockage proprement les objets sous forme de lignes et de colonnes dans des tables. Pour ce qui est de JSON à priori pas d'index (je trouve ça un peu con, cas sorti de la syntaxe XML et JSON sont identiques, donc c'est surprenant que Microsoft n'ait pas étendu l'indexation du XML aux colonnes JSON).

    https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    https://docs.microsoft.com/fr-fr/sql...l-server-ver15
    On ne jouit bien que de ce qu’on partage.

  11. #91
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    716
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 716
    Points : 2 702
    Points
    2 702
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Si tu crées un index (X,Y), comment fais-tu pour trouver tous les points qui sont à moins de 5 km d'un point donné ?
    Si un point B(xB,yB) est à moins de 5 kilomètres de A(xA,yA) alors |xB - xA| < 5 km et |yB - yA| < 5 km, car le carré de 10 km autour de A englobe entièrement le cercle de 5 km autour de A. Donc si c'est pour trouver les points à une distance donnée, j'aurais plutôt tendance à créer deux indexes, 1 pour l'abscisse et un pour l'ordonnée, à filtrer sur l'intervalle (-5, +5) et ensuite regarder parmi les points restants ceux qui sont effectivement dans le cercle.

    Citation Envoyé par StringBuilder Voir le message
    Évidemment qu'un index peut porter sur plusieurs colonnes ![...]
    Sinon, le RECORD d'Oracle est à mon sens un truc qui doit commencer à dater et doit apporter plus de lourdeur qu'autre chose.
    Cependant, Oracle et SQL Server permettent d'utiliser des représentations d'objets (XML ou JSON notamment) avec tout ce qu'il faut pour accéder aux attributs des objets.
    Merci, tu confirmes en fait ce que je disais: les affirmations de SQL Pro disant qu'il est difficile d'indexer plusieurs colonnes ou des colonnes contenant des sous-champs sont absurdes, surtout à l'heure où on utilise de plus en plus souvent des colonnes JSON ou XML. Avec PostgreSQL je peux déjà indexer un champ dans XML ou dans JSON, sur les autres serveurs je pensais que c'était déjà le cas mais je suppose que ça viendra.

  12. #92
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 459
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 459
    Points : 6 060
    Points
    6 060
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Si un point B(xB,yB) est à moins de 5 kilomètres de A(xA,yA) alors |xB - xA| < 5 km et |yB - yA| < 5 km, car le carré de 10 km autour de A englobe entièrement le cercle de 5 km autour de A. Donc si c'est pour trouver les points à une distance donnée, j'aurais plutôt tendance à créer deux indexes, 1 pour l'abscisse et un pour l'ordonnée, à filtrer sur l'intervalle (-5, +5) et ensuite regarder parmi les points restants ceux qui sont effectivement dans le cercle.
    Les index ne se combinent pas.
    Si tu crées un index I qui range tous les points dans un arbre binaire de recherche en triant sur l'abscisse, alors tu pourras faire une requête performante qui trouve tous les points avec une abscisse entre xA - 5 km et xA + 5 km. Cela correspond à deux recherches en O(log n) dans l'arbre binaire pour trouver les deux bornes. Entre les deux nœuds, il n'y aura que les points avec la bonne abscisse.
    De même, si tu crées un index J qui range tous les points dans un arbre binaire de recherche en triant sur l'ordonnée, alors tu pourras faire une requête performante qui trouve tous les points avec une ordonnée entre yB - 5 km et yB + 5 km. Cela correspond à deux recherches en O(log n) dans l'arbre binaire pour trouver les deux bornes. Entre les deux nœuds, il n'y aura que les points avec la bonne ordonnée.
    Par contre, avec tes deux index, pour trouver tous les points à 5 km de A, soit on n'utilise que I pour parcourir tous les points avec la bonne abscisse puis on filtre selon la distance, soit on n'utilise que J pour parcourir tous les points avec la bonne ordonnée puis on filtre selon la distance. Tu ne pourras pas aller plus vite.

    Dans la page Spatial Indexes Overview de la doc de SQL Server, avec les index spatiaux, les points sont rangés dans des grilles qui sont elle-même rangées dans des grilles, etc.

  13. #93
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Juin 2010
    Messages
    794
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 794
    Points : 986
    Points
    986
    Par défaut
    Citation Envoyé par al1_24 Voir le message
    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.
    Tout à fait aucune requête n'a à se trouver dans le code de l'appli

  14. #94
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Juin 2010
    Messages
    794
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 794
    Points : 986
    Points
    986
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Si un point B(xB,yB) est à moins de 5 kilomètres de A(xA,yA) alors |xB - xA| < 5 km et |yB - yA| < 5 km, car le carré de 10 km autour de A englobe entièrement le cercle de 5 km autour de A. Donc si c'est pour trouver les points à une distance donnée, j'aurais plutôt tendance à créer deux indexes, 1 pour l'abscisse et un pour l'ordonnée, à filtrer sur l'intervalle (-5, +5) et ensuite regarder parmi les points restants ceux qui sont effectivement dans le cercle.



    Merci, tu confirmes en fait ce que je disais: les affirmations de SQL Pro disant qu'il est difficile d'indexer plusieurs colonnes ou des colonnes contenant des sous-champs sont absurdes, surtout à l'heure où on utilise de plus en plus souvent des colonnes JSON ou XML. Avec PostgreSQL je peux déjà indexer un champ dans XML ou dans JSON, sur les autres serveurs je pensais que c'était déjà le cas mais je suppose que ça viendra.
    Votre conclusion est fausse car vous ne tenez pas compte d'une chose essentielle les structures de données sous-jacentes

  15. #95
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 459
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 459
    Points : 6 060
    Points
    6 060
    Par défaut
    À part ça, pour les cas que j'ai connus, je suis entièrement pour une architecture dans laquelle le code applicatif ne passe que par des vues et des procédures stockées. Le code applicatif pourrait quand même utiliser un ORM pour générer des requêtes SQL, mais ces requêtes n'auraient pas accès directement aux tables physiques.
    Mettre cette couche d'abstraction est juste un exemple d'application de la programmation modulaire : on isole les dépendances envers l'implémentation pour que l'ensemble soit plus facile à maintenir et plus rapide à faire évoluer.

    Citation Envoyé par redcurve Voir le message
    Tout à fait aucune requête n'a à se trouver dans le code de l'appli
    Les développeurs doivent avoir le droit de générer des requêtes plus compliquées que SELECT * FROM my_view. Il ne faut pas déconner non plus.

  16. #96
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    Ah il est certain que j'aurais une de ces productivités si je devais demander l'aval du sain dba chaque fois que j'ajoute un modèle dans mon app

  17. #97
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 459
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 459
    Points : 6 060
    Points
    6 060
    Par défaut
    Citation Envoyé par Sodium Voir le message
    Ah il est certain que j'aurais une de ces productivités si je devais demander l'aval du sain dba chaque fois que j'ajoute un modèle dans mon app
    Ça, ce n'est pas un problème technique, mais un problème organisationnel de l'entreprise.

    Remarque : je n'ai travaillé que dans des PME où c'étaient les développeurs qui s'occupaient des données. Naïvement, je m'attends à ce qu'un DBA ait un statut similaire à celui d'un développeur, responsable aussi de la vitesse des développements et du bon fonctionnement de l'application, mis à part qu'il a plus de compétences en bases de données et moins en développement pur. Comment ça se passe, dans une boîte normal ? À lire certains postes sur ce forum, on a l'impression que les DBA sont épargnés par les contraintes de délai.

  18. #98
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2009
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2009
    Messages : 552
    Points : 1 060
    Points
    1 060
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Les index ne se combinent pas.
    Tu peux te retrouver à indexer le couple (x,y) et ça s'avère plus efficace au niveau PostGIS pour rechercher des égalités strictes que de s'appuyer sur un indexe spatial (GIST).

    Citation Envoyé par Pyramidev Voir le message
    Dans la page Spatial Indexes Overview de la doc de SQL Server, avec les index spatiaux, les points sont rangés dans des grilles qui sont elle-même rangées dans des grilles, etc.
    Les grilles, c'est pas franchement la rolls de l'indexation spatiale (définition d'un pas, connaissance bbox globale à priori, taille de l'indexe,...). PostGIS s'appuie sur des RTree pour indexer les boites englobantes (voir Spatial Indexing) (il n'y a pas ce genre de méthode d'indexation dans SQL Server?)

    Citation Envoyé par SQLpro Voir le message
    Les SGBD OO ont disparu par darwinisme. Il est possible d'indexer des données scalaires atomiques par un simple tri des valeurs organisées par dichotomie (arbre de recherche). Ceci est déjà plus difficile pour des éléments à plusieurs composantes (exemple indexation spatiale, moins efficace car 2 cordonnées). C'est impossible pour des objets ayant de multiples attributs qui ne sont pas situé au même niveau hiérarchique... Tout simplement !
    Je ne comprend pas trop la fin... Avec PostgreSQL, tu peux https://www.postgresql.org/docs/9.1/...ressional.html. Dès lors, si le SGBD sait indexer row.att1 et f(row), il peut indexer row.properties.attribut_utilisateur.

    C'est pratique pour couper la poire en deux entre des tables rigides et des documents façon MongoDB lorsque tu veux permettre à des utilisateurs d'ajouter leurs attributs par exemple...

    Pour revenir au sujet de départ, il y a toujours quelqu'un qui paie directement ou indirectement pour un logiciel de base de données open source. Il est intéressant de s'interroger sur les motivations du côté des utilisateurs et des fournisseurs. Si on prend le cas de PostGIS qui justifie selon moi l'utilisation de PostgreSQL pour pas mal d'acteur du monde du SIG :

    - Quand le gros de la valeur ajoutée est dans son produit fini, il n'est pas déraisonnable de payer l'ajout d'une fonctionnalité à PostGIS pour ne payer une licence sur un SGBR non libre ou être le seul à maintenir un algorithme de calcul géométrique.

    - Quand on développe un logiciel type SIG, inclure une dépendance à un SGBD payant fait monter la facture des clients et rend non compétitif face à ceux qui mettent en commun leurs efforts autour de PostGIS et se concurrencent sur le développement des surcouches et interfaces.

    - Quand on est un contribuable, il peut être rentable de financer indirectement PostGIS via des projets de recherche s'appuyant sur ce dernier, plutôt que de n'avoir aucune alternative au paiement d'une licence de SGBD par processeur dans chaque organisation exploitant des données spatiales.

    - Quand on est développeur, il peut être aussi intéressant de se rémunérer en donnant des formations sur PostGIS et en développant des fonctionnalités à façon ou en surcouche, qu'en étant salarié d'une boite fournissant un SGBD payant.

    Après, des bugs, il y en a sûrement... La différence entre l'opensource gratuit et le payant fermé en la matière, c'est que lorsqu'un bug pose vraiment des problèmes, on a d'autres options que se battre à faire admettre au fournisseur que le bug existe et qu'il faut le traiter : Payer un indépendant ou mettre les mains dans le cambouis.

  19. #99
    Modérateur

    Avatar de MaitrePylos
    Homme Profil pro
    DBA
    Inscrit en
    Juin 2005
    Messages
    5 496
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA
    Secteur : Service public

    Informations forums :
    Inscription : Juin 2005
    Messages : 5 496
    Points : 12 593
    Points
    12 593
    Par défaut
    Citation Envoyé par bretus Voir le message
    ]


    - Quand on est développeur, il peut être aussi intéressant de se rémunérer en donnant des formations sur PostGIS et en développant des fonctionnalités à façon ou en surcouche, qu'en étant salarié d'une boite fournissant un SGBD payant.
    Je me suis fais taper sur les doigts, quand je conseillais aux client d'utiliser QGis en lieu et place d'arcGis, on me faisait valoir que l'open source c'était n'importe quoi...pourtant les Db sont PostgreSQL/Potsgis.
    La méconnaissance est aussi un prix à payé.

  20. #100
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    716
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 716
    Points : 2 702
    Points
    2 702
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Les index ne se combinent pas.[...]
    Par contre, avec tes deux index, pour trouver tous les points à 5 km de A, soit on n'utilise que I pour parcourir tous les points avec la bonne abscisse puis on filtre selon la distance, soit on n'utilise que J pour parcourir tous les points avec la bonne ordonnée puis on filtre selon la distance. Tu ne pourras pas aller plus vite.
    Je pensais qu'il était possible de créer un premier ensemble avec l'index I et un deuxième avec l'index J, et de calculer l'intersection des deux. Mais je viens de faire le test avec PostgreSQL et EXPLAIN me confirme qu'un seul index est utilisé. Dont acte.

    Par contre:

    Citation Envoyé par Pyramidev Voir le message
    Si tu crées un index I qui range tous les points dans un arbre binaire de recherche en triant sur l'abscisse, alors tu pourras faire une requête performante qui trouve tous les points avec une abscisse entre xA - 5 km et xA + 5 km. Cela correspond à deux recherches en O(log n) dans l'arbre binaire pour trouver les deux bornes. Entre les deux nœuds, il n'y aura que les points avec la bonne abscisse.
    Non, il n'y a qu'une seule recherche: une fois que tu as trouvé le minimum (x - 5) tu peux parcourir l'arbre en sens inverse, il est trié correctement jusqu'à (x + 5). En plus de cela souvent les bases de données utilisent des arbres B+ qui ne sont plus tout à fait des arbres, leurs feuilles les plus profondes sont liées comme une liste triée (voir ici par exemple) justement pour permettre de faire des recherches par intervalle.

    Maintenant je reviens au problème initial, j'ai continué d'y réfléchir.

    Citation Envoyé par StringBuilder Voir le message
    Si tu crées un index (X,Y), comment fais-tu pour trouver tous les points qui sont à moins de 5 km d'un point donné ?
    Pas d'autre solution que de lire l'ensemble des points !
    Un index (X,Y) c'est un arbre qui est construit en fonction de la relation d'ordre (a,b) -> (xA < xB ou xA = xB et yA < yB) : on indexe d'abord x et en cas de valeur identique, on se base sur y.
    Avec une requête telle que where x > -5 and x < 5 and y > -5 and y < 5, l'index sera utilisé, là encore je viens de vérifier avec Postgres.
    A part l'usage de deux indexes, ma méthode reste donc valable, mais encore faut-il comprendre qu'elle est en deux étapes. On reste d'accord que la requête précédente ne donne pas la liste des points qui sont dans le cercle mais dans le carré; par contre, tu appelles la fonction de calcul de distance seulement sur les résultats de cette requête, donc tu exclus au moins tout ce qui sort du carré et c'est déjà pas mal!
    Donc pour la deuxième phrase: non, pas besoin d'examiner tous les points.

    Citation Envoyé par StringBuilder Voir le message
    Maintenant, à partir du tracé des frontière d'un pays (polygone de quelques milliers de sommets) trouve l'ensemble des points qui sont contenus dedans.
    En fait c'est la même chose: tout polygone est quand même dans un rectangle. Donc non l'index ne permet pas de répondre directement à cette question, mais il permet au moins de réduire le champ de recherche et ensuite tu appelles la fonction disant si on est à l'intérieur sur sensiblement moins de points.

    Je travaille actuellement dans le monde de la traduction et on a un problème similaire pour trouver des phrases similaires (le but étant de s'inspirer d'anciennes traductions pour assurer la cohérence dans le temps). La fonction qui calcule la distance entre deux phrases est en O(N²) et aucun index ne changera cela. En revanche, en utilisant certains découpages de chaînes on peut créer un index qui élimine une grosse partie des phrases qui n'ont aucune chance de rester proches de la phrase en cours. Mais un deuxième filtrage reste nécessaire ensuite.
    Et au passage comme ils ont été cités, pour ce travail j'utilise des indexes GiST dans PostgreSQL, mais j'avoue avoir juste regardé les résultats, je n'ai pas cherché en détail leur mode de fonctionnement.

    Conclusion: les indexes ne peuvent pas tout, mais il faut penser à ne pas toujours vouloir tout faire en une seule requête.

    Citation Envoyé par redcurve Voir le message
    Votre conclusion est fausse car vous ne tenez pas compte d'une chose essentielle les structures de données sous-jacentes
    Mais encore? Je veux bien le croire mais dit comme ça ce n'est pas très convainquant, il faudrait quand même un peu plus de détails!

Discussions similaires

  1. Choix de logiciel de base de données pour un projet
    Par gissiou dans le forum Décisions SGBD
    Réponses: 10
    Dernier message: 08/03/2019, 12h51
  2. Réponses: 0
    Dernier message: 14/07/2018, 12h46
  3. IHM console pour logiciel de base de données
    Par kangourou_for_ever dans le forum Linux
    Réponses: 6
    Dernier message: 03/09/2006, 18h43
  4. procédure pour exporter et importer bases de données
    Par mariogarcia dans le forum SQL Procédural
    Réponses: 1
    Dernier message: 24/03/2006, 18h33
  5. Réponses: 4
    Dernier message: 18/01/2006, 22h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo