Hallo,
Ich habe vor in nächster Zeit einen WebShop auf HTML,CSS,XML,PHP und
MySQL basis zu erstellen.
Dabei soll es möglich sein Kunden anzulegen, welche Bestellungen
aufgaben können. Diese Bestellungen bestehen aus einer vielzahl von
Artikeln.
Da ein Artikel jedoch auch in vielen Bestellungen vorkommt, habe ich
dies durch die Tabelle "Einzelartikel" zu einer 1 zu n Beziehung
umgeformt.
Die DB ist wohl in 3. Normalform.
Was haltet ihr davon?
Ist sie korrekt?
Grüße
Matze
Matze schrieb:> Was haltet ihr davon?
Für Fritz Müller in der Sensengasse reicht es, vorausgesetzt es ist
nicht die in Wien oder du bist Österreicher. Aber spätestens Kunden mit
doppeltem Vor- und spanischem Nachnamen, die in der Freiherr von
Münchhausen Strasse wohnen, treibst du zur Verzweiflung.
auch an der Bezeichnung würde ich noch arbeiten.
Warum Kundennummer, woanders ist es immer ID... also würde auch hier
IdKunde passen.
Warum Kunden_DAten, es sind doch die Kunden, also Kunden.
ArtikelSortiment würde ich auch als Artikel umbenennen.
Einzelartikel ist auch etwas ungünstig, da würde ich BestellungsPosition
verwenden.
Peter II schrieb:> auch an der Bezeichnung würde ich noch arbeiten.
Wenn man erst einmal anfängt, sich um Namen zu streiten, dann ist alles
zu spät. ;-)
A. K. schrieb:> Nuckel schrieb:>> Die Feldlängen müssen dynamisch sein.>> Das sind sie hier ja auch. Nur eben mit viel zu kurzem Limit.
Präziser: die Feldlänge soll nur von den Ressourcen begrenzt werden.
A. K. schrieb:> Peter II schrieb:>> auch an der Bezeichnung würde ich noch arbeiten.>> Wenn man erst einmal anfängt, sich um Namen zu streiten, dann ist alles> zu spät. ;-)
So sehe ich das auch. Dem TO ging es bestimmt in der Hauptsache um die
Struktur der Datenbank...
Nuckel schrieb:> Präziser: die Feldlänge soll nur von den Ressourcen begrenzt werden.
Um irgendwelchen Eseln die Chance zu geben, bereits mit dem Feld vom
Vornamen die Kiste an den Anschlag zu bringen, auf dass sie beim
Nachnamen abnippelt?
Ich bevorzuge es, in jeder Tabelle ein Auto Increment ID als PK zu haben
und den eigentlichen Identifier mit Unique als eindeutig zu
kennzeichnen. So hast du etwas mehr Flexibilität z.B. bei der Gestaltung
der Kundennummer.
Ich würde die Bezeichner auch alle englisch machen. Macht sich später
bei der Webanwendung einfacher, da deine Forms auch englische Namen
haben sollte um die Autofill-Funkion der Browser besser zu nutzen.
VG
Matthias
A. K. schrieb:>> Präziser: die Feldlänge soll nur von den Ressourcen begrenzt werden.>> Um irgendwelchen Eseln die Chance zu geben, bereits mit dem Feld vom> Vornamen die Kiste an den Anschlag zu bringen, auf dass sie beim> Nachnamen abnippelt?
was will man mit einem 1000 Zeichen Ort anfangen, ihn kann man eh nicht
auf das Paket drucken. Ich halte ein sinnvolle Obergrenze der varchar's
auch für sinnvoll.
> was will man mit einem 1000 Zeichen Ort anfangen, ihn kann man eh nicht> auf das Paket drucken.
Du hast Recht - ein Feld für Ort/Stadt sollte er auch noch hinzufügen
:-)
Huh schrieb:> So sehe ich das auch. Dem TO ging es bestimmt in der Hauptsache um die> Struktur der Datenbank...
Anzunehmen. Und ich will hoffen, es ist eine Hausaufgabe, kein ernst
gemeintes Projekt.
- Ein Feld für Adresszusätze wäre noch nett.
- PLZ sollte ein String sein. Man denke an Führende Nullen oder
Bindestriche
- Zusätzlich zu PLZ sollte der Ort erfasst werden, es gibt Orte mit
gleicher PLZ. Da diese entsprechend kleine Nester sind, neigen die auch
dazu, jeweils eine eigene Dorfstraße zu haben.
- Der Einzelartikel/Bestellposten bräuchte auch noch nen Preis, der hier
sitzen sollte, weil sich die Artikelauspreisung ja ändern kann oder
abhängig von der Anzahl und der aktuellen Staffelung ist.
Peter II schrieb:> was will man mit einem 1000 Zeichen Ort anfangen, ihn kann man eh nicht> auf das Paket drucken.
Ganz soviel brauchts nun nicht, aber:
* 58 Buchstaben:
https://de.wikipedia.org/wiki/Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch
* 168 Zeichen: Krung Thep Maha Nakhon Amon Rattanakosin Mahinthara
Yutthaya Mahadilok Phop Noppharat Ratchathani Burirom Udom Ratchaniwet
Maha Sathan Amon Phiman Awatan Sathit Sakkathattiya Witsanukam Prasit
(das ist der Name von Bangkok)
Matthias Q. schrieb:> Macht sich später> bei der Webanwendung einfacher, da deine Forms auch englische Namen> haben sollte um die Autofill-Funkion der Browser besser zu nutzen.
So eine Funktion soll die Felder so ausfüllen wie ich das sage und nicht
wie das Programm sich zusammenbastelt. Egal wie die Felder heißen.
T.roll schrieb:> Matthias Q. schrieb:>> Macht sich später>> bei der Webanwendung einfacher, da deine Forms auch englische Namen>> haben sollte um die Autofill-Funkion der Browser besser zu nutzen.>> So eine Funktion soll die Felder so ausfüllen wie ich das sage und nicht> wie das Programm sich zusammenbastelt. Egal wie die Felder heißen.
Stimmt, es ist extrem komfortabel bei der Entwicklung englischen
Quasistandard auf Eigenfrickelei zu mappen. Aber mach du...
Es macht wenig Sinn Name und Vorname zu trennen. Ausser dann die Kunden
sie vertauschen koennen.
Ich wuerd auch Strasse und Nummer nicht trennen. Recht haeufig duerften
Hausnummern wie 3a zu sein. Bei uns haben Haeuser etwas ausserhalb
einzelne Namen, also Strasse und Hausname
Es macht wenig Sinn PLZ und Ort zu trennen.
Eine Frage wie kleinraeumig das Ganze gedacht ist. Ich wuerd fuer PLZ
und Ort zusammen 32 Zeichen vorsehen. Dann stehen die beiden schon in
der richtigen Reihenfolge.
Aber mach mal. Etwas flexiblel sein. Es gibt noch viel zu lernen.
Zwölf M. schrieb:> Es macht wenig Sinn Name und Vorname zu trennen. Ausser dann die Kunden> sie vertauschen koennen.
Bei so manchem Namen weiß man nicht mal, was davon nun Vor- und was
Nachname ist. Auch für Standard-Formulierungen in Anschreiben ist es
nicht verkehrt, den Nachnamen sowie das Geschlecht zu kennen. Und für
das Sortieren und Filtern ist es auch ziemlich unklug, diese
Informationen zu verschmelzen.
> Ich wuerd auch Strasse und Nummer nicht trennen. Recht haeufig duerften> Hausnummern wie 3a zu sein. Bei uns haben Haeuser etwas ausserhalb> einzelne Namen, also Strasse und Hausname
Wenn man die Straßen separat erfasst, kann man mit einer vorgefertigten
Straßen-Tabelle die Eingaben zuverlässiger autovervollständigen und
läuft nicht Gefahr, dass 3 Kunden die gleiche Straße 3 x unterschiedlich
in die DB reinhacken.
Zwölf M. schrieb:> Es macht wenig Sinn PLZ und Ort zu trennen.> Eine Frage wie kleinraeumig das Ganze gedacht ist. Ich wuerd fuer PLZ> und Ort zusammen 32 Zeichen vorsehen. Dann stehen die beiden schon in> der richtigen Reihenfolge.
Auch hier wieder die latente Gefahr von Tippfehlern, die man nicht
unterschätzen sollte und die analog zu den Straßen bei einem WebShop
wegen der Zustellung dann auch richtige Probleme verursachen können. Ich
arbeite immer mit PLZ_Ort-Tabellen und ermittle den Ort anhand der
eingegebenen PLZ.
Sinnvoll gewählte englische Namen würde ich eigentlich auch empfehlen,
schon allein deshalb, weil man bei späteren Datenbank-Fragen auf z.B.
Stackoverflow die vielen ausländischen Helfer nicht mit deutschen
Tabellennamen verwirrt.
Abgesehen davon fehlt dem DB-Design leider noch viel zu viel, um damit
tatsächlich einen ernstzunehmenden Shop zu betreiben. Und mit dem
DB-Design alleine ist es ja nicht getan...bei diesen geringen Kentnissen
tippe ich mal, dass frühestens in ca. 1 Jahr der Shop so weit ist, dass
er einem der vernünftigen kostenlosen Shop-Systemen in einem früheren
Beta-Stadium ähnelt. Und zum damaligen Zeitpunkt waren diese kostenlosen
Shops ja noch meilenweit davon entfernt, fehlerfrei und zuverlässig zu
arbeiten.
Matze schrieb:> Ich habe vor in nächster Zeit einen WebShop auf HTML,CSS,XML,PHP und> MySQL basis zu erstellen.
Aus akademischem Lerntrieb? Es gibt bereits viele etablierte E-Commerce
Lösungen, nimm eine davon, wenn du was verkaufen willst.
> Auch hier wieder die latente Gefahr von Tippfehlern, die man nicht
unterschätzen sollte und die analog zu den Straßen bei einem WebShop
wegen der Zustellung dann auch richtige Probleme verursachen können.
Hin und wieder entstehen neue Strassen. Dh diese Auswahltabelle muss
immer aktuell sein. Woher nehm ich die ?
Das waer dann eine klare Beschraenkung auf das Inland. Wenn's um
verderbliche Ware geht und man fern der Grenze ist ...
> Ich arbeite immer mit PLZ_Ort-Tabellen und ermittle den Ort anhand der
eingegebenen PLZ.
Auch hier eine klare Beschraenkung auf das Inland.
Zum Glueck ist die Zuordnung Dorf - PLZ in der besagten Richtung
eindeutig. Ist sie das ? Eher nicht. Ich kann mich zB mit zwei
verschiedenen Postleitzahlen beliefern lassen.
Oh D. schrieb:> Zum Glueck ist die Zuordnung Dorf - PLZ in der besagten Richtung> eindeutig. Ist sie das ? Eher nicht. Ich kann mich zB mit zwei> verschiedenen Postleitzahlen beliefern lassen.
wie ich oben bereits erwähnte, ist es auch andersherum nicht eindeutig.
Teilweise haben 2 naheliegende Dörfer die gleiche PLZ und beide haben
die Obligatorische Dorfstraße mit gleichen Hausnummern
Oh D. schrieb:> Hin und wieder entstehen neue Strassen. Dh diese Auswahltabelle muss> immer aktuell sein. Woher nehm ich die ?
Derartige Ereignisse muss man nun wirklich nicht in Echtzeit
synchronisieren...die bedingte Wahrscheinlichkeit, dass Neue Straße S +
Person P wohnhaft in ebendieser Straße + Bestellung B in Deinem Shop
auftritt, ist um Größenordnungen kleiner als die Wahrscheinlichkeit von
Tippfehlern oder verschiedenen Schreibweisen durch die Kundschaft. Die
nicht erkannte Straße kann man nach Bestätigung vom Kunden dann trotz
fehlender Entsprechung diesem Kunden zuordnen.
Ich würde das mit der Aktualisierung dieser Tabellen auch nicht
überbewerten...die allermeisten Straßen werden bei den von mir
programmierten Datenbanken auch nach Jahren noch von veralteten Tabellen
abgefangen und genau darum geht es hier.
Oh D. schrieb:> Auch hier eine klare Beschraenkung auf das Inland.
Nein. Ich muss bei internationalen Shops sowieso das Zielland abfragen
und kann dann diese Beschränkung dynamisch deaktivieren oder mir
entsprechende Tabellen/Algorithmen für das Zielland organisieren.
Oh D. schrieb:> Zum Glueck ist die Zuordnung Dorf - PLZ in der besagten Richtung> eindeutig. Ist sie das ? Eher nicht. Ich kann mich zB mit zwei> verschiedenen Postleitzahlen beliefern lassen.
Und wo ist das Problem? Wenn es offiziell wirklich 2 oder mehr
verschiedene PLZ für einen Ortsteil gibt, dann ist das in der Tabelle
berücksichtigt und ich kann es mir aussuchen, unter welcher PLZ ich
beliefert werden möchte, denn sonst wäre die PLZ-Zuodnung ja unabhängig
von der Datenbank falsch.
Vlad T. schrieb:> wie ich oben bereits erwähnte, ist es auch andersherum nicht eindeutig.> Teilweise haben 2 naheliegende Dörfer die gleiche PLZ und beide haben> die Obligatorische Dorfstraße mit gleichen Hausnummern
Wenn es nicht eindeutig wäre, könnte kein Postbote die Sendungen
zustellen. Es muss also irgendwelche Zusätze geben, die ich analog zu
den anderen Orten in die Datenbank einpflegen kann(Musterort-Musterdorf1
versus Musterort-Musterdorf2). Es gibt kein Gesetz, dass es mir
verbietet, in der Tabelle hinter 2 gleichen Orten noch Dorf-Zusätze zu
ergänzen, so dass die Kunden aus diesen Dörfern den für sie richtigen
Eintrag wählen können. Alternativ könnte man auch hier die vom Kunden
eingegebene Information nach Rückfrage ungeprüft übernehmen, so lange
man sich damit nicht die Autovervollständigen-Tabelle verschmutzt.
Fast-H schrieb:> Wenn es nicht eindeutig wäre, könnte kein Postbote die Sendungen> zustellen. Es muss also irgendwelche Zusätze geben, die ich analog zu> den anderen Orten in die Datenbank einpflegen kann(Musterort-Musterdorf1> versus Musterort-Musterdorf2). Es gibt kein Gesetz, dass es mir> verbietet, in der Tabelle hinter 2 gleichen Orten noch Dorf-Zusätze zu> ergänzen, so dass die Kunden aus diesen Dörfern den für sie richtigen> Eintrag wählen können. Alternativ könnte man auch hier die vom Kunden> eingegebene Information nach Rückfrage ungeprüft übernehmen, so lange> man sich damit nicht die Autovervollständigen-Tabelle verschmutzt.
es ging ja darum, den Ort wegzulassen und aus der PLZ zu gewinnen.
Kombination aus Ort+PLZ sollte eindeutig sein.
Matze schrieb:> Die DB ist wohl in 3. Normalform.> Was haltet ihr davon?> Ist sie korrekt?
Du hast nicht beachtet, dass Kunden die Angewohnheit haben, umzuziehen,
zu heiraten oder anderweitig den Namen zu ändern.
Das gleiche trifft vermutlich auf die Artikel zu (Preisänderung,
Änderung der Bezeichnung etc.).
Die ursprüngliche Bestellung sollte zu Prüfzwecken (z.B. für
Steuerprüfungen) auf jeden Fall nachvollziehbar sein. D.h. Du musst die
Kundendaten in die Bestellung kopieren. Das kann man in Tabellenform
machen, man kann aber auch XML oder JSON Felder dafür benutzen.
D.h. diese Daten eignen sich nicht für eine Normalisierung wie in Deinem
Schema dargestellt.
Wenn es keine Programmierübung sein soll, würde ich auch eher zu einem
fertigen Shop greifen. Die Einarbeitung in Layout und Logik mag etwas
länger dauern, aber dafür sind solche Randbedigungen dabei in der Regel
berücksichtigt.
Klaus P. schrieb:> Die ursprüngliche Bestellung sollte zu Prüfzwecken (z.B. für> Steuerprüfungen) auf jeden Fall nachvollziehbar sein. D.h. Du musst die> Kundendaten in die Bestellung kopieren. Das kann man in Tabellenform> machen, man kann aber auch XML oder JSON Felder dafür benutzen.
Das kann man garnicht stark genug betonen, alles archivrelevante
entsprechend zu behandeln und abzulegen. Ein guter Anhaltspunkt ist sich
zu überlegen, was alles auf der Rechnung erscheint und über die Zeit
auch immer wieder so auf der Rechnung erscheinen sollte würde man sie
neu generieren.
Ansonsten VARCHAR(1) fürs Geschlecht wird heutzutage schon sportlich.
D. I. schrieb:> Matze schrieb:>> Ich habe vor in nächster Zeit einen WebShop auf HTML,CSS,XML,PHP und>> MySQL basis zu erstellen.>> Aus akademischem Lerntrieb? Es gibt bereits viele etablierte E-Commerce> Lösungen, nimm eine davon, wenn du was verkaufen willst.
So sieht's aus. Man erfindet das Rad nicht neu wenn man nicht muss.
Zumindest dann nicht, wenn es schöne und gut funktionierende Räder zu
einem vernünftigen Preis zu kaufen gibt.
Mark B. schrieb:> D. I. schrieb:>> Matze schrieb:>>> Ich habe vor in nächster Zeit einen WebShop auf HTML,CSS,XML,PHP und>>> MySQL basis zu erstellen.>>>> Aus akademischem Lerntrieb? Es gibt bereits viele etablierte E-Commerce>> Lösungen, nimm eine davon, wenn du was verkaufen willst.>> So sieht's aus. Man erfindet das Rad nicht neu wenn man nicht muss.> Zumindest dann nicht, wenn es schöne und gut funktionierende Räder zu> einem vernünftigen Preis zu kaufen gibt.
Nicht umsonst gibts gefühlt 1000 Webbutzen, die sich auf "E-Commerce"
"spezialisiert" haben...
Zwölf M. schrieb:> Es macht wenig Sinn Name und Vorname zu trennen. Ausser dann die Kunden> sie vertauschen koennen.>> Ich wuerd auch Strasse und Nummer nicht trennen. Recht haeufig duerften> Hausnummern wie 3a zu sein. Bei uns haben Haeuser etwas ausserhalb> einzelne Namen, also Strasse und Hausname>> Es macht wenig Sinn PLZ und Ort zu trennen.> Eine Frage wie kleinraeumig das Ganze gedacht ist. Ich wuerd fuer PLZ> und Ort zusammen 32 Zeichen vorsehen. Dann stehen die beiden schon in> der richtigen Reihenfolge.>> Aber mach mal. Etwas flexiblel sein. Es gibt noch viel zu lernen.
Sorry,
aber das würde ich auf gar keinen Fall empfehlen!
Bin gespannt wie du mit Multi-Information-Attributen Plausi-Checks
durchführen möchtest. Neben vielen anderen Aspekten der guten
Entwicklungsparaxis...
Klaus P. schrieb:>> Die ursprüngliche Bestellung sollte zu Prüfzwecken (z.B. für> Steuerprüfungen) auf jeden Fall nachvollziehbar sein. D.h. Du musst die> Kundendaten in die Bestellung kopieren. Das kann man in Tabellenform> machen, man kann aber auch XML oder JSON Felder dafür benutzen.
Oder man verwendet ein Audit-Trail auf Tabellenebene
Jörg M. schrieb:> Oder man verwendet ein Audit-Trail auf Tabellenebene
Das kann man machen, will man in der Regel aber nicht. Wenn
derjenige, der die Bestellung anlegt, sie dreimal ändert, weil er sich
vertippt hat, werden auch ebensoviele Einträge in den Audittabellen
angelegt. Oder die Audit-Trigger werden kompliziert (und ggf. sehr
langsam).
Audits auf Tabellenebene sollten aber einfach gehalten werden und am
besten auch keine Aufgaben der Anwendungslogik übernehmen. Das könnte
über kurz oder lang niemand mehr warten.
Ich finde, man soll explizit die Eingabe von der Verarbeitung trennen.
Sowohl bei der Angabe neuer Artikel, als auch bei einem Kunden, kann es
zu Fehlern kommen.
Somit sollten solche Eingaben alle, mit dem guten, alten OK-Button,
abgeschlossen werden.
Sehr viele Gedanken sollte man sich auch zum Thema "ändern" machen.
Man erzeugt zwar viele Tabellen, aber es ist keine gute Idee zu viele
Angaben in einem Eintrag zu verpacken.
Wird z.B. die Stadt mit der Straße verbunden, so ist der Eintrag für
nichts anderes mehr zu gebrauchen.
Der beste Eintrag ist AutoInc oder wie auch immer das Teil benannt wird.
Dieser Eintrag sollte zu JEDEM Datensatz für eine eventuelle Referenz
verwendet werden. Auch DU solltest hierauf keinen Zugriff haben. Sollte
sich am Ende keiner für eine bestimmte Referenz interessieren - was
soll's. Sind Deine Löschfunktionen zu Fehlerhaft, musst Du halt eine
Reinigungsfunktion schreiben.
Ein paar Tipps:
Außerhalb von Ober-Unter-Hinter kann eine Ortschaft mehr als eine
Postleitzahl haben. Also ist die Fixierung der Postleitzahl mit einem
Ort zulässig, einen Ort mit einer Postleitzahl zu fixieren ist
fehlerträchtig.
Schränke die erlaubten Eingaben nicht zu sehr ein. Insbesondere in
Reihenhaussiedlungen sind Hausnummer wie 22f keine Seltenheit. Meine
Hausnummer lautet 35/1/4. Es gibt sogar noch einige Ortschaften, die
keine Straßennamen verwenden sondern nur Hausnummern.
Sehr große Firmen bzw. Institutionen haben nur eine Postleitzahl und gar
keine Adresse.
Wir haben mal einen Brief, als unzustellbar, zurückbekommen, bei dem der
dritte Dr., des Ansprechpartners, fehlte. Ganz wichtig bei Lieferungen
nach Österreich. Letztere verwenden im Übrigen 4-stellige
Postleitzahlen...
Ein Feld für eine (2-3) Länderkennung kann auch nicht schaden.
Spätestens bei Lieferungen ins deutschsprachige Ausland, kann es bei
Städtenamen zu Doppeldeutigkeiten kommen und nicht nur ins Ausland.
Neustadt in Deutschland ist kein Städtename, sondern ein Sammelbegriff.
Meist durch Zusätze entschärft.
Also:
Neustadt
Neustadt a.R.
Neustadt a. R.
Neustadt a R
Neustadt a. Rübenberge
Neustadt am Rübenberge
u.s.w. können, müssen aber nicht, für ein und dieselbe Stadt stehen.
Karl Niemand Straße
Karl Niemand-Straße
Karl Niemand Strasse
Karl Niemandstrasse
usw. sind ebenfalls möglich.
Hinzu kommen noch die vielen Schreib- und Lesefehler.
Vlad T. schrieb:> es ging ja darum, den Ort wegzulassen und aus der PLZ zu gewinnen.> Kombination aus Ort+PLZ sollte eindeutig sein.
Also lediglich aus PLZ + Straße eine eineindeutige Adresse zu erstellen
funktioniert nicht und ist auch so nicht vorgesehen. Programmierer, die
das nicht beachten, kannste wegen grundsätzlicher Inkompetenz in Regreß
nehmen (RTFM nicht beachtet).
Beispiel: Ich wohne in einem Ort A mit PLZ 1 die auch für Ort B und
sogar Ort C gilt. In allen drei Orten gibts die "Hauptstraße". Die
Postboten wissen, daß sie auf den Ort achten müssen, aber hier stand
schonmal ein Vollzugsbeamter und wollte mich als Zeuge zum Gericht
schleifen, weil derjenige, um den es ging die Vorladung nicht erhielt
(Einwurfeinschreiben des Gerichts, jedoch einer dieser neumodischen
Regionalbriefdienste) und nun zwangsvorgeführt werden sollte.
Ich konnte anhand Ausweis wenigstens den Beamten von seinem
Fehler("Falscher Ort", damit falsche Person) überzeugen. Wie es ausging,
weiß ich leider nicht.
oT: Vergiß nicht, in der Bestellung ggf Zahlart + Versandart, Bemerkung
und wenigstens ein Flag "offene bestellung"/ "Bestellung abgeschlossen"
zu hinterlegen.
Kundenadressen möglichst Neutral anlegen: was wenn statt
[Vorname=]"Erwin" + [Nachname=]"Mustermann" auf einmal
[vorname=]"Autohandel GmbH" + [Nachname=]"Egon Boss" bestellt?
Ergo: "Name1"-"Name3" ist ideal (vergiß nicht, daß du bei Lieferadresse=
"Packstation" drei Zeilen brauchst).
Klar ist Ort Varchar(100?) + PLZ = Varchar10 + IsoLand= varchar3 (jaja
Üblich ist alpha-2 mit nur 2 Buchstaben, aber schonmal erlebt, wenn ein
Spanier "ES" in ein Iso 3166-alpha-3-Feld eintippt? :D Prüf es trotzdem
nach oder mach besser ein SELECT-Tag ins HTML-Formular.
wenn es wirklich Auslandskunden gibt, mach dich auf das britische
Postsystem gefasst. Oder noch schlimmer: Hongkong = keine PLZen.
Auch noch wichtig: in der Liste der bestellten Artikel sollte neben
Anzahl auch mindestens der aktuelle Einzelpreis rein.
Es macht übrigens (außer vllt. auf Raspberry Pi) bei Mysql nichts aus,
wenn du die varchar-Größenwerte großzügig angibst. Das bisschen
Performance und Speicherunterschied geht völlig im Rauschen unter:jede
neue Indextabelle würfelt Performance und Speicherplatz weit mehr
durcheinander. Zumindest gilt das für obigen Zweck, in anderen Fällen
mags vllt. anders aussehen.
Was du tunlichst sein lassen solltest: Umlaute in Mysql-Spalten- oder
gar Tabellennamen. Obwohl das einleuchtend ist, gibts da draußen noch
immer Webbuden, die das nicht kapieren.
Ihr betrachtet das hier nur aus der Perspektive des Programmierers. Als
Kunde will ich aber nicht 100 Felder ausfuellen muessen, selbst wenn
sich die Anzahl an Eingabezeichen nicht aendert. Ich will auch nicht aus
womoeglichen Teilorten auswaehlen muessen. Und wenn die Hausnummer in
ein extra Feld eingegeben werden muss, komm ich mir schon verarscht vor.
Spaetestens dann ueberleg ich mir, ob ich den Artikel wirklich so
dringend brauch.
Deshalb:
-Vorname
-Name
-Adresszusatz
-Strasse/Hausnr.
-PLZ/Ort
Also nicht alles technisch optimieren, sondern auch auf die
Nutzerfreundlichkeit achten!
Negativbeispiel: Auf einer deutschsprachigen Seite muss das Land aus
einer Liste mit 400 Eintraegen ausgewaehlt werden, Deutschland ist zu
finden unter F wie Federal Republic of Germany :-)
Peter II schrieb:> was will man mit einem 1000 Zeichen Ort anfangen, ihn kann man eh nicht> auf das Paket drucken. Ich halte ein sinnvolle Obergrenze der varchar's> auch für sinnvoll.
Ja, aber nicht in MySQL, wenn sie das nicht geändert haben. Früher war
es jedenfalls so, daß man "Peter II" problemlos in ein VARCHAR(3)
schreiben konnte, das dann ohne Fehlermeldung abgeschnitten wurde und
man beim Lesen nurmehr "Pet" heraus bekam. Einer der vielen Gründe,
warum ich MySQL bei keinem ernsthaften Projekt mehr benutzen würde und
stattdessen zu Postgres gewechselt bin.
Matze schrieb:> Ich habe vor in nächster Zeit einen WebShop auf HTML,CSS,XML,PHP und> MySQL basis zu erstellen.
Wozu XML?
> Dabei soll es möglich sein Kunden anzulegen, welche Bestellungen> aufgaben können. Diese Bestellungen bestehen aus einer vielzahl von> Artikeln.> Da ein Artikel jedoch auch in vielen Bestellungen vorkommt, habe ich> dies durch die Tabelle "Einzelartikel" zu einer 1 zu n Beziehung> umgeformt.>> Die DB ist wohl in 3. Normalform.> Was haltet ihr davon?> Ist sie korrekt?
Nein. Deine bestehenden Bestellungen gehen kaputt, sobald sich der Preis
für einen Artikel nachträglich ändert -- viel Spaß mit Deinem Finanzamt.
Leute, die im Ausland wohnen und deren PLZ daher nicht in ein INT
passen, können bei Dir ebensowenig bestellen wie jene, die hier in
Aachen in der Straße "Henger Herrjotts Fott" mit der Hausnummer "37a"
wohnen.
Bei einem Shop gibt es mehrere Entitäten, von denen keine in nur einer
Tabelle abgebildet werden kann: Kunde, Sortiment, Lager und Bestellung.
Schon einen Kunden würde ich mit mehreren Tabellen anlegen: Stammdaten,
Wohn-, Rechnungs- und Lieferadressen, Kontaktdaten wie E-Mail-Adressen,
Telefon- und Telefaxnummern, Bankverbindung, jeweils gerne auch mehrere.
Da komme ich allein um einen Kunden sauber abzubilden auf mindestens
vier Tabellen, hinzu kommen eventuell Rabattierungen, Gutscheine etc.
Dann ist da das Sortiment; nur die einfachsten Artikel können in nur
einer Tabelle abgebildet werden. Schon Schuhe haben unterschiedliche
Größen und können unterschiedliche Farben für Sohle, Deckmaterial, und
Schnürsenkel haben, und dann, je nachdem, auch noch unterschiedliche
Preise.
Außerdem willst Du sicher keine Produkte anbieten, die Du nicht liefern
kannst; Du mußt also nachhalten, wieviele Produkte eines bestimmten Typs
Du noch auf Lager oder bereits verkauft hast. Idealerweise wird Dein
Shop Dich Dein Shop daran erinnern, daß Du nachbestellst, sobald eine
bestimmte Mindestmenge unterschritten wird, oder daß Du Sonderangebote
machst, wenn Du mehr als eine bestimmte Höchstmenge an Produkten im
Lager hast.
Und dann kommen die Bestellungen. Die dürfen sich natürlich nicht
ändern, nur weil ein Produktpreis oder eine Kundenanschrift geändert
worden ist, und gehören deswegen in mindestens zwei eigene Tabellen, die
NICHT mehr direkt an den Produkt- und Kundentabellen hängen dürfen.
Ein paar Erfahrungen.
Die Laenderauswahlliste kommt schlecht an. Falls man so eine denn
wollte, sollte man die nahen Laender zuoberst haben. Sollte aber auch so
ersichtlich sein. Ich muss jeweils immer runterscrollen bis Uzbekistan,
United States, Swaziland oder so. Wobei mein Land in einer englischen
Liste und einer Deutschen etwa am selben Ort zu finden sind. Also ich
find die Listen Schrott.
Andererseits. Wenn man das Land ausfuellbar macht erhaelt man :
Germany resp GERMANY
Deutschland resp DEUTSCHLAND
Schweiz resp SCHWEIZ
Suisse resp SUISSE
Switzerland resp SWITZERLAND
England
Britain
Scottland
Great Britain
GB
The Netherlands
Netherlands
Niederland
US
United States
USA
United States of America
Also gross/klein, mehrsprachige Auslegungen, Abkuerzungen, alles Fehler
nicht eingerechnet.
Wenn man das alles in die Datenbank eintraegt, ist die Adresse
moeglicherweise postalisch gueltig, man findet aber nichts.
Die Namen sind aehnhlich schlimm. Mit dem Nachteil, dass es da keine
Auswahllisten gibt. Moegliche Eintraege derselben Person, resp Familie
Karl Hinterwald
Hr K Hinterwald
KARL HINTERWALD
Hinterwald Karl
Dr Karl Hinterwald
K & G Hinterwald-Vordemwald = Maennername-Frauenname
Karl & Gertrud Hinterwald
und Permutationen. Zwei getrennte Felder fuer Name & Vorname haelt die
Leute nicht davon ab, verkehrt einzufuellen.
Adresszusaetze :
Supercampus of Hainan University, Hainan, China, Division Supertech,
Superlab 2134, Floor 123, ..
Hainan University, Hainan, China
Hainan, China
Da war dann nichts mit 80 Zeichen fuer irgendwas. Wenn man nichts senden
muss, am besten ein Textfeld fuer alles, 4000 Character, und egal, auf
der Rechnung steht was eingefuellt wurde.
Eine Begrenzung muss aber sein, denn hin und wieder bekommt man
roboterisierte Adressen, die sich dann hinziehen koennen.
Man kann sich da vertun, und sollte immer bereit sein etwas
dazuzulernen. Ein Standard Library Baustein genuegt nicht.
ShopDB_V2.jpg
(47 KB)
