Kauf- und Kontenverwaltung - Datenbank notwendig?

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

[jobo]

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

[Delphi.Narium]

Zitat von jobo:

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

Oh Mist, hab' ich nicht dran gedacht, da ich fast nur noch SynEdit nutze.

@Asura
ADOTable ist für die statische Anzeige eines Tabelleninhaltes, ADOQuery für die Ausführung von SQL-Statements.

DataSource benotigt ein TDataSet, ADOQuery und ADOTable sind beide von TDataSet abgeleitet, funktionieren also beide.

Einfach mal von beiden eins aufs Formular pappen, 'ne DataSource dazu und im Objektinspektor zum DataSource bei DataSet schauen, was da so zur Auswahl steht. Alles was da angezeigt wird, kann man auch nutzen.

Bezüglich Deiner Alternative zum SelAvail: Ja, das geht auch so, mit SelText bekommst Du ja den markierten Text. Wie und ob das bei unterschiedlichen Komponenten unterschiedlich funktioniert ist ja eher nachrangig, Hauptsache: Ziel erreicht

Das Memo ist für die Eingabe von SQLs. Dort tut sich nichts, außer Du gibst dort was ein. Deine Eingabe wird dann an die ADOQuery weitergereicht und nach deren öffnen, mit Hilfe einer DataSource und den dieser zugeordneten Datenkomponente (z. B. einem DBGrid), angezeigt.

Mal einen nicht wirklich sinnvollen Quelltext, mit dem man das demonstrieren könnte:

Delphi-Quellcode:

ADOQuery.Close;
ADOTable.Close;
ADOTable.TableName := 'users';
DataSource.DataSet := ADOQuery;
ADOQuery.SQL.Text := 'select * from users where ID = 1';
ADOQuery.Open;
ShowMessage('Sieht man jetzt den User mit der ID 1?');
ADOQuery.Close;
ADOTable.Open;
ShowMessage('Sieht man jetzt alle User?');
ADOTable.Close;

Dieser Quelltext ist so in etwa für eine Demonstration geeignet, aber nicht für den wirklichen Betrieb.

Wenn ich etwas benötige, um beliebige Daten anzuzeigen, nutze ich nie eine ADOTable, sondern immer nur ADOQuery (bzw. bei anderen Datenbankkomponenten die entsprechenden Gegenstücke). Will ich alle Daten einer Tabelle sehen, dann ist die Abfrage eben Select * from ebendertabelledieichsehenwill.

Ein Hin und Her per Zuweisung von diversen DataSet-Nachkommen zu eine DataSource macht nur den Quelltext verwirrend und scheint mir nicht zielführend.

Mal eben wild zusammengedaddelt so eine Art "Demo"

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, DB, ADODB, ExtCtrls, DBCtrls, Grids, DBGrids, ComCtrls;

type
  Tfrm = class(TForm)
    DataSource: TDataSource;
    ADOQuery: TADOQuery;
    pnTop: TPanel;
    StatusBar: TStatusBar;
    DBGrid: TDBGrid;
    DBNavigator: TDBNavigator;
    Splitter: TSplitter;
    ADOConnection: TADOConnection;
    btnSQL: TButton;
    btnEnde: TButton;
    pnInfo: TPanel;
    SQLEingabe: TMemo;
    Splitter1: TSplitter;
    Tabellen: TMemo;
    procedure btnEndeClick(Sender: TObject);
    procedure btnSQLClick(Sender: TObject);
    procedure TabellenDblClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frm: Tfrm;

implementation

{$R *.dfm}

procedure Tfrm.btnEndeClick(Sender: TObject);
begin
  ADOQuery.Close;
  ADOConnection.Close;
  Close;
end;

procedure Tfrm.btnSQLClick(Sender: TObject);
var
  slTables : TStringList;
  slFields : TStringList;
  i        : Integer;
  k        : Integer;
begin
  if not ADOConnection.Connected then begin
    if ADOConnection.ConnectionString = '' then begin
      ADOConnection.ConnectionString := PromptDataSource(handle,'');
    end;
    if ADOConnection.ConnectionString <> '' then begin
      ADOConnection.Open;
      Tabellen.Lines.Clear;
      slTables := TStringList.Create;
      slFields := TStringList.Create;
      ADOConnection.GetTableNames(slTables,false);
      for i := 0 to slTables.Count - 1 do begin
        Tabellen.Lines.Add(slTables[i]);
        ADOConnection.GetFieldNames(slTables[i],slFields);
        for k := 0 to slFields.Count - 1 do begin
          Tabellen.Lines.Add(Format('  %s',[slFields[k]]));
        end;
      end;
      slTables.Free;
      slFields.Free;
    end;
  end;
  if ADOConnection.Connected then begin
    ADOQuery.Close;
    ADOQuery.SQL.Clear;
    if SQLEingabe.SelLength <> 0 then begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.SelText));
    end else begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
    end;
    if Trim(ADOQuery.SQL.Text) <> '' then begin
      ADOQuery.Open;
    end;
  end;
end;

procedure Tfrm.TabellenDblClick(Sender: TObject);
begin
  if Tabellen.SelText <> '' then begin
    SQLEingabe.SelText := Tabellen.SelText;
  end;
end;

procedure Tfrm.FormCreate(Sender: TObject);
begin
  if FileExists(ChangeFileExt(Application.ExeName,'.sql')) then begin
    SQLEingabe.Lines.LoadFromFile(ChangeFileExt(Application.ExeName,'.sql'));
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  SQLEingabe.Lines.SaveToFile(ChangeFileExt(Application.ExeName,'.sql'));
end;

end.

Und das Formular dazu:

Delphi-Quellcode:

object frm: Tfrm
  Left = 4
  Top = 4
  Width = 1000
  Height = 640
  Caption = 'Demo-Datenbankoberfläche ;-)'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  OnClose = FormClose
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
  object Splitter: TSplitter
    Left = 0
    Top = 265
    Width = 992
    Height = 8
    Cursor = crVSplit
    Align = alTop
    Beveled = True
  end
  object pnTop: TPanel
    Left = 0
    Top = 0
    Width = 992
    Height = 41
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 0
    object btnSQL: TButton
      Left = 8
      Top = 8
      Width = 97
      Height = 25
      Caption = '&SQL ausführen'
      TabOrder = 0
      OnClick = btnSQLClick
    end
    object btnEnde: TButton
      Left = 112
      Top = 8
      Width = 75
      Height = 25
      Caption = '&Ende'
      TabOrder = 1
      OnClick = btnEndeClick
    end
  end
  object StatusBar: TStatusBar
    Left = 0
    Top = 594
    Width = 992
    Height = 19
    Panels = <>
  end
  object DBGrid: TDBGrid
    Left = 0
    Top = 273
    Width = 992
    Height = 296
    Align = alClient
    DataSource = DataSource
    TabOrder = 2
    TitleFont.Charset = DEFAULT_CHARSET
    TitleFont.Color = clWindowText
    TitleFont.Height = -11
    TitleFont.Name = 'MS Sans Serif'
    TitleFont.Style = []
  end
  object DBNavigator: TDBNavigator
    Left = 0
    Top = 569
    Width = 992
    Height = 25
    DataSource = DataSource
    Align = alBottom
    TabOrder = 3
  end
  object pnInfo: TPanel
    Left = 0
    Top = 41
    Width = 992
    Height = 224
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 4
    object Splitter1: TSplitter
      Left = 697
      Top = 0
      Width = 8
      Height = 224
      Beveled = True
    end
    object SQLEingabe: TMemo
      Left = 0
      Top = 0
      Width = 697
      Height = 224
      Align = alLeft
      TabOrder = 0
    end
    object Tabellen: TMemo
      Left = 705
      Top = 0
      Width = 287
      Height = 224
      Align = alClient
      TabOrder = 1
      OnDblClick = TabellenDblClick
    end
  end
  object DataSource: TDataSource
    DataSet = ADOQuery
    Left = 632
    Top = 48
  end
  object ADOQuery: TADOQuery
    Connection = ADOConnection
    Parameters = <>
    Left = 560
    Top = 48
  end
  object ADOConnection: TADOConnection
    Left = 472
    Top = 48
  end
end

Im realen Leben sollte man allerdings nicht gänzlich auf jedwede Fehlerbehandlung verzichten.

[Asura]

Moin Moin,
nachdem ich erfolgreich nun mein Projekt mit Access beendet habe widme ich mich nun einem neuen Projekt.
Nun möchte ich aber nicht mehr mit Access arbeiten, sondern nun auf eine Datenbank zurückgreifen, die mit einem Server dann gehalten wird.

Ich bin nun auf der Suche nach Anbietern, die günstig Datenbankserver anbieten.
Bis ich einen gefunden habe, würde ich jedoch gerne schon mal beginnen. Welche Lösung wäre die Beste, um direkt eine Schnittstelle zu haben ohne groß im Programmcode was ändern zu müssen.
Eventuell in Richtung Homeserver?
Die Datenbankmodellierung habe ich bereits fertig, wenn man da noch mal rüber schauen könnte und eventuell Verbesserungsvorschläge

[Delphi.Narium]

Mein Vorgehen ist erstmal:

Connectionstring auf die neue Datenbank ändern und Programm starten.
Wenn's nicht geht (was äußerst selten ist) muss ich halt die Probleme beheben.

Wenn man sich bei den SQLs an den Standard hält, sind Probleme eher selten, ab und an werden Datentypen etwas anders gehandhabt, aber die Masse sollte einfach laufen.

[edit - etwas provokant]
Wenn man mit Delphi eine gute Datenbankapplikation geschrieben hat, ist es der egal, gegen welche Datenbank sie läuft, man ändert die Datenbankverbindung (gerne per Dialog) und das Programm läuft gegen eine andere Datenbank. Der Softwareentwickler muss die Datenbanken nicht mal alle kennen.

Klar: Auf Datenbankseite darf man dann nur das nutzen, was alle Datenbanken können. Dafür gibt es den Standard, der weitgehend eingehalten wird.

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
[/edit]

[TigerLilly]

ad DB-Server:
Wir verwenden den MS SQL Express. Der ist kostenfrei, kann auch im Netz für Mehrbenutzer fungieren + ist mit den großen Editions gut skalierbar. Für uns funktioniert das sehr gut, egal ob Einbenutzer mit Laptop oder Multiuser mit Server.
Ähnliches gibt es auch von Oracle. Alternativ gibt es natürlich auch Firebird, Progress, mySQL.

ad Datenmodell formal:
- die Tabellennamen brauchen die Präfixe nicht. Entscheide dich, wie die Tabellen heißen sollen + aus.
- Die Feldnamen der Tabellen brauchen die Präfixe ebenfalls nicht. Das macht die Namen nur unübersichtlich.
- Die Namensgebung ist nicht einheitlich: bacc_usr_ID und sere_ID - sollte wohl book_sere_ID sein. Ähnliches für booT_ID.
- Die Schreibweise ist nicht einheitlich: Wenn du booT_ schreibst müsste es auch bAcc_ heißen.
- Entscheide dich, ob die nach dem _ groß oder klein weiterschreibst: sere_Name vs catg_name.
- Die Namen der Tabellen sollten entweder alle Einzahl (bevorzugt) oder Mehrzahl sein, nicht mischen (usr_users vs booT_bookingtype).


ad Datenmodell inhaltlich:
- In Zeiten von Password-Hacks würde ich keine Passwörter speichern, sondern nur ihre Hash-Äquivalente.
- Die Verwendung von englischen Bezeichnern bleibt jedem überlassen, ich persönlich finde, dass das kein Muss ist. Verständlichkeit hat Vorrang.
- Ob du mit den angeführten Attributen auskommst, musst du wissen, ich finde die Infos zur Bank und zum User sehr dürftig. Passwörter können ein Ablaufdatum haben, sollten ev. Nicht wiederverwendet werden. USer haben Klarnamen, ev E-Mail etc. Banken vielleicht eine Adresse?
- ob Buchungen wirklich nur eine Kategorie haben, musst auch du wissen, aber ev haben die Kategorien noch eine übergeordnete Kategorie. Bzw gehören zu Ein/Ausgängen.
- Senderreceiver kann ev auch weitere Infos vertragen.

HTH TigerLilly

[p80286]

Warum werden username und pw doppelt abgelegt?
Sollten mehrere User auf einen Bankaccount zugreifen müssen/können, sollte diese Relation über eine entsprechende Tabelle abgebildet werden.

Gruß
K-H

@Delphi.Natrium
Ganz so einfach ist es in der Praxis nicht, aber das Prinzip ist schon korrekt.

[jobo]

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

[Delphi.Narium]

Zitat von jobo:

Zitat von Delphi.Narium:

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

@Jobo:

Du beschreibst eigentlich genau das, was ich meine:
entweder <-> oder.

Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.

Ein bisserl Logik in der Datenbank und die "Reste" in N Applikationen? NoGo

Wer sowas entwirft, empfiehlt ... gehört gehauen