Hood-Bildung - Gemeindegrenzen

Adrian Schmutzler mail at adrianschmutzler.de
Fr Sep 21 15:42:54 CEST 2018


Hallo,

naja:

50.00001

DECIMAL(7,5) sind 4 bytes
FLOAT sind 4 bytes
CHAR(8) sind 8 bytes

Ist also doppelt so groß. Die Größe ist uns aber furzegal, es geht um die Eignung als Index.

Die führenden Nullen sind uns auch egal: Wir cachen dann halt nicht die Koordinaten, sondern die Anfrage.
Wir wollen auch keine Bereiche abfragen, wir haben immer einen Router mit exakt einer Kombi aus lat und lon. (Außer du denkst an Partitioning oder so, aber bei ner so kleinen Tabelle ist das Unsinn. Ich überlege eher, ob man auf die Indizes ganz verzichtet, bei ein paar 1000 Routern kanns sein, dass der eh immer nen Table-Scan macht, weil das schneller ist. Und ohne Indizes haben wir kein Lock beim Einfügen.)

Aber es kann sein, dass die hohe Verteilung von Daten bei CHARS uns beim INSERT ein Problem macht (Problem: Wo muss ich beim Key einfügen; das ist ja genau das Locking-Szenario, das ich vermeiden will) und deshalb DECIMAL besser ist.

Müsste man halt alle Varianten mal ausführlich testen.

Ich werde das erstmal nicht tun, weil mir dieses Konzept einfach zu groß wird für eine Komponente wie den KeyXchange, die von zentralen Bedeutung ist und so schön funktioniert.

Grüße

Adrian


> -----Original Message-----
> From: Michael Fritscher [mailto:michael at fritscher.net]
> Sent: Freitag, 21. September 2018 15:20
> To: Freifunk Franken <franken at freifunk.net>; Adrian Schmutzler
> <mail at adrianschmutzler.de>; fff at mm.franken.de; 'Freifunk Franken'
> <franken at freifunk.net>
> Subject: RE: Hood-Bildung - Gemeindegrenzen
> 
> Moin,
> 
> chars sind deutlich(!) größer... außerdem sind vergleiche etc. _sehr_ viel teurer
> - und ausserdem muss man da mit führenden nullen und so aufpassen, damit da
> lexikalische Reihenfolge gleich nummerische  wird - wichtig  wenn man via
> queries auf einen Bereich einschränken möchte.
> 
> Viele Grüße,
> Michael Fritscher
> 
> Am 21. September 2018 14:16:59 MESZ schrieb Adrian Schmutzler
> <mail at adrianschmutzler.de>:
> >Hallo,
> >
> >das hat jetzt aber nichts mit der Verwendung als Primary Key zu tun.
> >
> >Da will ich ja einen möglichst einfachen Typ. Und wenn man die
> >Koordinaten eh verstümmelt, macht es noch mehr Sinn, gleich CHAR zu
> >nehmen.
> >
> >Grüße
> >
> >Adrian
> >
> >> -----Original Message-----
> >> From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of
> >> fff at mm.franken.de
> >> Sent: Freitag, 21. September 2018 14:00
> >> To: franken at freifunk.net
> >> Subject: Re: Hood-Bildung - Gemeindegrenzen
> >>
> >> Hallo Adrian,
> >>
> >> > Es ist problematisch, Indizes auf Float-Werte zu legen.
> >>
> >> Zu _Koordinaten_
> >>
> >> PostgreSQL/PostGIS ist ja speziell für die performante Verarbeitung
> >> grosser Datenmengen im Bereich Geo-Informatik gebaut.
> >> Deshalb gibt eigene Datenobjekte für Koordinaten
> >> und auch für komplette Geo-Objekte:
> >> - Point, LineString/Curve, Polygon, etc.,
> >> - MultiPoint, MultiLineString, MultiPolygon, etc.
> >> - 3D-Datentyp Geography
> >>
> >> Diese dienen m.W. direkt als Fremdschlüssel.
> >>
> >> Falls man in einem DBMS keinen für Koordinaten geeigneten Datentyp
> >hat,
> >> kann man Koordinaten auf wenige Nachkommastellen beschränken.
> >>
> >> Genauigkeit:
> >> ~10 m	4 Nachkommastellen
> >> ~1 m	5 Nachkommastellen
> >> ~10 cm	6 Nachkommastellen
> >>
> >> Mehr brauchen wir vermutlich nicht.
> >> https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten
> >>
> >> Mit herzlichem Gruss,
> >> Markus




Mehr Informationen über die Mailingliste franken