Abfrage nach Anzahl der Stellen hinterm Komma

[ebs17]

Mein Vorschlag beschäftigt sich mit einer technischen Umsetzung, losgelöst vom inhaltlichen Sinn.

Ich kürze in einer zusätzlichen Spalte die MTB's auf die Zahlen hinterm Komma

Das entspricht dem Vorschlag von Klaus weiter oben hinsichtlich Normalisierung.
Die Ziffern nach dem Komma haben offensichtlich eine andere atomare Bedeutung als jene vor dem Komma. Also liegt es nahe, für sinnvolle spezielle Auswertungen den Gesamtausdruck zu zerlegen.

Konsequent und professionell ist es dann, diese Trennung einmalig auszuführen und die atomaren Inhalte in eigenen Tabellenfeldern abzulegen. Zusammensetzen bei Bedarf ist supereinfach, mit zusammengebandelten Daten umzugehen dagegen ist regelmäßig umständlich und schwierig, wie ja auch Deine Fragestellung verdeutlicht - und bei dem Kernproblem bist Du in vielfacher Gesellschaft.

Da die dritte Ziffer der rechten Seite eine sichtbare eigene Rolle spielt, müsste man die bis zu drei Ziffern der rechten Seite vermutlich ebenfalls in eigene Felder separieren. Das sind keine Zahlen mit Zahlencharakter, sondern Text-Zusammensetzungen aus Ziffern.
Die Prüfung würde sich dann darauf beschränken, ob dieses dritte Ziffernfeld einen Inhalt hat oder nicht.
Im professionellen Umfeld kann man dann Einzelfelder indizieren und diese Indizes bei Abfragen performanceerhöhend einsetzen - in Datenbanken gibt es potentiell viele Daten, die schnell zu verarbeiten sind.

[Mykis]

Hallo Klaus,

in einer zusätzlichen Spalte (MTB1) meiner Abfrage kürze ich die MTB's auf die Zahlen hinterm Komma. Es entsteht also eine ganze Zahl mit max. 3 Stellen. Wenn die Zahl dort kleiner 111 ist, wird bei Nordwert und Ostwert nix angezeigt.
Die resultierende Tabelle hänge ich zum Verständnis unten an.

LG
Frank

[Mykis]

Hallo Eberhard,

Konsequent und professionell ist es dann, diese Trennung einmalig auszuführen und die atomaren Inhalte in eigenen Tabellenfeldern abzulegen.

In meiner Datenbank wird dieses Procedere nur bei einer Abfrage benötigt. Der Aufwand soll sich also in Grenzen halten.
Vielen Dank für deine hilfreichen Erklärungen.

LG
Frank

[MzKlMu]

Hallo,

Die resultierende Tabelle hänge ich zum Verständnis unten an.

Die Tabelle hilft gar nichts. Im Gegenteil, jetzt bin ich noch mehr verwirrt. Wo kommen denn die Einträge für Nordwert und Ostwert her ?
Ich kann da keinerlei Zusamemnhänge zwischen MTB und diesen Werten erkennen.

Die in #13 gezeigten Formeln haben doch beide die gleiche Bedingung, wie sollen da Unterschiede zu Stande kommen?


Alles mehr als verwirrend, ich blicke es nicht.

Aber vielleicht bin ich ja besonders schwer von Begriff.

[ebs17]

Zur Eigenbewertung:

Der Aufwand soll sich also in Grenzen halten.

Eine Aufteilung ist unstrittig notwendig. Also beurteilen wir Aufwand.

1) Bei einem Datenimport in eine DB-Tabelle wird MTB einmalig aufgeteilt, die Einzelinformationen werden in eigene Tabellenfelder gespeichert und sind dort ständig verfügbar.
2) Bei der Abfragelösung erfolgt die Aufteilung von MTB pro Abfrageaufruf.

Wenn also die Abfrage mehr als einmal aufgerufen wird: Wo wird mehr Aufwand getrieben?

In meiner Datenbank wird dieses Procedere nur bei einer Abfrage benötigt.

Aus dem Kontext ist leicht entnehmbar, dass sowohl Du als Entwickler als auch die Datenbank als solche noch sehr am Anfang stehen. Datenbanken sind oft sehr langlebig, und insbesondere wenn Nutzer deren Vorteile nach und nach sehen und ahnen, steigen Anforderungen.

[Mykis]

Hallo Klaus,

Deutschland ist unter anderem in ein MTB-System eingeteilt. Das aus Quadranten, Viertelquadranten, Sechzentelquadranten etc. besteht. Die norwerte und ostwerte in meiner Tabelle sind Dezimalkoordinaten, die jeweils den Mittelpunkt des entsprechenden Quadranten in der Karte darstellen. MTB und Koordinate hängen also mathematisch zusammen. Jeder Fudort in meiner Pilzdatebank ist also durch ein MTB und diese beiden Koordinaten georeferenziert und kann in Karten z.B. durch einen Punkt dargestellt werden.

LG
Frank

[Mykis]

Hi Eberhard,

diese abgeschnittenen MTB benötige ich nicht noch einmal. Es geht nur um eine einmalig genutzte Exportfunktion für Funddaten. Deshalb wollte ich dafür nicht erst eine indizierte Tabelle mit diesen Werten anlegen. Aufwand wäre das natürlich keiner, da hast du ja Recht.

LG
Frank