Frage zum Tabellenaufbau

[Johannes23]

#12 war eine ernsthafte Frage, ich sehe es so wie hellbringer in #10.

Ich sehe es auch wie hellbringer. Das ist aber nicht die Frage: Es ist einfach objektiv richtig. Und begründet. Trotzdem gilt stets: "Du darfst dich nicht erwischen lassen!"

Und wenn Du schon so einen Schwachsinn raushaust -- Luther beliebte zu furzen.

Falsch. Er pfurzte, wenn er es tat oder furzte, je nachdem, welche Schreibweise dir beliebt.

[Midget]

Morgen allerseits,

Tatsächlich hängt es aber davon ab, ob hier eine zu zertifizierende ERP-Software erstellt wird, oder ob nur irgendwelche Rechnungen, die äußerlich den Formkriterien entsprechen, ausgeworfen werden sollen, um anschließen säuberlich abgeheftet zu werden.

Weit gefehlt ... ist nur als Übung gedacht . Ich arbeite mich grade in mein Programmierbuch "MYSQL für DUMMIES" ein und möchte gleich mit ner soliden Basis anfangen, bevor ich nach 2 Wochen wieder alles umbauen muss.

Variante 1:

Tabelle customer: id, name, delivery_address_id, invoice_address_id
Tabelle address: id, street, city, usw.

Nach euren zahlreichen gut gemeinten Vorschlägen werde ich mich mal an diese Variante rantrauen.

Danke schon Mal.

[protestix]

Bei deiner gezeigten Varianten hast du einen Fahler drin.

`id_kunde` INT NOT NULL,

Die Tabelle Kunde existiert nicht. Die referenzierte Spalte id ist zudem serial., also bigint unsigned und hier ist es int, das passt nicht, darauf musst du achten, dass Datentypen immer gleich sind.
Zudem solltest du beim den Tabellennamen darauf achten dass du immer die gleiche Form wählst, also immer singular und nicht einmal singular und ein anderes mal plural.

[erc]

An einer Fallunterscheidung bzw. wie wir es in der IT nennen, Kontrollstruktur kommt er eh nicht vorbei.

"Nukular! Das Wort heisst Nukular!". Kontrollstrukturen sind Konzepte aus Programmiersprachen die den Programmfluss steuern. In PHP z.B. if, else, goto, break, while, for, continue, return, include, exit usw... Du erkennst den Fehler?!

Die "Beziehung Auftrag <-> Kunde <-> Rechnungs-/Lieferadresse" ist eigentlich fürchterlich einfach zu modellieren: Wo eine Lieferung bzw. Rechnung hingeht, hat grundsätzlich in der Lieferung oder Rechnung zu stehen. Dort "darf" sie aber eben auch indirekt drin stehen. Also, indirekt:
[...]
Wie geschrieben: Der indirekte Weg, also Normalfall.

Sieht man wie "fürchterlich einfach" das ist. Das ist genau das was nicht funktioniert. Wenn die Beziehung zwischen Adresse und Auftrag über den Kunde abgebildet wird, hat jeder Auftrag eines Kunden die selbe Adresse. Das ist ein fundamentaler Designfehler.

[hausl]

Johannes23 ... unser neuer Samuel7, marie123, Alf2016? Jetzt kostet der Maskenball dann aber bald was.

[Midget]

PROTESTIX : bei Kollation nimmst du bei vorname, nachname und strasse utf8_german2_ci

Ich dachte, wenn ich UTF8 als Codierung nehme, hab ich kein Problem mehr mit Sonderzeichen wie Umlaute etc. ?
Hab mal gegoogelt und folgendes gefunden :

"As the character set, if you can, definitely UTF-8. As the collation - that's a bit nasty for languages with special characters. There are various types of collations. They can all store all Umlauts and other characters, but they differ in how they treat Umlauts in comparisons",

Verstehe ich das richtig : Ich brauche nur diese Kollation für Felder mit Sonderzeichen, die ich später evt. mit SELECT Abfragen sortieren möchte ?

PROTESTIX : darauf musst du achten, dass Datentypen immer gleich sind.

ah ok, ich dachte, ich bräuchte bloss drauf achten, ob das Feld numerisch ist oder einen String enthält.

[protestix]

Kollation ist die alphabetische Sortierung, hier deutsch Variante 2 unter https://de.wikipedia.org/wiki/Alphabetische_Sortierung
Zeichenkodierung sind hingegen die Bits und Bytes zur Interpretation eines Buchstabens, wenn du da was falsch machst bekommst du Zeichensalat dargestellt.

Wenn du noch am Anfang stehst, kann du dir auch gleich angewöhnen PDO mit Mysql zu nutzen, das macht hinterher einiges leichter.
Lies dazu mal https://php-de.github.io/jumpto/pdo/

[Johannes23]

Morgen allerseits,


Weit gefehlt ... ist nur als Übung gedacht . Ich arbeite mich grade in mein Programmierbuch "MYSQL für DUMMIES" ein und möchte gleich mit ner soliden Basis anfangen, bevor ich nach 2 Wochen wieder alles umbauen muss.


Nach euren zahlreichen gut gemeinten Vorschlägen werde ich mich mal an diese Variante rantrauen.

Danke schon Mal.

Die "Variante 1":
Tabelle customer: id, name, delivery_address_id, invoice_address_id
Tabelle address: id, street, city, usw.
ist m.E. keine gute Wahl. Gleiches gehört normalerweise in die gleiche Spalte. Da sich die Adressen in einer 1:n-Beziehung zum Kunden verhalten, ist die unter allen Gesichtspunkten naheliegende Lösung die Variante 2 (nach Hellbringer, #10). Wie er schon schreibt, kann ein Kunde dann mehrere Adressen haben. Vielleicht sollte man ergänzen: Es sind beliebig viele Adressen pro Kunde möglich. Es muß natürlich jeweils gesteuert werden, welche dieser Adressen genommen wird. Aber das ist lösbar, in #9 habe ich dargestellt, wie. Nutzt man außerdem noch die Möglichkeit eines Gültigkeitszeitraums, gibt es zwei Möglichkeiten:

• Die Adresse wird aufgrund des Gültigkeitszeitraums und des Adresstyps für den Standardfall ausgewählt.
• Die Adresse wird aufgrund der Angabe in der Tabelle Rechnung bzw. Lieferung ausgewählt. Daß das zuverlässig geschieht, wird durch eine IF(...,...,...)-Verzweigung im Ausdruck für die Ausgabe-Spalte der Abfrage sichergestellt.

Für die Rechnung kann dann noch zusätzlich die so ermittelte Adresse direkt in die Tabelle Rechnung kopiert werden, wenn man im Sinne Hellbringers formaljuristisch auf der sicheren Seite sein will.

[Arne Drews]

Weit gefehlt ... ist nur als Übung gedacht . Ich arbeite mich grade in mein Programmierbuch "MYSQL für DUMMIES" ein und möchte gleich mit ner soliden Basis anfangen, bevor ich nach 2 Wochen wieder alles umbauen muss.

Bei Übungen kann man sicher immer etwas variieren. Da Du Dir aber das Thema Rechnung als Beispiel vornimmst, sollte es tatsächlich auch aus wirtschaftlicher Sicht betrachtet werden. Und aus der Sicht ist die einzig sinnvolle Variante die von hellbringer und weiteren aufgezeigte.

[MOD: geschlossen]