Kauf- und Kontenverwaltung - Datenbank notwendig?

[mkinzler]

Zitat:

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ich würde es eher so machen

Getraenke:

ID (Primärschlüssel)
Name

Preise:

ID (Primärschlüssel)
getraenk (Fremdschlüssel)
von (Datum)
[bis (datum)]
Preis

Bestellungen:

ID (Primärschlüssel)
Nr
Datum
UserID (Fremdschlüssel)
Getraenk (Fremdschlüssel)

Users:
ID (Primärschlüssel)
Name
[Guthaben]

So kann man Preisänderungen besser protokollieren.

[Asura]

Zitat von Delphi.Narium:

Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?
Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)

An sich funktioniert das System, jedoch wenn er auf den Namen des Benutzers zugreifen will, gibt er mir eine Fehlermeldung aus. mit der ID funktioniert es aber.
Ich habe mal ein DBGrid in die Form gelegt und dort die Tabelle reingeladen. Er lädt in das Feld User überall das Wort "WIDEMEMO", ich gehe mal davon aus, das ist der Grund, warum er die Fehlermeldung rauswirft, die ich weiter oben angegeben habe?

Zitat von mkinzler:

Ich würde es eher so machen

Was bedeuten die Attribute mit den eckigen Klammern?
Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich verstehe auch noch nicht so ganz, wie eine Bestellung mehrere Getränke enthalten kann und wie berechnet er den Gesamtwert einer Bestellung?

Bis jetzt lese ich die Datenbank wie folgt:
Es existieren zwei Getränke (Beispielsweise) in der Tabelle Getraenke.
und es sind jeweils zwei Einträge in Preise für Getraenke hinterlegt.
Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Mir ist ebenfalls noch eine Frage eingefallen:
Wenn das Programm fertig ist und auf das Tablet übertragen wird und dort auch die Datenbank hinterlegt wird, muss das Tablet auch über Access verfügen, in hinblick auf Treiber bzw. der Möglichkeit, dass das Programm nichts mit der Datenbank dann anfangen kann?

[mkinzler]

Zitat:

Was bedeuten die Attribute mit den eckigen Klammern?

Felder sind nicht unbedingt notwendig.

Für das snowflaking des Datums reicht das Beginndatum (Enddatum = Beginndatum nächste Presiperiode)
Da Guthaben ist auch berechenbar (Problem Redundanz)

Zitat:

Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich bevorzuge synthetische Schlüssel, BestellNr ist Teil der Nutzdaten.

Zitat:

Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Es gilt der jeweilig gültige Preis zum Bestelldatum (aus Tabelle Preise). Bei einer Preisänderung wird ein neuer Eintrag in der Tabelle Preise mit dem Datum der Preisänderung und dem neuen Preis erzeugt.

Zitat:

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Dann würde ich eine weitere Detailtabelle für die Bestellpositionen verwenden. Gesamtpreis einer Bestellungen dann die Summe der Positionen (berechnet) also jeweils Anzahl * (aktueller) Preis.

was für ein Tablet?

[Asura]

Gut, denke das habe ich nun alles verstanden, dankeschön!

[QUOTE=mkinzler;1388680]

Zitat:

was für ein Tablet?

Zur Bestellabwicklung soll mein Programm auf ein Tablet übertragen werde. Bis jetzt existiert das Tablet noch nicht, ich werde es dann zu gegebenen Zeitpunkt kaufen. Wird natürlich ein Tablet mit Windows werden.
Meine Frage bezog sich darauf, ob das Programm später bei dem Release eine Access Version benötigt, bezüglich Treiber, um auf die Datenbank auf dem Tablet zuzugreifen.

[p80286]

Zitat von Asura:

Meine Frage bezog sich darauf, ob das Programm später bei dem Release eine Access Version benötigt, bezüglich Treiber, um auf die Datenbank auf dem Tablet zuzugreifen.

Weiter oben habe ich erfahren, daß Access ja immer bei Windows dabei ist (es sei denn es wird nicht mit installiert), dann wird es wohl verfügbar sein.

Gruß
K-H

[Delphi.Narium]

Bezgl.: WIDEMEMO

Für Namen nimmt man kein Memofeld sondern 'nen String bzw. VarChar. Wie lang kann den ein "gewöhnlicher" Username werden? VarChar(250) wäre da wohl schon eher überdimensioniert. In eine Memo- bzw. Blobfeld passt notfalls auch ein ganzer Roman rein, das scheint mir doch eher reichlich übertrieben.

Könntest Du eventuell mal die Createstatements Deiner Tabellen hier posten? Dann kann man da nochmal drüberschauen, inwieweit Bedeutung und Typ der Spalten zusammenpassen. Das ist was, da kann man am Anfang schonmal sehr leicht was falsch wählen und bereut nachher, dass eine Umstellung ohne Datenverlust nicht mehr so leicht möglich ist.

Die Tabellenerstellung würd' ich insgesamt auf Dauer lieber mit dem Programm (oder einem extra Pflegeprogramm?) selbst machen. Geht auch über 'ne ADOQuery und deren Methode ExecSQL. Vorteil: Die MS-Access-typischen "Unsitten" bei der Tabellendefinition kann man dadurch umgehen (kann sich also an den SQL-Standard halten, was einen ggfls. mal notwendig werdenden Datenbankwechsel vereinfacht), außerdem bekommt man (so meine ich) ein besseres Gefühl für die Tabellendefintionen und deren Abhängigkeiten untereinander. Aber das ist sicherlich auch Geschmacksache.

[Asura]

Zitat von Delphi.Narium:

Bezgl.: WIDEMEMO

Für Namen nimmt man kein Memofeld sondern 'nen String bzw. VarChar. Wie lang kann den ein "gewöhnlicher" Username werden? VarChar(250) wäre da wohl schon eher überdimensioniert. In eine Memo- bzw. Blobfeld passt notfalls auch ein ganzer Roman rein, das scheint mir doch eher reichlich übertrieben.

Könntest Du eventuell mal die Createstatements Deiner Tabellen hier posten? Dann kann man da nochmal drüberschauen, inwieweit Bedeutung und Typ der Spalten zusammenpassen. Das ist was, da kann man am Anfang schonmal sehr leicht was falsch wählen und bereut nachher, dass eine Umstellung ohne Datenverlust nicht mehr so leicht möglich ist.

Die Tabellenerstellung würd' ich insgesamt auf Dauer lieber mit dem Programm (oder einem extra Pflegeprogramm?) selbst machen. Geht auch über 'ne ADOQuery und deren Methode ExecSQL. Vorteil: Die MS-Access-typischen "Unsitten" bei der Tabellendefinition kann man dadurch umgehen (kann sich also an den SQL-Standard halten, was einen ggfls. mal notwendig werdenden Datenbankwechsel vereinfacht), außerdem bekommt man (so meine ich) ein besseres Gefühl für die Tabellendefintionen und deren Abhängigkeiten untereinander. Aber das ist sicherlich auch Geschmacksache.

Ich konnte das Problem lösen, indem ich die Einstellung auf einen Short String geändert habe habe.

Bezüglich des Pflegeprogramms, wollte ich eh entwerfen, da ich gerne doch eine Option hätte SQL Befehle auszuführen. Doch habe ich gerade Probleme mit der Verbindung, dass er das Ergebnis auf die das Grid überträgt. Muss man nicht die Tabelle dafür schließen und dann das Datasource an das Query anhängen?
Wie würde das dann auch mit der Formatierung aussehen wegen SQL? Benutze ein Memofeld, dort trage ich den SQL Befehl ein und über ADOQuery.Text setze ich den Text rein.