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
Angehängte Dateien:
-
ShopDB_V2.jpg
47 KB
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.
:
Bearbeitet durch User
Und wo wir grad dabei sind: Trennung von Rechnungs- und Lieferanschrift nicht vergessen.
Hausnummern sollten keine Zahlen sein (oder ein extra Feld für einen Zusatz haben).
Stimmt, die Feldlängen sind wenigstens eine Größenordnung zu klein. Hausnummer kann Buchstaben enthalten (1367a).
Jim M. schrieb: > Stimmt, die Feldlängen sind wenigstens eine Größenordnung zu klein. Die Feldlängen müssen dynamisch sein.
Nuckel schrieb: > Die Feldlängen müssen dynamisch sein. Das sind sie hier ja auch. Nur eben mit viel zu kurzem Limit.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Du solltest dein Sortiment von den Bestellungen trennen. Ansonsten kannst du Artikel nicht mehr verändern, nachdem sie zum ersten Mal bestellt wurden.
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
:
Bearbeitet durch User
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.
Amateur schrieb: > Meine > Hausnummer lautet 35/1/4. Musstest du zur Schule dann immer den Zug am Gleis 9 3/4 nehmen? :)
Ich glaube, Du musst noch etwas "Grundlagenforschung" betreiben. https://wi.uni-potsdam.de/homepage/lehrewi.nsf/0/1b3c20942a48d822c1257ee7003c44f7/$FILE/Teil%205%20-%20Vom%20Datenmodell%20zur%20Tabelle.pdf und z.B. https://books.google.de/books?id=kq8sm6kmUt4C&pg=PA143&lpg=PA143&dq=datenmodell+kunde+bestellung+artikel&source=bl&ots=zjphN4ahaU&sig=ananLA1lbRs8VGiK_3M6fMwC1IQ&hl=de&sa=X&ved=0ahUKEwiF1JTv0IrQAhWBnRQKHT9vAqE4ChDoAQggMAE#v=onepage&q=datenmodell%20kunde%20bestellung%20artikel&f=false
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.
:
Bearbeitet durch User
Hallo, nette Seite über Adressen: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ Gruss, Jay
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.