Autor Thema: Rote Listen: DB-Entwurf  (Gelesen 2700 mal)

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Rote Listen: DB-Entwurf
« am: 2014-01-28 13:21:42 »
Da es hier ein paar Leute gibt, die beruflich mit Datenbanken befasst sind (Eveline, Michael), will ich mal einen Entwurf zur Diskussion stellen. Dabei ist anzumerken, dass die neuen aktuellen Roten Listen (RL) eine etwas andere Struktur haben als wir es von den alten gewohnt sind.

Vorhanden Tabelle:

Artentabelle
id, name, autor, id_familie

Für die RL denke ich an zwei neue Tabellen:

Tabelle rote_liste_land
id, wiki_vorlage, land, bundesland, geographische_region


Anmerkung:
- bei einer Bundesliste, z. B. für Gesamtdeutschland, bleiben die Felder 'bunesland' und 'geograpische_region' = NULL
- nicht jede RL unterscheidet geographische Regionen. In diesen Fällen bleibt 'geograpische_region' = NULL

Tabelle Rote_liste
id
id_art => Artentabelle.id
id_rote_liste_land => rote_liste_land.id
bestandssituation
langfristiger_bestandstrend
kurzfristiger_bestandstrend
gefaehrdungseinstufung
risikofaktoren
risiko


Bei der Kreation der Datensätze habe ich mich an der noch nicht erschienenen neuen RL Schleswig-Holstein orientiert.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #1 am: 2014-01-28 15:07:13 »
Warum die getrennten Felder für Land/Bundesland/Geographische Region? Eine Rote Liste beschreibt die Situation in einem Gebiet. Ggf. sind mehrere solche Gebiete in einem Dokument beschrieben. Es reicht also ein einziger Name für das Gebiet, also z.B. "Deutschland" oder "Bayern, Schichtstufenland" oder "Sizilien". Wenn mehrere Gebiete in einem Dokument sind, dann wird eben jeweils die gleiche Vorlage referenziert.

Wie willst du die Situation einer neuen roten Liste handhaben? Sollen da die alten und die neuen Daten in die Datenbank? Dann bräuchtest du noch eine Jahreszahl für die Rote Liste, damit man jeweils die neuesten Daten abfragen kann. Oder sollen dann die alten Daten gelöscht werden, bevor man die neuen Daten einpflegt?

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #2 am: 2014-01-28 15:18:41 »
Warum die getrennten Felder für Land/Bundesland/Geographische Region? Eine Rote Liste beschreibt die Situation in einem Gebiet. Ggf. sind mehrere solche Gebiete in einem Dokument beschrieben. Es reicht also ein einziger Name für das Gebiet, also z.B. "Deutschland" oder "Bayern, Schichtstufenland" oder "Sizilien".

Dies bedingt, dass man diese Regionalen Teilungen kennt. Wenn man diese Regionalabgaben abtrennt und z. B. Bayern abfragt, bekommt man die Regionen automatisch geliefert. Die DB wäre somit auch für andere mögliche Anwendungsfälle nutzbar. Ganz ohne Kenntnis, dass Niedersachsen in Hochland und Tierfland unterteilt oder Bayern mit "Schichtstufenland" u.s.w.

Zitat
Dann bräuchtest du noch eine Jahreszahl für die Rote Liste, damit man jeweils die neuesten Daten abfragen kann.

Die Jahreszahl steht ja in der Wiki-Vorlage ({{Literaur}}), aber  vermutlich wäre die Abfrage viel einfacher, wenn es ein Feld für die Jahreszahl gibt. Also fügen wir der Tabelle Tabelle rote_liste_land ein Feld 'Jahr' hinzu.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #3 am: 2014-01-28 16:12:48 »
Schon klar, dass man regionale Teilungen kennt. Die Frage ist aber, warum man in der Datenbank getrennte Felder dafür braucht? Es muss doch ein Zweck dahinterstehen? Was kann man damit machen, was man mit nur einem Namensfeld nicht kann?

Eveline Merches

  • Kerngruppe
  • ******
  • Beiträge: 3665
  • Altötting, Südostbayern, TK 7742-3
Re: Rote Listen: DB-Entwurf
« Antwort #4 am: 2014-01-28 17:30:12 »
Zitat
Schon klar, dass man regionale Teilungen kennt. Die Frage ist aber, warum man in der Datenbank getrennte Felder dafür braucht? Es muss doch ein Zweck dahinterstehen? Was kann man damit machen, was man mit nur einem Namensfeld nicht kann?
Ich habe es so verstanden, dass es nicht immer für alle drei Felder einen Eintrag gibt, je nach Liste finde ich nur Bayern, oder nur Deutschland oder eben Bayern und Schichtstufenland. Steht alles in einem Feld wird die Suche nach Bayern schwierig, wenn dort "Deutschland, Bayern, Schichtstufenland" oder nur "Bayern" oder "nur Bayern, Schichtstufenland" steht.
Ist alles getrennt, kann ich Ausgaben für "Deutschland" (Filter in Land), oder nur "Bayern" (Filter in Bundesland) oder nur "Schichtstufenland" (Filter Geografische Region ) machen. Zusätzliche Felder fressen ja kein Brot und sollten eigentlich nicht das Problem sein.
Wichtiger ist die Frage, ob das Aufteilen in diese drei Felder irgendeine Anwendung verhindert. Das müsste man sich dann anschauen.
Wenn man die Listen als CSV-oder Excel-Datei bekommen kann, könnte man eine Übernahmeprozedur schreiben. Da die Listen aber wohl noch einigermaßen überschaubar sind und nicht jährlich erneuert werden, ist eine händische Erfassung auch keine Strafarbeit.

Beim Aufbau der Tabellen ist es oft praktisch ein Feld "Bemerkungen oder Sonstiges" zu haben. Da kann man dann alles notieren, was in solchen Listen manchmal mit * markiert ist und als Fußnote eine ergänzende Info darstellt. So ein Feld hat bei uns immer 4000 Zeichen, damit einem der Platz nicht ausgeht. Meistens ist dieses Feld aber leer.

Ich habe aber noch ein paar Verständnisfragen:
Wenn eine neue Liste rauskommt, ist dann die alte ungültig? Wenn also eine Art nach einer alten Liste als gefährdet eingestuft war und in der neuen fehlt, muss sie aus unserer Datenbank für das Land gelöscht werden?
Sind die Herausgeber dieser Listen immer gleich, z.B. für Bayern?
Oder können da mehrere Autoren zum gleichen Gebiet eine Liste ausgeben?

liebe Grüße
Eveline



Ahme den Gang der Natur nach. Ihr Geheimnis ist Geduld.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #5 am: 2014-01-28 17:55:37 »
Das erzeugt interne Redundanz, und das ist nie gut. Bayern liegt immer in Deutschland, Sizilien immer in Italien. Ein Ländername ist überflüssig und kann schlimmstenfalls falsch sein (Tippfehler gibt es immer wieder, wie man gerade in letzter Zeit gesehen hat).

Der erste (und einzige?) Anwendungsfall ist ja, dass man für eine bestimmte Art alle Rote-Listen-Einträge braucht. Mit getrennten Feldern wäre das Ergebnis einer solchen Abfrage z.B.:

landbundeslandregiongefaehrdungseinstufung
DeutschlandNULLNULL1
DeutschlandBayernAlpenR
ItalienSizilienNULL2

Mit einem Feld:

gebietgefaehrdungseinstufung
Deutschland1
Bayern, AlpenR
Sizilien2

Was ist besser?

Mit getrennten Feldern muss man eigentlich auch immer alle abfragen, weil man sonst keine sinnvollen Ergebnisse bekommt. Wenn man z.B. nur das Land abfragt, dann bekäme man:

landgefaehrdungseinstufung
Deutschland1
DeutschlandR
Italien2

Das wäre Unfug. Entsprechend wenn man nur Land und Bundesland abfragt:

landbundeslandgefaehrdungseinstufung
DeutschlandNULL1
DeutschlandBayernR
ItalienSizilien2

Auch das wäre Unsinn, weil kein Gefährdungsstatus für das gesamte Bayern existiert.

Wenn man also immer alle drei Felder braucht, warum dann nicht nur eines?

Eveline Merches

  • Kerngruppe
  • ******
  • Beiträge: 3665
  • Altötting, Südostbayern, TK 7742-3
Re: Rote Listen: DB-Entwurf
« Antwort #6 am: 2014-01-28 18:12:07 »
Okay, das überzeugt, für die Ausgabe der gesamten Info.
Es gibt also keine Anforderung für Ausgaben welche Arten überhaupt für Deutschland oder überhaupt für Bayern gelistet sind? (unabhängig von Status)

RL Deutschland:
Araneus alsine 
Dolomedes fimbriatus
...
RL Bayern:
Xysticus cristatus 
Dolomedes fimbriatus
...

liebe Grüße
Eveline
Ahme den Gang der Natur nach. Ihr Geheimnis ist Geduld.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #7 am: 2014-01-28 19:27:04 »
1) Feldanzahl
Wie gesagt, das war erstmal eine rein logisch, nicht anhand möglicher Anwendungsfällen, ausgedachte Struktur. Für die Angabe der Region kann ich mich auch mit nur einem Feld begnügen. Für den primär gedachten Anwendungsfall, der Anzeige auf der Artseite, reichte es auf jeden Fall vollkommen aus:

Tabelle rote_liste_land
id, wiki_vorlage, land, bundesland, geographische_region

SELECT * FROM Artenliste AS a, Rote_liste AS rl, rote_liste_land AS rland
WHERE name='$ARTNAME' AND a.id=rl.id_art
AND rl.id_rote_liste_land=rland.id
ORDER BY rland.land

Dann käme die Angabe für Bayern immer vor Bayern Schichtstufenland u.s.w.

2) Feld Bemerkung
Mit einem 4000 Zeichen großen Feld "Bemerkung", das meistens leer ist, hätte ich mehr Bauchschmerzen. Da würde ich lieber eine Extraliste sehen; meinetwegen so:

Tabelle Bemerkung
id
tabelle
id_tabelle
Bemerkung

Um nun zur Roten Liste Bayerns einen Kommentar hinzuzufügen:
Tabelle rote_liste_land
id=55
wiki_vorlage='{{Lit checklist by}}'
land='Bayern'

INSERT INTO Bemerkung (tabelle, id_tabelle, bemerkung)
VALUES ('rote_liste_land', 55, 'Blah fasel Kommentar')

Ebenso könnte man einem Datensatz einer beliebigen anderen Tabelle einen Kommentar hinzu fügen, ohne dass diese Tabelle dafür irgendwie speziell vorbereitet sein muss. Für eine Bemerkung zur Tabelle selbst, lässt man id_tabelle=NULL.

3) Gültigkeit der Roten Liste (RL), verschiedene Versionen
Eine Rote Liste erstellt nicht irgend wer, sondern wird vom Umweltministerium des Landes herausgegeben. Es ist etwas offizielles.

Wenn es schon eine RL für ein Land gibt und es kommt eine neue heraus, baut die neue immer auf der alten auf. Der Fall, dass eine in der erten RL genannten Art in der neuen kommentarlos unter den Tisch fällt, ist eigentlich nicht denkbar. Aber theoretisch kann der Fall vorkommen, dass eine Art als Fehlbestimmung aus der Liste herausgenommen wird.

Ich könnte mir einen Marker vorstellen, der angibt, ob der Listeneintrag aktuell ist. Das erspart das Jahresfeld, welches ja für sich genommen, gar keine Aussage hat (es ist nur eine zu vermuten). Der Marker kann ein ASCI-Zeichen umfassen. Z.B. Aktualitaet: a=aktuell, v=veraltet, u=ungültig, n=neu unpubliziert o.ä. Das heißt, wenn eine neue Liste heraus kommt, sind wir nicht gezwungen die alten Daten zu löschen (man weiß nie, ob die in irgend einem Zusammenhang noch mal interessant sein könnten). Ebenso könnte man Daten für eine neue, unpublizierte RL schon mal eingeben (leider dauert es meist sehr lange bis eine eingereichte neue RL tatsächlich gedruckt wird -- bevor sie getruckt ist, sollten die Daten nicht anderswo [z.B. bei uns] veröffentlicht werden).

Also:

Tabelle rote_liste_land
id
wiki_vorlage
land
aktualitaet

Lieber wäre mir jedoch:
Tabelle rote_liste_land
id
wiki_vorlage
region
iso
aktualitaet


Für Bayern stünde bei iso='by'. Bei allen Einträgen.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Eveline Merches

  • Kerngruppe
  • ******
  • Beiträge: 3665
  • Altötting, Südostbayern, TK 7742-3
Re: Rote Listen: DB-Entwurf
« Antwort #8 am: 2014-01-28 20:24:39 »
Also so ein Bermerkungsfeld soll ja bei der Dateneingabe ggf. mitgefüllt werden. Da ist eine eigene Tabelle mit Fremdschlüsselbeziehung absolut überbewertet.
Zumal man ja die Info nicht mehr sofort sieht, nur wenn man sie dazujoined. Größe und Füllgrad eines Feldes machen doch heutzutage keine Speicherprobleme mehr. Aber wenn Du dennoch Bauchweh bekommst, lass das Feld einfach weg. Wir erleben hier in der Praxis halt oft, dass Infos mitgespeichert werden sollen, die in keines der "echten" Felder passen. Sie werden nur selten abgerufen, aber wenn dann soll es einfach möglich sein.

Für die Aktualitaet dürfen nur bestimmte Werte erfassbar sein. Deine Abfrage muss dann auf den Wert a=aktuell filtern, damit keine doppelten Einträge erscheinen. Da muss man natürlich genau aufpassen, wieviele Werte man da zulässt und ob die als "aktuell" interpretiert werden müssen.  Auf jeden Fall ist das besser als eine Jahreszahl.
Ganz entfallen würde dies natürlich, wenn man löscht und neu erfasst, aber wenn man die alten Daten noch mal brauchen kann ....
Die Frage ist natürlich, werden diese Daten jemals abgefragt, also irgendwo angezeigt? Wohl eher nicht, die unpublizierten dürfen nicht angezeigt werden. Wenn der "Datenbankbefüller" nun der einzige ist, der die Daten sehen kann, ist zu überlegen, ob der Aufwand lohnt.

liebe Grüße
Eveline
Ahme den Gang der Natur nach. Ihr Geheimnis ist Geduld.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #9 am: 2014-01-28 20:41:18 »
Unpublizierte Daten haben nur dann einen Sinn, wenn der Marker irgend wann zu 'aktuell' wechselt. Die Daten für die neue RL Schleswig-Holsteins sind seit 2009 fertig. Wahrscheinlich wird sie 2014 gedruckt. Da wäre nun gut 4 Jahre lang Zeit gewesen, die Daten schon mal in die DB zu schreiben. Sobald die RL offiziell veröffentlicht ist, kann man die Daten frei geben (alte müssen vorher auf 'u' gesetzt werden). Daten, die nie veröffentlicht werden dürfen, haben natürlich keine Existenzberechtigung in der DB.

Da die RL auch immer die Checkliste des Landes ist, kann es im Einzelfall interessant sein, auf die alten Daten zuzugreifen (evtl. doch mit einer Jahreszahl als Datenfeld, falls es mehrere ältere Versionen gibt). Vielleicht nicht in einer standardmäßig programmgesteuerten Abfrage, aber im Rahmen einer individuellen Recherche könnte man z. B. erfahren, wie viele neue Arten seit der Checkliste des Jahrs XY hinzu gekommen sind. Alte Daten können also weiterhin nützlich sein.

Zur Bemerkung
Natürlich kann man die Bemerkung bei der Eingabe mit eingeben. Dass die Bemerkung 'nur hinzugejoint' werden kann, finde ich nicht schlimm, denn dazu ist der JOIN-Mechanismus doch da.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Eveline Merches

  • Kerngruppe
  • ******
  • Beiträge: 3665
  • Altötting, Südostbayern, TK 7742-3
Re: Rote Listen: DB-Entwurf
« Antwort #10 am: 2014-01-28 21:04:38 »
Zitat
Natürlich kann man die Bemerkung bei der Eingabe mit eingeben. Dass die Bemerkung 'nur hinzugejoint' werden kann, finde ich nicht schlimm, denn dazu ist der JOIN-Mechanismus doch da.

Kann man bei MySQL in zwei Tabellen gleichzeitig Daten eingeben? Bei Oracle geht das nicht. Da muss das zu referenzierende Objekt erts in seiner eigenen Tabelle gespeichert werden, bevor man es in der anderen referenzieren kann.
Das Problem ist auch nicht der Join, sondern, dass man wissen muss, dass es noch eine Tabelle gibt, in der weitere Daten stehen. Wenn die Pflege der Datenbank wechselt oder die grauen Zellen anfangen zu schwächeln, dannstößt man auf die Daten womöglich nie mehr. Man sucht ja nur etwas, von dem man weiß, dass es da ist. Eine Tabellenspalte sehe ich und sehe auch wozu die gehört. Bei einer Tabelle die Bemerkung heißt, muss ich schon in den Inhalt gucken, für welche Tabellen die gilt.
Aber mir ist es auch egal, wie Du es machst, es ist ja nicht falsch und du hast ja nur nach meiner Meinung gefragt.

liebe Grüße
Eveline
Ahme den Gang der Natur nach. Ihr Geheimnis ist Geduld.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #11 am: 2014-01-28 21:19:57 »
Kann man bei MySQL in zwei Tabellen gleichzeitig Daten eingeben? Bei Oracle geht das nicht.

Ich dachte da eher an ein in php programmiertes Backend.

Zitat
Da muss das zu referenzierende Objekt erst in seiner eigenen Tabelle gespeichert werden, bevor man es in der anderen referenzieren kann.

Das wäre dann faktisch auch der Fall, aber in der Eingabe wäre dieser technische Hintergrund maskiert. So könnte man eine Liste von RL-Daten einlesen lassen (z. B. durch Hochladen einer Datei), die es zu ließe, dass einige Einträge mit Kommentaren versehen wären.

Zitat
Das Problem ist auch nicht der Join, sondern, dass man wissen muss, dass es noch eine Tabelle gibt, in der weitere Daten stehen.

Auch das würde das PHP-Programm erledigen, bzw. standardmäßig mit abfragen und den Kommentar ggf. mit in die Ausgabe einbauen. Wir arbeiten ja nicht direkt mit der Datenbank. Da ist immer ein Interface dazwischen.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #12 am: 2014-01-28 21:42:39 »
Das Kommentarfeld sollte eigentlich kein Platzproblem verursachen. Wenn man NULL zulässt und das Feld meistens NULL ist, dann wird dafür praktisch kein Platz verbraucht.

Vorsicht mit den Ländercodes! BY ist kein offizieller Code für Bayern! In ISO 3166 steht BY für Weißrussland! In ISO 3166-2 ist der Code für Bayern DE-BY.

Ich würde aber wirklich das Land/Bundesland/Region, für das eine Einstufung gilt, als einzelnen Namen in der Datenbank führen. Das nochmal aufzuteilen bringt wirklich nichts.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #13 am: 2014-01-28 22:41:54 »
Das nochmal aufzuteilen bringt wirklich nichts.

Leider findet man dann aber mit land LIKE 'Bayern%' alle Regionen, nur nicht Bayern selbst. Eine Abfrage auf iso='DE-BY' würde alle bayerischen Listen liefern. Auch die Gesamteinstufung für 'Bayern'.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #14 am: 2014-01-29 07:34:33 »
Ich hab es oben schonmal geschrieben: Es gibt keine Gesamteinstufung für Bayern. Wenn es sie gäbe, dann würde sie schlicht "Bayern" heißen. Warum sollte man nach 'Bayern%' suchen und dann nicht alle Regionen haben wollen? Ich versteh die Absicht einfach nicht.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #15 am: 2014-01-29 10:13:27 »
Ich hab es oben schonmal geschrieben: Es gibt keine Gesamteinstufung für Bayern.

Dann ist Bayern ein schlechtes Beispiel. Bei Niedersachsen ist das aber der Fall:
- Niedersachsen
- Niedersachsen Tiefland
- Niedersachsen Hochland

Zitat
Wenn es sie gäbe, dann würde sie schlicht "Bayern" heißen. Warum sollte man nach 'Bayern%' suchen und dann nicht alle Regionen haben wollen? Ich versteh die Absicht einfach nicht.

Es geht um die Nutzung der vorhandenen Daten über die Anzeige aller RLs hinaus.

Für die Anzeige auf der Art-Seite wird es tatsächlich nicht benötigt, frisst aber auch kein Brot. Bei anderlei Recherche in der Datenbank (die muss nicht zwingend programmgesteuert sein) kann es aber hilfreich sein. Z. B. um festzustellen, ob sich die Anzahl der bekannten Arten in Bundesland XY seit der Ausgabe YZ geändert hat oder anderweitige mögliche Fragestellungen.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #16 am: 2014-01-29 10:59:29 »
Niedersachsen ist eigentlich 3 Rote Listen in einem Dokument. Das ändert aber nichts am Prinzip. Eine Einstufung gilt genau für ein Gebiet. Dass manchmal ein Gebiet ein Teil eines größeren Gebiets ist, ist irrelevant.

Wie schon gesagt, wenn du alles was mit z.B. "Bayern" zu tun hat aus den Daten auslesen willst, dann kann man ja nach "Bayern%" suchen, und dann bekommt man genau das. Der Ländercode ist einfach überflüssig, er hilft dir hier kein Stück weiter.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #17 am: 2014-01-30 17:12:49 »
Wie schon gesagt, wenn du alles was mit z.B. "Bayern" zu tun hat aus den Daten auslesen willst, dann kann man ja nach "Bayern%" suchen

Ich habe das nun an einem anderen Beispiel ausprobiert (Steatoda albomaculata%). Du hast Recht! Ich dachte, das ginge so nur, wenn nach "albomaculata" noch weitere Zeichen kämen. Es geht also tatsächlich ohne. Damit wird die Sache einfacher, da man keine ISO-Codes raus suchen muss.

Also: Tabelle rote_liste_land
id
wiki_vorlage
region
iso
aktualitaet

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #18 am: 2014-01-30 17:47:52 »
Ja, der Operator % matcht beliebige Zeichen, einschließlich Null Zeichen.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #19 am: 2014-01-30 18:18:44 »
Und noch als Hinweis, falls das nicht sowieso klar ist: Viele Rote Listen enthalten keine weiteren Infos abgesehen vom Gefährdungsstatus. Die anderen Infos müssen also optional sein.

Martin Lemke

  • Administrator
  • *****
  • Beiträge: 14773
  • TK 2130 Lübeck, Schleswig-Holstein, Germany
    • Spinnenerfassung in SH
Re: Rote Listen: DB-Entwurf
« Antwort #20 am: 2014-01-30 21:35:44 »
Und noch als Hinweis, falls das nicht sowieso klar ist: Viele Rote Listen enthalten keine weiteren Infos abgesehen vom Gefährdungsstatus.

Alle neuen, die nach den aktuellen Richtlinien erstellt werden, haben diese Zusatzinformationen. Die neuen Felder müssen also den Wert NULL haben dürfen. Das ist korrekt. Fall die alten Listen eingelesen werden sollen.

Martin
Profil bei Researchgate.net

DAS waren noch Zeiten: Nowegen 2011.

Michael Hohner

  • Administrator
  • *****
  • Beiträge: 4851
  • Wo ist nun der versprochene Wurm?
    • Meine Spinnenfunde in Bayern
Re: Rote Listen: DB-Entwurf
« Antwort #21 am: 2014-01-31 07:31:17 »
Wir werden wohl noch jahrelang alte Listen haben.