Bestellungsdatenbank

Kampfgummibaerlie

Datenbank-Guru
Beiträge
728
Soda, nachdem ich mir vorgenommen habe, mich durch das Ganze buch zu zwingen, und ich angefangen habe, hier der Stand der Dinge:

Ja, es ist eine Bestellungsdatenbank direkt beim 1. Beispiel ^^

Ich habe ehrlich zu sein keine besonderen Fragen bezüglich PostgreSQL, eher nur, um mehr darüber zu erfahren. Mir ist klar, dass ich falsch angefangen habe, und mir vorher überlegen sollte, wie es am Ende sein sollte. (habe primary keys vergessen, foreign keys auch, und was weiß ich was :D)

Liegt wohl an der Uhrzeit, werde mich Morgen wieder damit befassen...
So, wie ich meine Mutter kenne, wird die auf meine Datenbank verzichten, und lieber das funktionierende System, welches monatlich was kostet, einfach zahlen. Aber ja, wenn ich schon dabei bin, wiederhole ich die Frage:
Was sollte man bei einer Bestellungsdatenbank tatsächlich alles machen?

Im Buch steht, dass man "Wiederholungen" vermeiden soll, in dem Sinne, dass man alles in einer eigenen Tabelle speichert, und als Foreign Key in die entsprechende Tabelle verknüpfen.
Sprich: Falls das Land Österreich 0815 mal in der Tabelle "Kunden" vorkommt, verbraucht es am Ende effektiv mehr Speicherkapazität, wie als wenn ich eine Liste der Länder extern speichere, und sie mittels Foreign Key verknüpfe? So hätte ich es jedenfalls aus dem Buch verstanden. (Scheint was für mich zu sein, weil fast alles (meine Frage zB nicht (bisher zumindest) ausführlich erklärt wird.

Ich bin kein Experte in solchen Dingen, deshalb frage ich nach ^^

Um ein einfaches Beispiel zu haben:
Verbraucht es (auch in Datenbanken) weniger Byte, wenn ich 0815 Verknüpfungen erstelle, welche wiederum auf eine andere Tabelle zugreifen, und von dort den entsprechenden Wert nehmen?

Am Desktop-PC ist dem so, aber ich kann mir nicht vorstellen, dass das bei Datenbanken (beinahe) genauso funktioniert.
Danke für Antworten :)

Glas Wasser trinken, und Fernseher anwerfen.
 
Werbung:
Es geht meist nicht um den Speicherplatz sondern um Konsistenz der Daten.
Angenommen irgendwann wird Österreich in etwas anderes Umbenannt. Dann muss man dies 815x die Einträge ändern, sonst nur einmal.
Und wenn wir schon bei dem Beispiel sind. Was glaubst du wie unterschiedliche (falsch) man Österreich schreiben kann. Dann wohnt Kunde 1 in Österreich, Kunde 2 in Östereich, Kunde 3 in Oesterreich und Kunde 4 in Österreih.
 
Der Sinn von Foreign Keys ist nicht in erster Linie Speicherplatz zu sparen, sondern ein in sich stabiles und robustes Datenmodell zu haben, welches immer und unter allen Umständen konsistent ist.

Um eine Bestellung zu machen, hat man erst einmal eine Kunden-Tabelle. Diese hat einen Primary Key - z.B. die Kundennummer. In der Tabelle der einzelnen Bestellungen hast Du dann einen Foreign Key auf die Kundentabelle. Damit ist es nicht möglich, eine Bestellung zu einem nicht vorher angelegten Kunden zu erfassen. Und auch nicht, einen Kunden zu löschen, der Bestellungen hat, die dann 'in der Luft hängen würden. Es kann Dir also nicht passieren, daß in den Bestellungen eine Kundennummer auftaucht, die es in der Kundentabelle nicht gibt.
 
Werbung:
Habe mir die ersten 100 Seiten des Buches angeschaut.
Womit ich mich (was in den 100 ersten Seiten vorhanden ist) wäre eigentlch nur das mit Cascade und Restrict.

Habe auch die paar Informationen bezüglich der Foreign-Key-"Regeln" gelesen (ich nenne es mal Regeln).

Ich glaube, die Vermietungstabelle fällt deutlich "einfacher" aus, als eine Bestellungstabelle. (Ja, mir ist klar, dass ich dazu mehrere Tabellen brauche).

In dem Buch werden 11 Tabellen zwecks Bestellungen verwendet, ich zähle mal schnell auf, was ich mir gemerkt habe:
1.: In dem Buch wird von Kunden gesprochen (klar)
2.: In dem Buch wird von Artikeln gesprochen (klar)
3.: In dem Buch wird von Bestellungen gesprochen (klar)
4.: In dem Buch wird von Ländern gesprochen (denke ich, könnte ich auslassen, weil ich, wenn ich ehrlich sein darf, wohl keine internationalen Geschäfte erwarten darf)
5.: Eine Tabelle "Verlag", sprich Geschäfte, wo ich den Stoff etc. herbekommen würde, was ich glaube ich in meinem Fall auch entfällt, weil Mutter meistens persönlich einkaufen geht, und nimmt, was sie braucht/ihr gefällt.
6.: Adressentypen (Lieferadresse, Rechnungsadresse)

hier hörts dann auf, habe das Buch aber auch, eher umflogen, als aktiv gelesen, um es mir auch zu merken.

Wäre aber durchaus dankbar, falls ich auch hier noch den nötigen Tritt bekomme, falls ich in die falsche Richtung steuere.

Ich meine, ich war mein ganzes Leben kein Fan vom Lesen, aber muss offenbar doch noch irgendwann damit anfangen ^^ (Die ersten 75 Seiten oder so, habe ich mir durchgelesen, und habe dann nach und nach nach Texturen gesucht, die ich noch nicht kenne.)

Anbei am Ende meine Frage:
Lauft eine Datenbankplanung so, dass man beim "Endprodukt" anfängt, und die Tabelle mit Endprodukten in ein jede kleinstmögliche Kategorie unterteilt?
(Glaube meine Programmier-Schwester hat es mir irgendwann mal grob so erklärt, aber ja, die ist eben eher die Homepage-Macherin)

Werde noch ein wenig spielen, und dann wohl ins Bett gehen ;)
Wollte nur nicht den Anschluss an euch verlieren xD
 
Zurück
Oben