Kauf- und Kontenverwaltung - Datenbank notwendig?

[Asura]

Gut, ich habe mir überlegt, dass ich über eine Ini-Datei, den Zugriff solange verweigere auf die Software, wenn ich diese Datenbank über meinen Computer bearbeite.

Nun frage ich mich, wie ich nun ein Datensatz abfrage, so kann ich ja theoretisch über SQL eine Spalte abfragen, doch wie kann ich die Abfrage in ein Stringlist fassen?

Code:

 with ADOQuery do
  begin
    Close;
    SQL.Clear;
    SQL.Add('SELECT username FROM users') ;
    Open;
  end;

[Delphi.Narium]

Weiß zwar nicht, was Du vorhast, eventuell sowas?

Delphi-Quellcode:

var
  sl : TStringList;
begin
  sl := TStringList.Create;
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username FROM users') ;
  ADOQuery.Open;
  while not ADOQuery.EoF Do begin
    sl.Add(ADOQuery.Fields[0].AsString);
    ADOQuery.Next;
  end;
  ADOQuery.Close;
  // Irgendwas mit der Stringliste machen.
  ...
  sl.Free;
end;

Statt 'ner Stringliste könnte man dort auch von 'ner TComboBox die Eigenschaft Items nehmen. Dann sieht die entsprechende Zeile so aus:ComboBox1.Items.Add(ADOQuery.Fields[0].AsString); An Stelle von  sl := TStringList.Create; wäre dann eher ein ComboBox1.Items.Clear; angebracht.

[Asura]

Ich würde gerne die existierenden Benutzer in Button.Caption speichern. Hatte das vorher ebenfalls mit Ini-Dateien gelöst, hat auch wunderbar geklappt (Buttons, weil ein Tablet und größere Buttons mit Benutzer-Auswahl angenehmer ist als eine Combobox beispielsweise).

Leider stößt er mit deinem Beispiel folgende Fehlermeldung aus:
"1 Parameter wurde erwartet, aber es wurden zu wenige Parameter übergeben".

Habe die Stringlist nur über ein Showmessage ausgeben wollen, um zu sehen, ob es funktioniert.
Ich habe auch überprüft die Verbindung von ADOQuery zu DataSource steht, sowie auch die Verbindung von DataSource zu ADOTable, also in den Objektinspektor ist alles richtig eingestellt. Komischerweise hat es ja auch mit dem Grid wunderbar funktioniert!

[Asura]

Des Weiteren habe ich mir mal bisschen mehr Gedanken zu der Datenbankmodellierung gemacht und bisschen auch mich weiter informiert über Datenbanken.

Nun möchte ich Fragen, ob hier ein Denkfehler drin ist:

Es existieren 3 Tabellen: Getränke, Bestellungen, Users

Getränke <-- n --- m --> Bestellungen <-- n --- 1 --> Users

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

Ist das so korrekt?

Nun noch eine Frage: Wie löse ich das, dass Bestellungen mehrere Getränke notiert und hierbei die einzelnen Getränke mit Anzahl und Preis berücksichtigt.
Lass mich raten: Mehr Tabellen und Verknüpfungen?

Ich möchte noch mal eventuell kurz Erklären was mein Vorhaben ist, damit man sich besser hineinversetzen kann:
Stellen Sie sich vor, Sie können hier einfach über ein Tablet Ihr Konto auswählen. Daraufhin öffnet sich eine Übersicht, wo verschiedene Getränke zur Auswahl stehen mit Preis (Also Konto, Getränke und Preis können variabel über die Datenbank geändert werden und werden auch so vom Programm immer mit verändert). Daraufhin kann man Beispielsweise: Zwei Bier und Zwei Cola auswählen und es wird in einen virtuellen Warenkorb gelegt. Danach drückt man nur noch Kauf abschließen und das System rechnet automatisch nach der Buchung ein Minusbetrag (Hier in der Tabelle User unter Guthaben) den Preis runter und registriert für eine spätere Einsicht immer noch (unter Tabelle Bestellungen) die komplette Bestellung.
So kann ich durch ein Programm schlichtweg Lagerbestände kontrollieren, der User hat hier immer eine Übersichtsmöglichkeit und die Sicherheit, dass keine Verrechnungen stattfinden.

Hoffe nun kommt mein Vorhaben besser rüber.

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

Delphi-Quellcode:

var
  i   : Integer;
  btn : TButton;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;
  ADOQuery.Open;
  i := 0;
  while not ADOQuery.EoF Do begin
    i := i + 1;
    // So kurz ist das mutig. Man sollte im "richtigen" Programm dann prüfen,
    // ob die Komponente auch gefunden wurde und ob der Typ passt.
    btn := TButton(Self.FindComponent('Button' + IntToStr(i)));
    if Assigned(btn) then begin
      btn.Caption := ADOQuery.Fields[0].AsString;
      // Nur als Idee: Der Button "weiß" dann direkt die UserID für die weitere Arbeit.
      // Beim Button-Click muss man dann nicht erst aus dem Namen in der Caption    
      // die UserID suchen, um sie für die Tabelle Bestellungen verwenden zu können.
      btn.Tag := ADOQuery.Fields[1].AsInteger;
    end else begin
      // Das sollte nicht vorkommen, aber eine entsprechende Fehlerbehandlung
      // wäre trotzdem nicht schädlich.
    end;
    ADOQuery.Next;
  end;
  ADOQuery.Close;
end;

Zum Datenmodell:

Der Getränketabelle würd' ich zusätzlich eine Getraenke_ID gönnen und die als Primärschlüssel nehmen.

Die Tabelle Bestellungen erhält dann statt des Getränkenamens die Getränkeid.

Mit dem Modell kann man eigentlich schon pro Bestellung mehrere Getränke verwalten. Es werden dann pro Bestellung mehrere Datensätze angelegt. Man könnte, damit es übersichtlicher wird, der Getränketabelle noch eine Spalte Position spendieren. Jedes Getränk zu einer Bestellung bekommt eine eigene Position, so dass man aus Bestellt_Nr und Position einen eindeutigen Schlüssel machen könnte. Auch kann man hierüber die Ausgabe immer sortiert ausgegeben werden und hat immer die gleiche Sortierung, selbst dann wenn man mal die Getränkenamen ändern sollte.

Umlaute in Tabellen- und Spaltennamen finde ich kritisch. Man weiß nie genau, ob man das auch (wenn nötig) auf eine andere Datenbank übertragen kann. Persönlich nehme ich nur (auch wenn Datenbanken was anderes können) nur die Buchstaben A bis Z, die Ziffern 0 bis 9 und den Unterstrich _. (Mag altmodisch sein, aber bisher hat noch jeder Datenbankwechsel ohne Programmänderungen oder Änderungen am Datenmodell funktioniert. Tabellen und Spaltennamen sind bei mir maximal 30 Zeichen lang. In der Regel reicht das auch aus.

[mkinzler]

Statt

Delphi-Quellcode:

  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;

kann man auch kurz

Delphi-Quellcode:

ADOQuery.SQL.Text := 'SELECT username, UserID FROM users;';

schreiben.

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

[jobo]

Zum Datenmodell noch einige Anmerkungen:
Feldnamen in einheitlicher Sprache, Englisch ist quasi Standard
Bei Feldnamen einer einheitlichen Nameskonvention für Schlüsselfelder, Flags, Logikattributen folgen
Primärschlüssel wie schon genannt als Zahlwert, Namen (änderbar) als separates Feld, ebenfalls unique
Tabellen und Feldbezeichnungen möglichst passend, aber allgemein wählen. Spätestens wenn die Leute auch Snickers und Twix bestellen, ist Getränkename unglücklich gewählt, also z.B. Tabelle "Produkt", Feld "Name"
Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.
Datenmodel-Constraints (unique, not null, ref constraints, ..) möglichst eng fassen und bei Bedarf lockern oder Ausnahmen definieren.
Cascading Constraints mit Vorsicht (oder gar nicht einsetzen), bwahrt Entwickler/Anwender vor Datenverlust.

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.

[mkinzler]

Ware statt Getränke, Vorgang statt Bestellungen ( dann kann man auch "Guthabenzugänge" modellieren und das aktuelle Guthaben berechnen)

Zitat:

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

Oder pro Tabelle. Bei Access geht dies ja sowiso auch nicht anders.

[Bernhard Geyer]

Zitat von HolgerX:

Alles für die Erstellung/Benutzung einer Access-Datenbank ist auf einem blanken Windows-Rechner schon vorhanden.
...
Oder habe ich da was verpasst?

Jo, hast du.
MS ist zwar auf "normalen" Windows-Systemen vorhanden, aber nicht immer.
Im Berech Embededd ist die Jet-Engine ein Optionaler Teil den man (um Platz zu sparen) auch abwählen kann.
MS hat (früher) die Jet-Engine auch im Rahmen der MDAC-Installation verteilt. Die letzten Versionen waren aber ohne dieser bereit gestellt.

Ich vermute das MS die Jet-Engine deshalb nicht ausbaut um nicht noch eine (unnötige) Problemstelle zu produzieren (wie sie ja an anderen Stellen mit "komischen" Entscheidungen sich ohne Not erschaffen haben.
Darauf würde ich mich nicht verlassen. In Zeiten von "Mobile First" kann sowas auch mal ohne Vorankündigung in einem Spring/Autum-Update kommen.