Bonjour,
Ok pour la proposition de point cela me semble plus standard et plus stable dans le temps (Vu que beaucoup utilisent cette solution).
Pour le type de location
-Dictionnaire ?
-Enum ?
-Table ?
Je confirme avoir bien tous lus les messages précedents sans exception. J’étais aussi bien la quand tu en as parlé au devcamp. Et j’ai meme depuis passer plusieurs heures pour les valider, les tester et les enrichir. Et c’est justement parce que tenant compte de tous les messages, que je pense que stocker lat et long n’est pas forcément « sous optimal ». C’est un maniere d’apporter une reponse simple très fortement utilisée actuellement, à une grande majorité de cas d’usage actuel ou future et cela n’empeche aucunement l’usage d’un champ de type Point (qui doit etre vue comme une sorte d’index ou de champ précalculé de lat et long permettant des calculs, des fonctions specialisées, meme si la base a besoin d’un « champ » dédie pour cela plutôt que d’un simple index). Pour alimenter un tel champ, il est necessaire de connaitre la lat et long, donc cela n’a rien de deconnant de conserver les données sources d’une donnée « compilée ». D’autant plus que la plupart des cas d’usage jusqu’ici se sont parfaitement bien accomodés de lat et long qui a le merite de fonctionner sans risque d’incompatibilité, d’etre universel et suffisant pour de nombreux cas d’usage existant ou à venir (la plupart des api de geoencoding ou geoloc retournant ces 2 infos). Cela n’empeche en rien l 'usage de Point (puisque Point est une donnée compilée de lat et long selon un referentiel/algorithme donnée). On sait que ce type d’objet posera surement des problematiques d’infra, meme si supporté de longue date par postgresql, car requiert des extensions au niveau base, pas toujours dispo ou pas toujours utilisable de maniére commune d’une base à l’autre. Je vois donc le Point comme une info « complémentaire » pour des usages avancés et nullement une fonctionallité dont on doit se passer. Dans la mesure où il s’agit d’une info compilée selon un réferentiel donné, que l’on appelle dans un tel contexte une donnée « formatée », l’avoir en plus des données brutes, n’a rien de choquant.
1 « J'aime »
@eldy lorsque je parlait à Laurent dans mon message précédent c’était le Laurent @Lmag pas toi 
Mais bon… par contre ta réponse me laisse un peu dubitatif et je n’ai pas envie de batailler devant ce qui me semble être une énorme connerie: soit vous décidez de stocker long/lat dans deux champs de type float soit un seul champ de type point (plus une info qqpart du référentiel utilisé exemple WGS84). Mais pas les deux !!!
le « point » n’est que la manière optimale de stocker long/lat dans la base de données c’est tout … je ne vois pas pourquoi tu considère ça comme un index ?
je ne te suis pas du tout sur l’histoire de donnée source / donnée compilée … l’information est la même c’est juste le type de champ utilisé pour stocker l’information : le moteur de base de données permet de stocker long/lat dans un champ spécial « point » c’est super simple
un petit peu comme si nous voulions stocker une adresse ip en base de données avec un varchar parce-que c’est pratique et ça reflète les usages ? sans savoir par exemple qu’il existe la possibilité de stocker une ip sous la forme d’un long (voir ip2long et long2ip) offrant par la même une manière tout de même bien plus efficace de stocker l’information (et donc de faire des filtres)
partant de ton raisonnement, autant tout stocker en type blob ou varchar et basta ? non ?
pour le coup assez d’avis avec Eldy à savoir la conservation des champs servant à obtenir un résultat calculé pour de multiples raisons :
- perfs,
- si on change de mode de calcule, il faudra pour actualiser la donnée, connaitre le mode de calcul précédent
pour ce qui est d’utiliser float ou point, à part ajouter une contrainte technique sur la version de la base de données possédant ce type de champs, quand on sait déjà le bordel parfois entre de postgres, mysql et oracle…
Il faut se rappeler que les formats de données on été nécessaire au début de SQL pour optimiser la place des bases de données (les Mo étant tres cher à l’époque)
C’est ce qu’on appelle un acte de « dénormalisation » de la forme normale d’une base de donnée. De tel cas doivent se limiter au maximum s’est vrai.
Mais parfois il se justifie. Ici par exemple, par le fait que le type de donnée Point pose actuellement des soucis (syntax potentiellement différentes selon les bases de données, non support sur certains versions de base ou non dispo de l’extension pour la gérer sur de nombreux hébergement, voir évolutions d’une version à l’autre de base) qui obligera de toute façon à mettre 2 méthodes d’abstraction du genre buildSqlToInsertGeo() ou convertGeoSqlIntoLatLong(), lesquelles seraient propres au driver de base de donnée comme l’est la méthode d’abstraction ifsql() qui permet de rendre des fonctions SQL problématiques en non problème. Cela permet d’avoir un point central conditionné sur une option ou un état/version de la base pour s’adapter et rendre Dolibarr opérationnel dans tous les cas.
Le côté « énorme » d’une éventuelle erreur de choix me semble donc exagéré car on pourra passer de l’un à l’autre si on se trompe de voie en changer seulement ces 2 méthodes, lesquels ne feront pas plus que 5 lignes de code !
Le format Point a surtout été instauré pour permettre l’usage de fonction native propre de la base de donnée comme du calcul de distance ou comparaison entre 2 points, finalement comme un « index » (elle aussi manière de stocker la même donnée mais différemment pour un usage par des fonctions native internes à la base de donnée). D’où ma comparaison. Mais je conçois que ce n’est pas forcément une bonne comparaison.
En bref, tu penses que le fait que des experts aient spécifiquement bossés sur le sujet ne te semble pas être digne du moindre intérêt et que stocker deux float dans la base de de données est mieux ?
https://dev.mysql.com/doc/refman/8.0/en/spatial-types.html
C’est le 1er avril la ?
Je résume avec des données que tu connais peut-être mieux, disons que nous aurions à stocker le numéro du jour de la semaine, nous pouvons donc choisir par exemple un int (valeur 0 à 6), un tiny int non signé, un ENUM et toi tu dis que non un VARCHAR c’est mieux et tu me dis que c’est pour des questions de perfs ? gniiiii ?
Sauf que ton jour de semaine, il reste un jour de semaine et qu’un point à ce que j’en est compris est le résultat d’un calcul basée sur deux valeurs et une formule qui peu changer avec le temps.
A titre d’info, il m’est arrivé de conserver les dates dans un varchar au format YYYYMMJJ pour des problèmes de compatibilité de base de données et d’internationalisation, chacune ayant sa propre manière de gérer les champs de type date… la dénormalisation des données, particulièrement quand on s’inscrit dans une solution la plus ouverte possible fait parfois sens
J’ai dit que je ne bataillerais pas, je ne bataille pas, je regrette ce choix et j’aurais préféré qu’ils soit étayé de quelques exemples, tests, retex etc. et que nous aurions été voir du côté des outils libres de cartographie comment ils arrivent à « jongler » avec des moteurs de bases de données très différents (je pense à mapserver, qgis, etc.)
1 « J'aime »
Bonjour, (&bonne année)
Je ne sais pas quelles sont tes sources pour en avoir « compris » ça mais c’est dommage … peux tu perdre 2 minutes à essayer ceci sur un mysql/mariadb ?
CREATE TABLE `adresses` ( `rowid` INT NOT NULL AUTO_INCREMENT , `nom` VARCHAR(128) NOT NULL , `pos` POINT NOT NULL , PRIMARY KEY (`rowid`));
résultat (visible avec phpmyadmin)
Ajout de quelques entrées:
INSERT INTO adresses(nom,pos) VALUES ('plage', geomfromtext('POINT(44.66286 -1.18586)'));
INSERT INTO adresses(nom,pos) VALUES ('zoo', geomfromtext('POINT(44.5861 -1.1368)'));
INSERT INTO adresses(nom,pos) VALUES ('la corniche', geomfromtext('POINT(44.60222 -1.21037)'));
INSERT INTO adresses(nom,pos) VALUES ('bordeaux', geomfromtext('POINT(44.855 -0.571)'));
INSERT INTO adresses(nom,pos) VALUES ('mairie de la teste', geomfromtext('POINT(44.6313865 -1.1485677)'));
INSERT INTO adresses(nom,pos) VALUES ('mairie de toulouse', geomfromtext('POINT(43.6044375 1.4440504)'));
ça va c’est pas super compliqué quand même ? (quoi qu’il y ait quand même du temps à passer pour comprendre le x/y long/lat qui est peut-être inversé, vu l’heure j’ai pas forcément 100% vrai).
récupération des données et affichage :
SELECT rowid,nom,ST_X(pos) AS x, ST_Y(pos) AS y FROM adresses
Et ensuite ça permet de faire des bricoles du genre "lister tous les points triés par distance à vol d’oiseau du point x/y donné " …
SELECT rowid, nom, ST_X(pos) AS x, ST_Y(pos) AS y, ( GLength( LineStringFromWKB( LineString( pos, GeomFromText('POINT(44.6313865 -1.1485677)') ) ) ) ) AS distance FROM adresses ORDER BY distance ASC
Alors oui ça demande de faire des efforts, de se confronter à des « outils » / « concepts » qu’on ne maîtrise pas, de sortir de sa zone de confort mais de mon point de vue ça apporterait tellement de choses en plus que ça me semble en valoir largement la peine …
Mais bon …
1 « J'aime »
Donc à lire ce que tu expliques, j’avais bien compris 
Je crois que c’est plus un problème culturelle qu’autre chose : d’expérience j’évite au maximum de mettre du code, de l’intelligence au niveau des requêtes SQL.
Une base de données c’est fait pour stocker de la data, et d’expédience (oui encore), à chaque fois que l’on y ajoute des procédures stockées ou des fonctions avancées (genre pour les calculs sur les dates), c’est l’assurance que l’on va avoir des mauvaises blagues à l’intégration, prods, …
Cas d’école d’une intégration chez un client d’un appli il y a 20 ans, où je découvre que sa base de données et au format anglais, et que toute mes requetes SQL avec des calculs sur les dates foirent joyeusement.
Quand tu fais fait du « dev solo », c’est jouable mais quand tu diffuses un outils sur toute la planète, tu évites au possible les choses « exotiques » dans ton code
Là dans ton exemple , quand je vois des trucs du genre "GLength( LineStringFromWKB( LineString( " je fuis en courant… et ce n’est pas pour ne pas sortir de ma zone de conforts, juste que j’évite de me mettre des balles dans le pied.
Décidément, un monde semble se creuser entre nous … je t’invite donc à n’utiliser que des fichiers plats et pas de clés étrangères dans ton code ça risquerait d’être trop problématique …
Ok ma fois pourquoi pas … et donc peux tu me proposer une alternative avec un stockage long / lat sous forme de deux champs float dans la base de données pour lister 5 points et les distances à vol d’oiseaux qui les séparent ?
Ben sa passe par du code php, ne me fait pas croire que tu n’es pas capable de réaliser ce genre de chose en php?
… et donc sur le même principe si tu veux chercher dans ta base de données les 10 produits les plus chers tu fera tout ça en php et le sql ne serait qu’un espace de stockage de données brutes ?
Et sinon Bonne Année de Montpellier ! !
Géographique degré décimaux X: 43.62505 Y: 3.862038
DMS X: 43° 37’ 30.18" Y: 3° 51’ 43.34"
UTM (en mètres) Zone 31T X: 569547 Y: 4830590
Lambert 2 étendu (en mètres) X: 723283 Y: 1848213
X=Latitude Y=Longitude
Etsinonkikimodifilapr ? 
@erics @defrance. Nous on veut bien faire une autre tentative 
1 « J'aime »
Toute PR fermée est accompagnée normallement soit d’un commentaire (mention d’une autre pr doublon par exemple), soit d’un lien vers un commit qui a provoqué la cloture automatique de la PR (vérifie bien dans l’historique de la PR, si ce n’est pas le cas, indique la ref de la pr)
J’ai peut-être mal vu alors…
Bonjour
Je mets mon point sur les extrafields…
Tant qu’à faire, si on peut mettre autre chose qu’un point
Fred
2 « J'aime »
Bonjour
Exemple, j’ai un objet ‹ Champ agricole › je veux créer un extrafield Multipoint avec les limites géographiques du terrain… etc
Fred
2 « J'aime »
