Reprise du message précédent :

Solr est overkill pour ce que je veux faire. J'ai pas non plus besoin d'une seconde table simplement parce que l'ORM est infoutu de comprendre que je veux un index de type FULLTEXT

UPDATE Ville v SET zipcode = LPAD(v.zipcode, 5, '0')

 
Dites, c'est normal que ça fasse queudal?

UPDATE Ville v SET zipcode = LPAD(v.zipcode, 5, '0')

Non. Sauf s'ils faisaient déjà tous 5 caractères.
Ca fait vraiment rien, ou alors c'est seulement ton client qui t'affiche la même chose?

J'ai rajouté
 

WHERE LENGTH(v.zipcode) < 5

 
Mais  
 

SELECT COUNT(*) FROM Ville WHERE LENGTH(zipcode) < 5

c'est quoi comme sgbd? Le type du champ?
 

zipcode est bien  un char/varchar ?

Enfoiré c'était un int, il me dit rien ce con

edit: te manque sûrement un warning planqué et un strict mode à la con

Postgres:

Je peux pas te dire, mon mysql est locké depuis 10 bonnes minutes à cause du alter

C'est pas pour rien que myqsl va bien avec PHP

bof, oracle ne dit pas grand chose non plus, je pense, là-dessus...length(int) fonctionne sans rien demander, et l'affectation string=>int doit passer aussi, tant que le format du string est ok...

SQL server aussi l'accepte sans broncher

Ouaip, et

MEANWHILE, http://www.postgresql.org/docs/dev [...] e-9-3.html

J'ai déjà fait du GIS avec Postgresql mais pas avec Mysql, des retours là dessus?
 
Je veux faire une recherche par ville ou par departement/region et par radius autour d'un point.
 
J'ai déjà la plupart de mes points GPS (le reste ce sont des patelins, donc j'utilise Google pour combler les trous), le truc que je sais pas c'est comment placer/convertir ses points sur un model qui permette de faire mes recherches.
 
i.e:  Comment créer un Point "Paris" qui soit à l'intérieur de d'un Polygon "IDF"?

les derniers retours que j'ai eu de mysql spatial n’étaient pas bon du bons ( je crois que c'est 0x90 qui l'avait dit)

Bon, j'ai dégagé la recherche par region/département, je ferais simplement une jointure sur les tables correspondantes pour récupérer une liste de ville correspondantes.
 
Par contre pour la recherche par proximité:
 
http://www.arubin.org/files/geo_search.pdf
 
Sous forme de fonction ça donne ça ( à voir le type des paramètres );
 

DROP FUNCTION IF EXISTS distance;
 
CREATE FUNCTION distance(
  orig_lat VARCHAR(20),
  orig_lon VARCHAR(20),
  dest_lat VARCHAR(20),
  dest_lon VARCHAR(20)) RETURNS FLOAT
 
RETURN 3956 * 2 * ASIN(
  SQRT(
        POWER(SIN((orig_lat - ABS(dest_lat)) * PI()/180 / 2), 2)
      + COS(orig_lat * PI()/180 )
      * COS(ABS(dest_lat) *   PI()/180)
      * POWER(SIN((orig_lon - dest_lon) *   PI()/180 / 2), 2)
  )
);

SELECT *, distance('44.873807','-0.597832', v.lat, v.lon) AS dist FROM Ville v HAVING dist < 5;

SELECT *, distance('44.873807','-0.597832', v.lat, v.lon) AS dist FROM Ville v HAVING dist < 5;

 
Pourquoi having au lieu de where, je rate un truc?

Non, t'as raison, my bad.

Par contre ça risque pas d'être vachement lent, tout ça? J'imagine que t'en as un paquet, de villes...
Remarque t'as toujours l'option de précalculer les distances entre villes une à une plus tard si jamais ça s'avère trop lent...

C'est assez lent, mais par contre j'ai les champs lat, lon en VARCHAR, me demande si ça boosterait pas un peu de convertir le truc en FLOAT.

Sinon c'est bien HAVING qu'il faut mettre, ça doit etre considéré comme une fonction d'aggrégat.

SELECT count(id) FROM Ville;

ça pourrait être pire...faut juste pas avoir 40 appels par seconde, quoi.

Y'a pas un truc pour faire un ORDER BY sur la likeliness d'un LIKE 'foo%'?

pas compris. Un exemple de pseudo-requete et de résultat souhaité?

SELECT * FROM Matable m WHERE m.mon_champ LIKE 'foobar%' AS likely ORDER BY likely DESC;

Non mais LIKE c'est pas du fulltext.

Merci de ta contribution. Mais fulltext me renvoit des trucs un peu moisis, et renverra rien si j'ai 50% ma recherche matche plus de 50% de la table (MySQL ftw)

  SOLR  

Overkill. C'est pour de l'autocomplétion.

C'est sûr que c'est overkill. Mais juste pour l'expérience, je conseille tout de même d'essayer.
Mise en place d'un tomcat, un script d'import, un script d'update et un cron pour lancer les update régulièrement. C'est moins chiant que d'essayer d'utiliser du SQL pour un truc qu'il n'aime pas.
Et une fois implémenté pour l'auto-complétion, rien n'empêche de l'utiliser pour plus de choses.

SELECT * FROM Matable m WHERE m.mon_champ LIKE 'foobar%' AS likely ORDER BY likely DESC;

un levenshtein/jaro_winkler ou assimilé dans le select, et order selon cette colonne.

OK, je vais faire ça côté front alors.

 
Discuss.
 
En particulier, je stocke des événements relatifs à mes utilisateurs, genre "s'est gratté la tête le lundi 12 janvier à 16h46". Aujourd'hui, j'y ajoute la TZ "+02" (type PostgreSQL "timestamp with time zone" ).
 
Côté applicatif, c'est du Java + Joda Time.
 
Sur le thread http://stackoverflow.com/q/2532729, on conseille d'inclure l'offset + DST et d'enregistrer le nom de la TZ pour pouvoir reconstruire le timestamp d'origine. Ça va un peu à l'encontre de l'assertion de début de post, que j'ai rencontré un peu partout.
 
Du coup, UTC ou UTC+TZ ?

 
Pour moi, les deux. On stocke les dates en UTC pour être sûr de l'unicité (DST) et de l'ordre (TZ), calculer des différences entre deux dates. J'aurais tendance à dire que c'est la base.
 
Ensuite, quant à la pertinence de stocker aussi le TZ du lieu dans lequel l'action a eu lieu, cela correspond, selon moi, plus à un besoin applicatif, qui est d'afficher pour un événement l'heure locale reliée au lieu où l'action a été effectuée / observée.

Je pars du principe que quand c'est relatif à un seul utilisateur tu stockes tout en UTC et t'ajoutes la TZ à la volée, puisqu'elle peut varier. Après le DST est appliqué en fonction de la TZ, donc faut revenir à l'UTC à partir de là.

Edit: En fait tout pareil que Farian

 
Je lis vos réponses sur le tard.
 
Donc plutôt que '2013-05-15 13:55:00+02', je stocke '2013-05-15 11:55:00' en timestamp et '+02' dans une autre colonne ? Décimal signé ?

Est ce qu'il y a un équivalent a ON DUPLICATE KEY UPDATE en postgresql ?  
 

Pas vraiment http://www.postgresql.org/docs/cur [...] RT-EXAMPLE