Forum im neuen Gewand

Hallo Gerald,

das mit dem Zeichensatz ist jetzt auch nichts, was unbedingt gleich sofort geändert werden müßte, ist zwar ein bißchen lästig, aber doch im erträglichen Bereich.

Bezüglich der Rebsorten-Dubletten hab ich in dem Gesamtbackup gesehen, daß es da einen Bereich gibt, der mit "Table: vkn_rebsorte" überschrieben ist, da gibt's zu jeder Rebsorte das "F_Synonym". Würde Dir das helfen wenn ich diesen Tabellenteil entsprechend überarbeite? Falls Du das dann mit minimalem Aufwand übernehmen könntest...

[Gerald]

Hallo Erich,

ja, das könnte sicherlich weiterhelfen. Daneben aber müssen natürlich aber auch die vielen Einträge mit Angabe der Zusammensetzung einer Cuvée entfernt bzw. auf "Cuvee" zusammengeführt werden und die Zusammensetzung einfach als Kommentar eingetragen. Denn wer wird schon in der Suchfunktion nach einem Wein aus 74% Tempranillo und 26% Garnacha suchen - und das nicht einmal finden, wenn der Verfasser der VKN das in umgekehrter Reihenfolge formuliert hat ...

Und bei den Regionen haben wir das Problem, dass eigentlich nur 2 Ebenen vorgesehen sind, die User aber teilweise bis zu 4 eingetragen haben. So kann man natürlich auch nicht suchen. Dazu kommt noch der - sorry - völlige Schwachsinn aus den DAC meiner Landsleute, wo je nach Rebsorte ein Wein aus einer ganz bestimmten Herkunft einmal "Niederösterreich" und einmal z.B. "Kamptal" (DAC) heißt - so etwas kann man auch schwer in einer Datenbank abbilden.

Grüße
Gerald

... wo je nach Rebsorte ein Wein aus einer ganz bestimmten Herkunft einmal "Niederösterreich" und einmal z.B. "Kamptal" (DAC) heißt - so etwas kann man auch schwer in einer Datenbank abbilden.

Ich sehe mich jetzt nicht als DB-Experten, aber das abzubilden, ist nachgerade trivial: Du brauchst nur eine "(Meta-)Regionentabelle" und eine n:1-Relation "anzuzeigende Region" -> Metaregion. Die Abbildung in der DB ist nicht das Problem, sondern die Erfassung bzw. Konsolidierung - wie eigentlich immer, wenn Freitext möglich ist und nicht nur aus einer vorgegebenen Menge ausgesucht werden kann.

[Gerald]

Danke, aber so einfach sehe ich das nicht (oder habe das Prinzip nur nicht verstanden?). Denn wenn jemand z.B. einen Wein als Frankreich - Bordeaux - Médoc - Pauillac eingibt, dann soll man bei der Suche nach Frankreich-Bordeaux diesen Wein ja auch finden. Wenn umgekehr jemand weniger Ebenen zur Eingabe nützt (Frankreich - Bordeaux), dann sollte die Suche nach Pauillac diesen Wein eben nicht finden. Ich müsste also alle - sagen wir - bis zu 4 Ebenen in der Datenbank abbilden und dann die Sache mit übergeordneter / untergeordneter Einheit in den Abfragen berücksichtigen. Bei bis zu 4 Ebenen wird schon die SQL-Abfrage allein ziemlich lang (und dann beschweren sich vielleicht die User, dass die Datenbank so langsam geworden ist ).

Grüße
Gerald

Auf das Thema "Ebenen" bin ich eben garnicht eingegangen, sondern nur auf die Frage (die ich möglicherweise mißverstanden habe), wie nach Weinen gesucht werden kann, die unterschiedlich angezeigt werden, aber aus derselben Region kommen. Und das geht mit einer zusätzlichen Abstraktion.

Was die Ebenen angeht:
Da müßte ich die Datenbankstruktur sehen, bevor ich mich traue, mehr dazu zu sagen. Was ich aber nicht glauben mag, ist, daß mit einer geeigneten Struktur und Indizierung die Abfragen zu langsam werden - so groß ist die DB nicht.

Aber recht wahrscheinlich ist das nur unqualifiziertes Reingequatsche von meiner Seite; Du hast Dir ja schon reichlich Gedanken dazu gemacht...

[Gerald]

Na ja, ich habe in meinem Brotberuf teilweise mit der Thematik zu tun (auch wenn ganz anderes Thema als Wein, ist die Sache mit den Hierarchien ähnlich) und die daraus resultierende Abfragen bremsen den Microsoft SQL Server (mit dem ich üblicherweise zu tun habe) doch deutlich aus. Ist aber möglicherweise nur ein Bug in der Optimierung des genannten Systems, bei MySQL vielleicht unproblematisch.

Das Hauptproblem bei Regionen und Rebsorten liegt meiner Ansicht nach vor allem darin, dass jeder User selbst da etwas eintragen kann, ohne sich mit der dahinterliegenden Logik zu beschäftigen. Nur wenn ich das nicht den User machen lassen, sondern auf Rückfrage selbst mache, dauert es immer ein bisschen und die User werden wiederum ungeduldig. Keine Ahnung, wie man das am besten lösen kann.

Grüße
Gerald

Genau das meinte ich: Es ist kein grundsätzliches Problem der Abbildung, sondern eher der (inkonsistenten) Erfassung.

[Gerald]

Ja, angenommen es gibt Margaux noch nicht als Region: dann dürfte man es bei der Neuanlage nicht einfach mit "Frankreich" verlinken, sondern auch (oder statt dessen, je nach Datenmodell) mit "Médoc" als Parent. Diese Option gibt es derzeit in der Oberfläche gar nicht. Aber selbst wenn es sie gäbe, gehe ich einmal davon aus, dass die Hälfte der neu eingetragen Regionen nicht richtig eingeordnet wären. Man müsste also entweder neue Regionen nur "auf Antrag" zulassen oder wie bisher und regelmäßig alles prüfen/nachkorrigieren. Beides leider ziemlich zeitaufwändig ...

Grüße
Gerald

Man müsste also entweder neue Regionen nur "auf Antrag" zulassen oder wie bisher und regelmäßig alles prüfen/nachkorrigieren. Beides leider ziemlich zeitaufwändig ...

...zumindest bei den Regionen könnte man das m.E. schon "auf Antrag" einführen, nachdem man da mal aufgeräumt hat. Denn da ist ja dann doch schon recht viel vorhanden und "echte" neue Regionen bzw. Bereiche dürften seltener und seltener werden. Vermutlich wird der Großteil der "Neuanträge" dann einfach fehlerhaft im Sinne der Regionen- / Berichsdefinition sein, vor allem denke ich da an die ganzen Appellationen etc., z.B. Vinho Verde ist halt keine Region, sondern einfach eine DO im Minho...

Das letzte VKN-Backup habe ich mir im November gezogen, irgendwann im Januar 2023 habe ich die tanzanischen Regionen Usambara und Dodoma eingefügt, danach kamen entsprechend den ID's noch 9 weitere Einträge, ist also m.E. überschaubar. Und da die Regionen in den einzelnen Ländern ja meist klar definiert sind, kann man hier auch mit überschaubarem Aufwand eine recht vollständige Basis schaffen, die m.E. nicht ständig einer unkontrollierten Erweiterung bedarf.

Dazu kommt noch der - sorry - völlige Schwachsinn aus den DAC meiner Landsleute, wo je nach Rebsorte ein Wein aus einer ganz bestimmten Herkunft einmal "Niederösterreich" und einmal z.B. "Kamptal" (DAC) heißt - so etwas kann man auch schwer in einer Datenbank abbilden.

...da muß man einfach ein bißchen pragmatisch sein. In weinlagen.org wurden die Regionen / Bereiche mal von Charlie aka Dr. Gierling neu geordnet, nachdem wir per Mailaustausch darüber diskutiert haben, könnte man m.E. gut als Vorlage nehmen.

Wobei ich es so handhabe, daß ein Wein -von dem ich weiß, daß er physisch da her kommt- z.B. in der Region Niederösterreich - Bereich Kremstal eingeordnet wird, egal ob da nun Kremstal DAC oder Niederösterreich draufsteht. Wenn man sich da unsicher ist, kann man ihn ja auch unter der Region Niederösterreich einordnen.

[Gerald]

Ja, vielleicht wäre das mit dem "Antrag" nicht so schlecht, da ja - anders als beim Start der Datenbank - das meiste ohnehin schon vorhanden sein sollte.

Wobei ich es so handhabe, daß ein Wein -von dem ich weiß, daß er physisch da her kommt- z.B. in der Region Niederösterreich - Bereich Kremstal eingeordnet wird, egal ob da nun Kremstal DAC oder Niederösterreich draufsteht. Wenn man sich da unsicher ist, kann man ihn ja auch unter der Region Niederösterreich einordnen.

Na ja, dann wird ein und derselbe Wein von Verkoster A unter Kremstal und von Verkoster B unter Niederösterreich eingetragen - nicht unbedingt im Sinn einer präzisen Datenbank. Wenn jemand eine Kundendatenbank hat und bei manchen Kunden steht der Wohnort, bei anderen nur das Bundesland drin, dann wäre das ja auch keine sehr gute Lösung.

Aber leider habe ich auch keine bessere Idee, wie man den DAC-Unfug auflösen könnte ...

Grüße
Gerald