Antworten auf deine Fragen:
Neues Thema erstellen

Grundsatzfrage DB-Aufbau

Josie1234

Nicht mehr ganz neu hier

Nach durchforsten des Webs nach einer Antwort, bin ich verwirrter als vorher.

Hintergrund:
Ich habe einen SQL-Datenbank mit ein paar Tabellen darin. Es sind Informationen über Veranstaltungen. Eines dieser Tabellen ist ziemlich groß, i.e. viele Spalten. Sie beinhaltet die Informationen über eigentliche Veranstaltung. Noch ist es überschaubar in Anzahl Datensätze. Ich bin dabei die ganze Seite neu zu stricken (versuche ein bisschen "sauberer" zu programmieren), und möchte, wenn ich schon dabei bin, auch den DB neu ordnen - halt wie es sein soll.

Datenbeispiele:
1. z.B. "Schwierigkeitsgrad" einer Führung. Es gibt Abstufungen: leicht, mittel, schwer. Also Einfachauswahl.
2. z.B. "Zielgruppe" einer Führung. Es gibt einige: Kinder, Jugendliche, Erwachsene, Familien. Also Mehrfachauswahl.

Nun meine eigentliche Frage:
Wie speichere ich diese beiden Fälle im Datenbank korrekt ab?
Füge ich einfach direkt die Auswahl in der Tabelle ein (Fall 1)? Hier möchte ich ggf. eine grafische Darstellung zu der jeweiligen mit in der DB vermerken (i.e. "schwer" = rot.jpg) für die Darstellung im Informationsblatt.
Füge ich eine Spalte für jeden Möglichkeit in der "Haupttabelle" ein und arbeite mit "true/false" (Fall 2)
Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?

Ich habe schon so viel über "serialize", "implode", "Normalisierung", und vieles mehr gefunden (und versucht zu kapieren). Und in verschiedene Foren die Empfehlungen gelesen. Zum Teil innerhalb eines Threads widersprüchlich.

Wenn also meine Fragestellung sich hier etwas verwirrt anhört, so stellt es genau mein derzeitiges Gemüt dar. *lach*
 

Duddle

Posting-Frequenz: 14µHz

Ein sehr guter Anfangspunkt ist für mich immer das Entity-Relationship-Modell. Mit diesem kann, mit etwas Übung, für die meisten Fälle mühelos die Problemdomäne modelliert und in einen Datenbankentwurf überführt werden.

In deinem Fall würde ich deine Domäne anfangs so beschreiben: eine Führung hat einen Schwierigkeitsgrad. Ein Schwierigkeitsgrad ist mehreren (das heißt keiner, einer oder mehr) Führungen zugewiesen. Das entspricht einer 1:n-Kardinalität. Überführt ergibt das zwei Tabellen:
Code:
Führung(id, bezeichnung, grad_id)
Grad(id, bezeichnung)
Dieses Mini-Beispiel (welches noch nicht alles wiederspiegelt) ist normalisiert. Das passiert (so weit ich weiß) immer automatisch, wenn das ERM korrekt formuliert ist.

Edit:
Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?
Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.


Duddle
 
Zuletzt bearbeitet:

dieterD200

Nicht mehr ganz neu hier

Ein sehr guter Anfangspunkt ist für mich immer das Entity-Relationship-Modell. Mit diesem kann, mit etwas Übung, für die meisten Fälle mühelos die Problemdomäne modelliert und in einen Datenbankentwurf überführt werden.

In deinem Fall würde ich deine Domäne anfangs so beschreiben: eine Führung hat einen Schwierigkeitsgrad. Ein Schwierigkeitsgrad ist mehreren (das heißt keiner, einer oder mehr) Führungen zugewiesen. Das entspricht einer 1:n-Kardinalität. Überführt ergibt das zwei Tabellen:
Code:
Führung(id, bezeichnung, grad_id)
Grad(id, bezeichnung)
Dieses Mini-Beispiel (welches noch nicht alles wiederspiegelt) ist normalisiert. Das passiert (so weit ich weiß) immer automatisch, wenn das ERM korrekt formuliert ist.

Edit:

Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.


Duddle


Hallo,
oder anders ausgedrückt: jede Information wird in einer DB nur einmal gespeichert.
Gruß Dieter
 

rafoldi

Aktives Mitglied

In meinen DB'S verfolge ich einen hohen Normalisierungsgrad (i.d.R. den 5'ten). Bedeutet schon einen hohen kognitiven Aufwand. Wo sind Wiederholungen etc.. Ebenfalls immer wieder Constrains nicht nur über zwei Tabellen sondern über mehrere Tabellen.
Beispiel
Auftragskopf - Auftragspositionen
- Kunde
- Artikel
- Liefer- Zahlungsbedingungen
- etc.

Da kommt schon eine Menge zusammen. weiterhin die Frage, eher bei MSSQL DB, nach nonclustered oder clustered Indexen.

Will nicht weiter in die Tiefe gehen, manches ist auch DB Spezifisch......
 

rafoldi

Aktives Mitglied

Zitat von Josie1234:
Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?


Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.

Duddle

Naja es werden von den DB's noch die alten where Verknüpfungen unterstützt wie
select * from t1, t2 where t1.id = t2.id
 
Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Antworten auf deine Fragen:
Neues Thema erstellen

Willkommen auf PSD-Tutorials.de

In unseren Foren vernetzt du dich mit anderen Personen, um dich rund um die Themen Fotografie, Grafik, Gestaltung, Bildbearbeitung und 3D auszutauschen. Außerdem schalten wir für dich regelmäßig kostenlose Inhalte frei. Liebe Grüße senden dir die PSD-Gründer Stefan und Matthias Petri aus Waren an der Müritz. Hier erfährst du mehr über uns.

Stefan und Matthias Petri von PSD-Tutorials.de

Nächster neuer Gratisinhalt

03
Stunden
:
:
25
Minuten
:
:
19
Sekunden

Neueste Themen & Antworten

Flatrate für Tutorials, Assets, Vorlagen

Zurzeit aktive Besucher

Statistik des Forums

Themen
118.616
Beiträge
1.538.358
Mitglieder
67.536
Neuestes Mitglied
QuestionMark
Oben