Einzelnen Beitrag anzeigen

Delphi.Narium

Registriert seit: 27. Nov 2017
2.428 Beiträge
 
Delphi 7 Professional
 
#55

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 12. Dez 2017, 23:34
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.
  Mit Zitat antworten Zitat