nicht angemeldet
Hallo !
Die Datenbank-Inhalte bestehen aus den Tabellen:
"Stadt"
"Stadtteile" (Stadt, erster, zweiter, dritter)
--------------------------------^^^^^^^--^^^^^^^^--^^^^^^^^
"Shops_1" (ID, Stadt, Liefergebiete [mehrere], Name, Adresse, URL)
-------------------------------------------------------^^^^^^^^^^^^
"Shops_2" (ID, Stadt, Liefergebiete [mehrere], Name, Adresse, URL)
Mit diesem Ansatz wird das m.E. immer noch nix.
Solche gleichartigen Informationen gehören - in Tabellenform gedacht - untereinander in Zeilen (= verschiedene Datensätze) und nicht nebeneinander in Spalten (=mehrere Felder im selben Datensatz).
Die Verbindung zwischen deinen zukünftigen Tabellen "Lieferbezirke" und "Shops" ist eine klassische n:m-Beziehung (n und m stehen nur als Platzhalter für evtl. verschiedene natürliche Zahlen) :
Jedem Shop liefert in 1 oder mehrere Lieferbezirke.
In jedem Lieferbezirk gibt es einen oder mehrere Shops.
Um diese Beziehung datenbank-technisch darstellen zu können, benötigst du eine zusätzliche 3. Tabelle.
In die 1. Tabelle trägst du die Lieferbezirke ein (jeden nur 1x).
In die 2. Tabelle trägst du alle Shops ein (jeden nur 1x).
Beide Tabellen haben idealerweise je ein Feld mit einer eindeutigen Nr (sog. Primary Key), wodurch sie eindeutig zu identifizieren sind (genauso wie Kunden stets eine Kunden-Nr erhalten).
In die 3. Tabelle trägst du nun einfach nur zeilenweise Paare diese Nummern ein, um der Datenbank zu zeigen, wer wohin liefert:
Feld : Bezirk: Shop:
---------- ---------
1 1
1 2
1 3
2 3
3 2
Die Datenbank weiß somit, in Bezirk 1 liefern Shop 1, 2 und 3, in Bezirk 2 nur Shop 3 und in Bezirk 3 nur Shop 2. Genausogut weiß sie andersherum aber auch, dass Shop 1 nur in Bezirk 1, Shop 2 in die Bezirke 1 und 3 und Shop 3 in alle Bezirke ausliefert.
Du bist in keiner Weise festgelegt, dass ein Shop max. in nur z.B. 10 Bezirke ausliefern könnte, was etwa bei deinem Tabellenentwurf der Fall wäre.
Von dem Gedanken für die beiden Kategorien zwei getrennte Shop-Tabellen anulegen, würde ich mich ganz schnell verabschieden. Solltest du später einmal 3 oder 4 Kategorien benötigen, stündest du dumm da. Ein einfaches Feld "Kategorie" in der Shop-Tabelle würde es auch tun.
Hinsichtlich der ersten 3 Shops pro Lieferbezirk wäre beispielsweise ein zusätzliches Feld "Rang" in der oben gezeigten 3. Tabelle denkbar, wo du diese Rangzahl selbst einträgst, oder, wenn es einfach nur irgendwelche 3 von vielen sein dürfen, brauchst du nicht einmal das. Eine einfache Beschränkung der Ausgabe auf die ersten 3 Treffer würde dann ausreichen (Limit 0,3).
Generell scheint es mir, dass du dir der Möglichkeiten, die dir eine Datenbank bietet, noch nicht bewußt bist, da du die Daten so anzuordnen versuchst, wie es dich für als Mensch am einfachsten und bequemsten erscheint.
Dem Computer macht es aber nur wenig aus, sich durch eine meterhohen Stapel von (virtuellen) Karteikarten zu wühlen, um die eine passende für dich zu suchen.
Ich beschäftige mich schon seit vielen Jahren mit Datenbanken und staune jedesmal aufs Neue, mit welch affenartiger Geschwindigkeit ein Datenbankprogramm Ordnung in Millionen und Abermillionen von Datensätzen bringt, die ich einfach nur wahllos und unsortiert untereinander geschrieben habe. :-)
Ich hoffe, ich konnte dir ein wenig auf den richtigen Weg helfen, wenn du dich jetzt selbst (dafür gibt es leider noch keine Programme) durch ein paar Datenbank-Handbücher und Tutorials wühlen _musst_.
Gruß,
kerki