Kauf- und Kontenverwaltung - Datenbank notwendig?

[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?

[Asura]

Zitat von jobo:

Zum Datenmodell noch einige Anmerkungen:

Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.


16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der GUI/der Logik) leicht in die Hose.

Was ist mit einer zentralen Sequenz gemeint, also diese Aussage verstehe ich nicht.

Bezüglich der 16:
Mir fällt aber keine andere Möglichkeit ein, die eine schnelle Auswahl ermöglicht. Weil ich habe es mir zurzeit so gedacht: Tablet an, Benutzer auswählen (1. Klick), Getränke auswählen (Mind. 1 weiterer Klick) und Kauf bestätigen (3. Klick).
Also, dass der Käufer hier ganz einfach ein Kauf abwickeln kann.

Zur Zeit läuft es über die gute alte Methode: Zettel, Strich unter Getränk und Namen machen und ich darf das dann alles zusammenrechnen, buchen etc. Also: Umständlich für mich, deswegen eine Software.
Jedoch soll sie für den Anwender in Gegensatz zu der Strichliste ebenfalls kein großen Mehraufwand haben, sonst würde die Frage der Käufer aufkommen: Wieso ein neues System, was für mich einen Mehraufwand und Zeit kostet, wenn die Strichliste genauso gut funktioniert. Also eventuell können sie das das nachvollziehen, dass ich hier auch bisschen auf Attraktivität in Hinblick auf Schnelligkeit und "Leichtigkeit" aus bin.

[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.

[jobo]

Zitat von Asura:

Was ist mit einer zentralen Sequenz gemeint, also diese Aussage verstehe ich nicht.

Bezüglich der 16:
Mir fällt aber keine andere Möglichkeit ein, die eine schnelle Auswahl ermöglicht.

Ein Sequenz ist ein Zahlengenerator, der von sich aus schon eindeutige (idr. einfach aufsteigende) Zahlen ausspukt bei Anfrage. Den (einen) bindet man an die verschiedenen Primärschlüssel, das ist einfach bewährte Praxis. Bei Access geht das vielleicht nicht, hier nimmt man idR ein Autoinc Feld, macht das gleiche, aber je Schlüsselfeld. Ist auch kein Drama.

16: Du kannst einfach eine Dropdownliste/Combobox mit den Usern machen. Der User muss natürlich 2x mehr klicken, aber Du sparst Dir 16 Button und den weiteren Umbau für weitere User.
(mit einem normalerweise üblichen Anmeldevorgang wäre das Thema auch erledigt, Mehraufwand für den Anfang, aber viel sauberer, spätestens wenn die ersten Deine Rechnung anzweifeln)

[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.

[Delphi.Narium]

Zum Anzeigen der Ergebisse eines SQLs braucht man eigentlich nur:

Ein Memo für die Texteingabe.
Eine ADOQuery, 'ne DataSource und ein DBGrid. DBNavigator ist ein kann. Eventuell 'ne Statusbar mit SimplePanel := True;

Einen Button, der ungefähr so einen Quelltext im OnClick enthält (ungetestet):

Delphi-Quellcode:

var
  s : String;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  // Wenn selektierter Text vorhanden ist, wird nur der als SQL übernommen.
  // Dadurch kann man dann im Memo mehrere SQLs haben und muss nicht immer alle neu schreiben ;-)
  // Speichert man mit Memo.Lines.SaveToFile beim Programmende
  // und lädt beim Programmstart mit Memo.Lines.LoadFromFile, hat man auch länger was davon.
  if Memo.SelAvail then begin
    ADOQuery.SQL.Add(Trim(Memo.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(Memo.Text));
  end;
  if ADOQuery.SQL.Count = 0 then exit;
  Try
    s := AnsiLowerCase(Copy(ADOQuery.SQL[0],1,6);
    if s = 'select' then begin
      ADOQuery.Open;  // Für Abfragen
      StatusBar.SimpleText := Format('Es wurden %d Datensätze gefunden.',[ADOQuery.RecordCount]);
    end else begin
      ADOQuery.ExecSQL; // Für alles andere wie Insert, Update, Delete, Create Table ...
      StatusBar.SimpleText := Format('Von der Abfrage waren %d Datensätze betroffen.',[ADOQuery.RowsAffected]);
    end;
  except
    on e : Exception do begin
      MessageDlg(e.Message,mtError,[mbOk],0);
    end;
  end;
end;

Man kann zur Laufzeit bei 'ner DataSource den DataSet ändern, allerdings gehe ich her, dass ich jeder Query, Table (wenn ich die denn mal brauche) 'ne eigene DataSource spendiere und jeweils ein eigenes DBGrid ...

Normalerweise haben aber die "Pflegeteile" von Programmen nur eine Datenbankverbindung, eine Query, eine DataSource, ein DBGrid und einen DBNavigator. Das reicht, da man alles per SQL machen kann, was zur Datenanzeige und / oder Datenmanipulation erforderlich ist.

Mehrere Querys und/oder Tables gibt es nur, wenn unumgänglich mehrer Datenmengen zeitgleich zur Verfügung stehen müssen, bei einem Pflegeprogramm scheint mir dies nicht sinnvoll zu sein.

[Asura]

Vielen Dank für die Mühe!

Bezüglich Memo.SelAvail musste ich leider feststellen existiert nicht, habe die auch nicht hierunter http://docs.embarcadero.com/products...rls_TMemo.html gefunden.

Wie wäre es mit:

Delphi-Quellcode:

  if SQLEingabe.SelLength <> 0 then begin
    ADOQuery.SQL.Add(Trim(SQLEIngabe.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
  end;

Aber generell tut sich effektiv nichts im Memo. Ich gehe mal davon aus, dass es bestimmt an der Verlinkung der ADO Komponenten liegt.
Du hast geschrieben, dass man nur eine Verbindung, Query, Datasource und DBGrid benötigt? Also kein ADOTable?
Wie würde dann die Verbindung aussehen zwischen den Komponenten?
Weil benötigt DataSource nicht die Komponenten ADOTable ?