OpenOffice.info

von **DPunch** » Mi, 27.10.2010 15:53

Aloha

herz4 hat geschrieben:Tut mir leid, Dir widersprechen zu müssen: Nicht nur die Postlei[t/d]zahl meines Ortes hat mehr als einen, hier zwei Orte zugehörig, dass trifft für mehre hundert PLZ in Deutschland zu!

Das muss Dir überhaupt nicht Leid tun, denn Du hast ja grundsätzlich Recht - ich hatte mich allerdings so allgemein ausgedrückt, weil das Problem als solches ja eigentlich keins ist (bzw in meinen Erfahrungen nie eins war).
Solange der Empfänger z.B. eines aus einer derart aufgebauten Datenbank Serienbriefs sich nicht beleidigt fühlt, weil statt des Namens seiner 200-Seelen-Gemeinde der Name der benachbarten 200-Seelen-Gemeinde hinter der gleichen PLZ steht, ist das überhaupt kein Problem. Hin und wieder vielleicht ärgerlich für die zuständige Poststelle, aber das wars dann auch.

herz4 hat geschrieben:Jedenfalls ist für mich jetzt sicher, das die PLZ nicht UNIQUE sein kann, erst mit dem Ortsnamen zusammen!

Das widerspricht der kompletten Idee, denn dann kannst Du wieder Datensätze ala ("81477","Muenchen") und ("81477","Munchen") in die Tabelle stecken.

Ist auf jeden Fall ein streitbares Thema, ich persönlich hatte jedoch nie Probleme mit dem Auslagern in eine eigene Tabelle, die die PLZ als PK benutzt.

von **herz4** » Mi, 27.10.2010 14:43

@DPunch

Tut mir leid, Dir widersprechen zu müssen: Nicht nur die Postlei[t/d]zahl meines Ortes hat mehr als einen, hier zwei Orte zugehörig, dass trifft für mehre hundert PLZ in Deutschland zu! Ich habe mir gerade ein größeres File aus dem Netz gezogen, aus dem ich diese Daten habe. Es möge nicht das aktuellste sein - die sind kaum kostenlos zu haben - aber es hat sich nichts grundlegendes geändert! Nun bin ich dabei, diese Daten so aufzuarbeiten, dass sie mir dienlich werden, bestenfalls zusammen(!) mit dem Telefon-Vorwahlverzeichnis.

Jedenfalls ist für mich jetzt sicher, das die PLZ nicht UNIQUE sein kann, erst mit dem Ortsnamen zusammen!

Sorry!

von **DPunch** » Mi, 27.10.2010 13:48

Aloha

herz4 hat geschrieben:Es gibt in Deutschland nicht nur einen Ort zu vielen Postleitzahlen. Umgekehrt, zu vielen Ortsnamen - wie z.B. Neustadt - gibt es viele PLZ. Da krieg ich gerade UNIQUE gar nicht auf die Reihe ...

Jede Postleitzahl identifiziert eindeutig einen Orts-/Stadtnamen, insofern ist man da auf der sicheren Seite. Umgekeht geht das natürlich nicht aber das war auch nicht der Vorschlag

Die PLZ als Primärschlüssel oder mit einem UNIQUE - Constraint verhindert aber, dass z.B. einmal der Datensatz ("81477","Muenchen") und einmal der Datensatz ("81477","München") vorkommt.

von **herz4** » Mi, 27.10.2010 10:23

DPunch hat geschrieben:Eine Auslagerung, möglicherweise zusammen mit einem UNIQUE - Constraint über die PLZ, macht die Datenbank als Ganzes sicher fehlerresistenter.

Klingt für mich sehr interessant! Überhaupt, schönen Dank für's Einklinken.

Es gibt in Deutschland nicht nur einen Ort zu vielen Postleitzahlen. Umgekehrt, zu vielen Ortsnamen - wie z.B. Neustadt - gibt es viele PLZ. Da krieg ich gerade UNIQUE gar nicht auf die Reihe ...

Ich freute mich über weiteres "Einklinken" auch von Dir, DPunch!

René

von **DPunch** » Mi, 27.10.2010 09:16

Aloha

Wenn ich mich kurz einklinken darf:

Das Totschlagargument für das Auslagern des Ortes ist sicherlich die Normalisierung - da der Ortsname direkt von der PLZ abhängt, gebieten die Regeln der Normalisierung das Auslagern.

herz4 hat geschrieben:Ich "gleiche" das aus, indem ich '%Doberan%' herausfiltere, und beides erhalte: Bad D. und D. allein. Dann kann ich "reparieren"...
Du meinst, bei Dir kommt so etwas nicht vor?!

Nun, für ihn fällt dieses Reparieren nur an einer Stelle an - nämlich in der ausgelagerten Tabelle. Nach Deinem Prinzip müsstest Du dann allerdings *alle* vorkommenden Datensätze mit 'Doberan' ausbessern - und musst dabei noch höllisch aufpassen, dass Du nicht vielleicht auch noch ein "Doberanhausen" irgendwo in Deutschland mitänderst.
Eine Auslagerung, möglicherweise zusammen mit einem UNIQUE - Constraint über die PLZ, macht die Datenbank als Ganzes sicher fehlerresistenter.

von **herz4** » Mi, 27.10.2010 08:36

Neujuenger2010 hat geschrieben:Korrekt. Aber dann ziehe ich den Fehler wenigstens konsequent bei allen Münchnern durch und schiebs hinterher auf die Technik...

... scheint nicht ganz zutreffend.
Buchstabendreher oder Umlaut(öäü)-Umschreibungen(?) scheinen mir nicht relevant bei nur mittelmäßig gebildeten Datenbearbeitern (wie Dir). Aber, z. B. der Ort Doberan in der Nähe der wunderschönen Ostseeküste heißt eigentlich Bad Doberan. Kann sein, dass Dir der Fehler des fehlenden Bads nicht unterläuft. Bei mir halte ich das eher für möglich. Er würde wahrscheinlich nur dadurch provoziert, dass der Ort falsch geschrieben steht und von mir so falsch übernommen wird.
Ich "gleiche" das aus, indem ich '%Doberan%' herausfiltere, und beides erhalte: Bad D. und D. allein. Dann kann ich "reparieren"...
Du meinst, bei Dir kommt so etwas nicht vor?!

von **Neujuenger2010** » Mi, 27.10.2010 07:49

herz4 hat geschrieben: [....]
Auch bei der Eingabe von Ortsnamen in die Tabelle Ort können Fehler passieren: prinzipiell ist "Muenchen" so allein nicht ausgeschlossen!

Korrekt. Aber dann ziehe ich den Fehler wenigstens konsequent bei allen Münchnern durch und schiebs hinterher auf die Technik...

herz4 hat geschrieben: [Vorschlag Listenfeld mit "Autofill"]

Sicher auch ein möglicher Weg.

herz4 hat geschrieben: Wenn man erst den Ort einträgt, kann dann der Eintrag der PLZ analog verlaufen und bestenfalls unter Ausfilterung der für den Ort bekannten! Hier sind doch Fehler viel "abwegiger" (postalisch).

Naja, auch hier kann mal eine neue PLZ zu einem bekannten Ort dazukommen --> Fehlerpotential bei der Eingabe.

Ein völlig Fehleingabe-resistentes System wird es wohl nie geben. Dazu sind die User (bei meiner Datenbank: ich) viel zu erfinderisch in dieser Beziehung...

herz4 hat geschrieben: Mir scheint einfach die "Auslagerung" nur eines Merkmals - Ort - in eine gesonderte Tabelle allein aufgrund der daraus resultierenden Notwendigkeit des Join bei Abfragen und von Unterformularen in Formularen(!) zu aufwendig, vor allem im Hinblick auf Auswahlabfragen im Formular!
Ich bin weiter sehr an Deiner Argumentation interessiert, weil ich ähnlich gelagerte Probleme versuche zu lösen, die ich mir geschaffen habe ...
Schönen Tag wünscht
René

Hier muss ich dann aus der Diskussion aussteigen. Ich hab mich noch nicht ansatzweise mit Formularen geschweige denn Unterformularen (Abfragen hab ich ja bereits gelöst

) beschäftigt. Daher kann ich auch nicht beurteilen, welche Variante (Extra-Tabelle oder Kombinationsfelder) unter Berücksichtigung aller Einsatzmöglichkeiten die zweckmässigste ist.

Dir auch einen schönen Tag!

von **herz4** » Mi, 27.10.2010 06:51

Neujuenger2010 hat geschrieben:Korrekt. Bei erstmaliger Eingabe eines neuen Ortes muss ich diesen zuerst in der Tabelle "Ort" erfassen. Ob es da einen leichteren Workaround gibt, weiss ich nicht.
Mir ist bislang nur diese Methode eingefallen...

Auch bei der Eingabe von Ortsnamen in die Tabelle Ort können Fehler passieren: prinzipiell ist "Muenchen" so allein nicht ausgeschlossen!
Dein Ziel der Vermeidung von Schreibfehlern bei der Eingabe von Ortsnamen kann ich auch näher kommen, wenn ich den Ort mit in der Tabelle Kunden so wie auch die PLZ speichere, und beiden ein Listenfeld im Eingabeformular statt eines Textfeldes gebe, deren Liste ich mit der Abfrage nach bisher gespeicherten Ortsnamen bestenfalls nach abfallender Häufigkeit gefüllt erstelle, gar nicht erst ausklappen lasse dafür aber auf "Autofill" (weiß nicht wie's exakt heißt) einstelle. Wenn dann im Ort der erste Buchstabe eingegeben wird - angenommen "M" - wird automatisch der Ort vorschlagend eingetragen, der mit "M" beginnt und am häufigsten ist. Mit jedem weiter eingetragenen Buchstaben, wird die Auswahl spezieller, bis sie wünschenswert passt oder aber automatisch der "neue" eingetragen wird.
Wenn man erst den Ort einträgt, kann dann der Eintrag der PLZ analog verlaufen und bestenfalls unter Ausfilterung der für den Ort bekannten! Hier sind doch Fehler viel "abwegiger" (postalisch).
Mir scheint einfach die "Auslagerung" nur eines Merkmals - Ort - in eine gesonderte Tabelle allein aufgrund der daraus resultierenden Notwendigkeit des Join bei Abfragen und von Unterformularen in Formularen(!) zu aufwendig, vor allem im Hinblick auf Auswahlabfragen im Formular!
Ich bin weiter sehr an Deiner Argumentation interessiert, weil ich ähnlich gelagerte Probleme versuche zu lösen, die ich mir geschaffen habe ...
Schönen Tag wünscht
René

von **Neujuenger2010** » Di, 26.10.2010 20:33

herz4 hat geschrieben: [....]
Weiterhin hat mir Dein Verweis auf Wikibooks sehr gefallen, mit dem ich mich revanchieren kann und auf eine Deiner Fragen antworten will: http://de.wikibooks.org/wiki/Einf%C3%BC ... erabfragen!

Bingo! Danke! ...*grummel*hättichauchselbstdraufkommenkönnen*grummel*

herz4 hat geschrieben: Deine "Entrümpelung" hat mir geholfen besser zu verstehen. Wahrscheinlich aus Gründen der Redundanz verzichtest Du in "Stammdatensätzen" sogar auf die Speicherung des Ortsnamens zugunsten eines Zeigers. Das ist sicherlich hilfreich um Daten bei Änderung leicht ändern zu können: dies muss man dann nur an einer Stelle. Ist etwa eine Anrede mittlerweile veraltet, modernisiert man sie. Bei Ortsnamen dürfte dies nicht das Angestrebte sein, was aber dann?

Bei Ortsnamen dient es einfach zur Vermeidung von Schreibfehlern.
Angenommen, ich möchte alle Kunden einer bestimmten Stadt selektieren. Dann rutschen mir bei der Abfrage alle Münchener Kunden durch, bei denen unter Ort z.B. "Muenchen" oder "Münhcen" o.ä. eingetragen wurde.
Gleichzeitig habe ich so bei Serienbriefen im Adressfeld immer die korrekte Schreibweise (sofern einmal korrekt in der Datenbak erfasst) stehen. Sonst wirds manchmal peinlich...
Evtl. gibt es ja auch mal eine "Eingemeindung", wo ein Ortsname plötzlich zu einem Ortsteil wird. Auch da ist es dann halt nur eine zentrale Änderung.

herz4 hat geschrieben: Ich sehe eine Schwierigkeit bei der Eingabe neuer Daten. So lange nur bekannte Ortsnamen einzugeben sind, easy. Was aber bei "neuen", besser unbekannten. In diesem Fall stößt doch ein etwaiges Kombifeld an seine Grenzen, oder? Ich meine, dann müsste der Datenpool Ortsnamen erst aktualisiert werden. Oder gibt es leichtere Methoden?

Korrekt. Bei erstmaliger Eingabe eines neuen Ortes muss ich diesen zuerst in der Tabelle "Ort" erfassen. Ob es da einen leichteren Workaround gibt, weiss ich nicht.
Mir ist bislang nur diese Methode eingefallen...

von **herz4** » Di, 26.10.2010 20:06

Hallo Neujünger2010,

ich danke Dir für Deinen Humor mit dem Du meinen Anflug von "Übelheblichkeit" - von wegen die Alten - ertragen hast!

Weiterhin hat mir Dein Verweis auf Wikibooks sehr gefallen, mit dem ich mich revanchieren kann und auf eine Deiner Fragen antworten will: http://de.wikibooks.org/wiki/Einf%C3%BC ... erabfragen!

Deine "Entrümpelung" hat mir geholfen besser zu verstehen. Wahrscheinlich aus Gründen der Redundanz verzichtest Du in "Stammdatensätzen" sogar auf die Speicherung des Ortsnamens zugunsten eines Zeigers. Das ist sicherlich hilfreich um Daten bei Änderung leicht ändern zu können: dies muss man dann nur an einer Stelle. Ist etwa eine Anrede mittlerweile veraltet, modernisiert man sie. Bei Ortsnamen dürfte dies nicht das Angestrebte sein, was aber dann?

Ich sehe eine Schwierigkeit bei der Eingabe neuer Daten. So lange nur bekannte Ortsnamen einzugeben sind, easy. Was aber bei "neuen", besser unbekannten. In diesem Fall stößt doch ein etwaiges Kombifeld an seine Grenzen, oder? Ich meine, dann müsste der Datenpool Ortsnamen erst aktualisiert werden. Oder gibt es leichtere Methoden?

Ich würde gerne mehr lernen ...

René

von **Neujuenger2010** » Di, 26.10.2010 17:41

herz4 hat geschrieben:@Neujuenger2010

Du scheinst mir, Dein Problem eleganter gelöst zu haben als durch meinen Vorschlag, der Dir schwer fiel zu verstehen.

In Wirklichkeit unterscheiden sie sich nach meiner Einschätzung nur syntaktisch - zu Deinen Gunsten!

Weiter so, immer besser sein wollen als die Alten ...

René

*rotwerd*

Danke!

Allerdings interessiert mich jetzt doch, wie und wozu man Unterabfragen einsetzen kann. Mein hier geschiildertes (und nun gelöstes) Problem, war ja quasi bei einer recht simplen Abfrage.
Meine Datenbank wird zukünftig noch etliche weitere Tabellen mit diversen Kundeninfos enthalten. Dann brauche ich auch komplexere Abfragen.
Es wäre daher sehr nett, wenn Du mir schon mal einen Hinweis geben könntest, in welchen Fällen Unterabfragen sinnvoll sein können und wie sie "funktionieren". Dann kann ich später rechtzeitig in die richtige Richtung denken...

Eine Frage habe ich zusätzlich noch zu der Syntax:

Ich habe meine Abfrage mal etwas "entrümpelt". Sie sieht jetzt so aus:

Code: Alles auswählen

select
	"Kunden"."Name",
	"Kunden"."Vorname",
	"Kunden"."Adresszusatz",
	"Kunden"."Strasse",
	"Kunden"."Hausnummer",
	"Kunden"."PLZ",
	"Ort"."Ort",
	"Anrede"."Anrede",
	"Titel"."Titel",
	"Briefanrede"."Briefanrede"	
from
	"Kunden"
	join "Anrede" on "Kunden"."Anrede" = "Anrede"."Anrede-ID"
	join "Ort" on "Kunden"."Ort" = "Ort"."Ort-ID"
	join "Briefanrede" on "Kunden"."Briefanrede" = "Briefanrede"."Briefanr-ID"
	left join "Titel" on "Kunden"."Titel" = "Titel"."Titel-ID"
	
where
	"Kunden"."Kategorie" = 1

Das finde ich persönlich etwas übersichtlicher, da jetzt "mein" wichtiges Filterkriterium "Kategorie" quasi alleine im "where"-Ausdruck steht. Ich seh also besser, was ich mit der Abfrage eigentlich suche.
Zudem kann ich problemlos (es funktionierte im test zumindest problemlos...) in die Ausgabe weitere Tabellen-Verknüpfungen einbinden, in denen es das gleiche (Leer-)Problem wie bei "Titel" gibt. Z.B. Geschlecht (nur als Test...):

Code: Alles auswählen

select
	"Kunden"."Name",
	"Kunden"."Vorname",
	"Kunden"."Adresszusatz",
	"Kunden"."Strasse",
	"Kunden"."Hausnummer",
	"Kunden"."PLZ",
	"Ort"."Ort",
	"Anrede"."Anrede",
	"Titel"."Titel",
	"GeschlRechtsform"."GeschlRechtsform"
from
	"Kunden"
	join "Anrede" on "Kunden"."Anrede" = "Anrede"."Anrede-ID"
	join "Ort" on "Kunden"."Ort" = "Ort"."Ort-ID"
	left join "GeschlRechtsform" on "Kunden"."Geschlecht/Rechtsform" = "GeschlRechtsform"."Geschl-ID"
	left join "Titel" on "Kunden"."Titel" = "Titel"."Titel-ID"
	
where
	"Kunden"."Kategorie" = 1

Ist das von der Logik und Syntax her korrekt?

Bitte bremst mich und schubst mich in die richtige Richtung, falls ich hier Unsinn lerne/probiere!

Danke!

von **herz4** » Di, 26.10.2010 15:42

@Neujuenger2010

Du scheinst mir, Dein Problem eleganter gelöst zu haben als durch meinen Vorschlag, der Dir schwer fiel zu verstehen.

In Wirklichkeit unterscheiden sie sich nach meiner Einschätzung nur syntaktisch - zu Deinen Gunsten!

Weiter so, immer besser sein wollen als die Alten ...

René

von **Neujuenger2010** » Di, 26.10.2010 13:00

herz4 hat geschrieben:Vielleicht gelingt folgendes:
Erstelle den SELECT-Befehl wie ehedem ohne Titel-Zuordnung! Benutze diesen als Unterabfrage, etwa wie:
SELECT * FROM (SELECT ... FROM ...) AS "A" LEFT JOIN "Titel" ON "A"."Titel" = "Titel"."Titel-ID",
wobei in Klammern Deine Unterabfrage steht. Achtung: "Kunden"."Titel" muss in Deiner Unterabfrage mit ausgegeben werden und kann dann bei Bedarf nur dadurch rausgenommen werden, dass anstatt * die Felder angegeben werden, die ausgegeben werden sollen.
Geht das?

Danke auch für Deinen Beitrag! Leider habe ich als Anfänger da noch Verständnisprobleme:

1.
Was meinst Du im ersten Satz mit "Titel-Zuordnung"? Worauf bezieht sich das? Kannst Du die entsprechende Stelle aus meiner Abfrage zitieren?

2.
Was genau soll ich in der Unterabfrage abfragen?

Vielen Dank im voraus für Deine Geduld mit einem Newbie!

von **Neujuenger2010** » Di, 26.10.2010 12:56

Neujuenger2010 hat geschrieben: [....]
Einzig

Code: Alles auswählen

SELECT "Kunden"."Name", "Kunden"."Vorname", "Kunden"."Strasse", "Kunden"."Hausnummer", "Kunden"."Adresszusatz", "Kunden"."PLZ", "Anrede"."Anrede", "Titel"."Titel", "Briefanrede"."Briefanrede", "Ort"."Ort", "Kundenkategorien"."Kategorie" FROM "Kunden", "Anrede", "Titel", "Briefanrede", "Ort", "Kundenkategorien" LEFT JOIN "Titel" ON "Kunden"."Titel" = "Titel"."Titel-ID" WHERE "Kunden"."Anrede" = "Anrede"."Anrede-ID" AND "Kunden"."Briefanrede" = "Briefanrede"."Briefanr-ID" AND "Kunden"."Ort" = "Ort"."Ort-ID" AND "Kunden"."Kategorie" = "Kundenkategorien"."Kategorie-ID" AND "Kunden"."Kategorie" = 1

funktioniert. Wirft aber leider ein ungewolltes Ergebnis aus: Es werden alle möglichen Kombinationen (Jeder Kunde mit jedem möglichen Titel) ausgeworfen.

[....]

Latürnich sollte man dann wohl vor "LEFT JOIN" die Tabelle "Titel" aus dem FROM auch entfernen....

Nach ein wenig einlesen in http://de.wikibooks.org/wiki/Einf%C3%BC ... n_abfragen habe ich jetzt folgende Abfrage:

Code: Alles auswählen

SELECT "Kunden"."Name" "Kundenname", "Kunden"."Vorname", "Kunden"."Strasse", "Kunden"."Hausnummer", "Kunden"."PLZ", "Kunden"."Adresszusatz", "Titel"."Titel", "Ort"."Ort", "Anrede"."Anrede", "Briefanrede"."Briefanrede"  FROM "Ort", "Anrede", "Briefanrede", "Kunden" LEFT JOIN "Titel" ON "Kunden"."Titel" = "Titel"."Titel-ID" WHERE "Kunden"."Kategorie" = 1 AND "Kunden"."Ort" = "Ort"."Ort-ID" AND "Kunden"."Anrede" = "Anrede"."Anrede-ID" AND "Kunden"."Briefanrede" = "Briefanrede"."Briefanr-ID"

Nach einem Test über einen Bestand von 10 Kundendatensätzen liefert die Abfrage das gewünschte Ergebnis.

Hoffentlich ist das nicht nur ein Zufall...

Wäre nett, wenn jemand bestätigen könnte, dass die Abfrage syntaktisch korrekt ist und meinen Abfragewünschen auch entspricht.

Danke!

von **boser** » Di, 26.10.2010 10:21

Hallo Zusammen,
ich hätte da die Frage , ob ein LEFT JOIN , bzw, RIGHT JOIN geht, wenn die Beziehung nicht entsprechend mit 1:n eingestellt ist.
mfg
boser

OpenOffice.info

[gelöst] Probleme bei Abfrage mit leeren Feldern

Antwort erstellen

Ansicht erweitern Die letzten Beiträge des Themas: [gelöst] Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern

Re: Probleme bei Abfrage mit leeren Feldern