-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Damit hast du natürlich vollkommen recht... Ich glaube so langsam verstehe ich euch. :)
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Das ist mir schon klar. Beide Varianten gehen, die Wartbarkeit der Ersten ist natürlich höher, aber dafür hat man keine aufgeblähten Tabellen. Ich glaube das ist eine persönlich Ansicht darauf: Entweder höherer Wartungsaufwand und schlankere Tabellen oder eben andersrum. Kann das sein? Einen anderen signifikanten Unterschied gibt es ja nicht, bis auf eventuell noch Performance.
>> Aber...
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Das finde ich auch, je mehr ich darüber nachdenke.
Ich stehe momentan wirklich auf dem Schlauch... Es ist mir erklärlich, weshalb ich alles in eine Tabelle packen sollte. Die würde dann ja irgendwie so aussehen:
Kategorie
ID
BookType
Costtype
Sub_Name
Main_Name
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
Hm... ich finde den Ansatz wirklich interessant. Nun kenne ich auch noch nicht so viele... Bei uns haben wir das alles ausgelagert in eigene Tabellen, um eben alles zu trennen. Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt. Und darauf dann einen Index... Klar geht das, aber habe noch...
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
Ich hatte auch mehr etwas im Kopf wie: Auftrag (Hauptkategorie), Auftragsposition (Kategorie), Auftragsunterposition (Unterkategorie). So wäre es nach seinem Beispiel, zumindest für mich.
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
Das ist wohl richtig, aber das sind im Regelfall doch auch Daten, die sich eben nicht weiter Normalisieren lassen.
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Verzeih, da hast du natürlich vollkommen Recht! Mein Fehler. :oops:
>> Also ich möchte meinen, dass Joins über Tabellen schneller gehen, als ein Select über eine Tabelle mit etlichen Massendaten. Vor allem wenn du dann noch sinnvolle Indizes angelegt hast.
>> Mag sein, aber du hättest dann eine riesige Tabelle mit zig Daten. Das kann doch nicht gut sein. Und durch eine Tabelle...
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Dann hast du eine Spalte die nur in 2 von 3 Fällen gefüllt ist? Ist das konsistent?
EDIT:
Aber in deinem Beispiel wäre es sowieso sinnvoller eine Artikeltabelle zu erstellen und darin eine Referenzspalte zu Kategorien einzubauen.
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
Ja, bei 10 Hierarchie-Ebenen dann 10 Tabellen. Es ist doch auch in Bezug auf Abfragen viel effizienter/performanter schmalere Tabellen zu haben, statt einer riesigen, mal davon ab, dass man somit keine Normalisierung erreicht. Aber eben diese sollte man doch anstreben oder irre ich mich?
Die Berufsschule ist knapp ein Jahr her, aber ich bin ziemlich sicher, dass das dort vermittelt wird und...
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
>> Stimmt, könnte man so natürlich denken. Bei unserem WaWi-Programm, gäbe es dann aber ein Stammdatenformular für Bankverbindungen. Hast du eine andere IBAN wäre das dann ein neuer Satz. Die IBAN ist ja immer eindeutig...
>> Ich sage da nur ein Stichwort: Normalisierung.
LG
-
Forum: Datenbanken
by StepByStep,
13. Apr 2018
Moin!
Zum Thema IBAN: Da schließe ich mich TigerLilly in etwa an, aber eine Banktabelle hast du quasi schon mit "bankaccounts". Du hast jetzt zwei Tabellen mit dem Feld "IBAN", was ein wenig Unglücklich hinsichtlich des Themas Redundanz ist. Du könntest du das Feld in "senderreceiver" entfernen, da du es über senderreceiver -> users -> bankaccounts bekommst.
Passwörter IMMER hashen! Niemals...
