Grundsätzliches zur Datenbankverwendung

[Jan]

Hallo DPler!

Ich habe ein paar Grundsätzliche Fragen zu der Art und Weise wie ich meine Datenbankanwendung am besten angehe.

Ich habe mich nun mit Ach und Krach in dieses Firebird Mysterium geklickt und getippt um es jetzt tatsächlich geschafft zu haben programmatisch eine Datenbank und einen darin enthaltenen table zu erstellen. Die Dokumentation zu den ganzen Kram ist unter aller Sau, finde ich. Aber das tut ja erstmal nix zur Sache.

Was ich mich jetzt frage ist: wie handhabe ich die Datenbank.
Ich bin also dabei das Moviecontrol 2 Projekt anzugehen.
Das bedeutet jede Menge Datensätze die auch Multimedia enthalten können und wo viel rumsortiert und gefiltert wird, etc.
Soll ich nun die Datenbank einmal öffnen, alle Daten auslesen und in den Speicher lesen, vielleicht mit Ausnahme der BLOB Felder, und dann im Speicher arbeiten? Oder sollte ich besser die Verbindung zur Datenbank durchweg bestehen lassen und alle Datenbank Anfragen des GUIs über SQL statements an die Datenbank geben? Also zum Beispiel einen Filter nach Schauspielern über ein SELECT statement an die Datenbank geben und damit dann die Ausgabe füllen?

Die nächste Frage:
Ich will dem Benutzer die Möglichkeit geben den Inhalt der tables weitgehend selber bestimmen zu können. D.h. ich will, dass er beliebige Datenfelder vorgeben kann und den Datentyp manuell festlegen kann.
Das Erstellen der tables ist ja nicht das Problem, sondern wie ich das ganze dann in meinem Programm handhabe.
Ich hatte eigentlich vorgehabt das ganze über Filmlisten - und Movieobjekte zu implementieren, allerdings wüsste ich garnicht wie ich ein Movieobjekt jetzt implementieren sollte, wenn ich nicht von vornherein weiss, wie die Daten aussehen, die das Objekt beherbergen soll. Dazu fällt mir eigentlich nur ein array ein.
Aber wie finde ich denn im Programm heraus wie der Benutzer den table erstellt hat, damit ich auch mit den Daten aus der Datenbank umgehen kann?

Hm das wars glaube ich erstmal.
Gruß

[bttb930]

Zitat:

Zitat von Jan

Soll ich nun die Datenbank einmal öffnen, alle Daten auslesen und in den Speicher lesen, vielleicht mit Ausnahme der BLOB Felder, und dann im Speicher arbeiten?

Auf keinen Fall - dann wäre es ja keine DB...

Zitat:

Zitat von Jan

Oder sollte ich besser die Verbindung zur Datenbank durchweg bestehen lassen und alle Datenbank Anfragen des GUIs über SQL statements an die Datenbank geben? Also zum Beispiel einen Filter nach Schauspielern über ein SELECT statement an die Datenbank geben und damit dann die Ausgabe füllen?

schon eher. Du kannst aber auch das Filtern den Komponenten überlassen - je nach dem welche Du verwendest und ob die das können.

Zitat:

Zitat von Jan

Die nächste Frage:
Ich will dem Benutzer die Möglichkeit geben den Inhalt der tables weitgehend selber bestimmen zu können. D.h. ich will, dass er beliebige Datenfelder vorgeben kann und den Datentyp manuell festlegen kann.
Das Erstellen der tables ist ja nicht das Problem, sondern wie ich das ganze dann in meinem Programm handhabe.
Ich hatte eigentlich vorgehabt das ganze über Filmlisten - und Movieobjekte zu implementieren, allerdings wüsste ich garnicht wie ich ein Movieobjekt jetzt implementieren sollte, wenn ich nicht von vornherein weiss, wie die Daten aussehen, die das Objekt beherbergen soll. Dazu fällt mir eigentlich nur ein array ein.
Aber wie finde ich denn im Programm heraus wie der Benutzer den table erstellt hat, damit ich auch mit den Daten aus der Datenbank umgehen kann?

Nö, kein Array. Bilde vielleicht jeden Datentyp über eine Klasse nach (TDBInteger, TDBFloat, TDBText usw) und erstelle dann die Objekte indem Du aus der DB die Tabellenfelder und ihre -typen ausliest. Die TDB...-Klassen enthalten einen Feldnamen, eine Variable für den Wert und vielleicht noch eine Feldtypbezeichnung. Daraus baust Du dir dann deine Movie-Klasse zusammen. In der könntest Du eine TObjectList haben, die die Felder enthält. Etwa so (nur dahingekritzelt, nicht geprüft):

Delphi-Quellcode:

TDBField = class
private
  FName: string;
public
  property Name: string read FName write FName;
end;

TDBIntegerField = class(TDBField)
private
  FValue: Integer;
property
  Value: Integer read FValue write FValue;
end;

{ usw, weitere TDB...Field-Klassen }

TFieldList = class
private
  Fields: TObjectList;
public
  constructor Create;
  destructor Destroy; override;
  procedure AddField(const aField: TDBField);
  function GetField(const aFieldName: string): TDBField;
end;

TMovie = class
private
  FieldList: TFieldList;
// weitere Felder und Funktionen
end;

Und dann baust Du dir einen TMovieProvider der einen TMovie zurück gibt und die Feldliste dann schon füllt.

[Jan]

Vielen Dank für die Hilfestellung.
Muss das ganze dann nurnoch nach C# transportieren, aber das dürfte nicht allzu schwer sein.

Wie sieht das allerdings mit der Laufzeit aus, wenn ich jegliche Operation direkt über die Datenbank mache?
Festplattenzugriffe sind doch um ein Vielfaches langsamer als RAM zugriffe. Und bei mehreren tausend Datensätzen kann ich mir vorstellen, dass das recht lange dauert, besonders wenn ich mit komplizierteres SELECT Anfragen arbeite. Aber wie gesagt ich hab sowas noch nicht gemacht, und ich kann mich natürlich verschätzen.
Weiterhin denke ich mir, dass ich die Tabelle ja eigentlich sowieso in den Speicher laden muss, wenn ich um Beispiel die ganze Tabelle anzeigen will, warum soll sie dann nicht gleich da bleiben?

Noch etwas anderes Grundsätzliches:
Wenn ich den TMovie so dynmamisch erstelle, wie kann ich ihn dann ausgeben?
Ich nehme mal an in sowas wie einem Listview. Ich weiß allerdings nicht, ob man in Listview-Spalten auch dropdowns und Filebrowser Buttons einbauen kann. Das wäre mal interessant zu wissen.

Gruß
Jan

[Sidorion]

@Performance: Das kannst Du getrost der Datenbank überlassen .. die hat Methoden zum Verbessern (Cashes, Indices ...)
@Darstellung: Gibbet in D7 eine Prima Klasse für: TValueListEditor

[Hansa]

Würde mir in so einem Fall eventuell mal das ClientDataSet ansehen. Das ist quasi eine In-Memory-Table.

Dann noch der obligatorische Kommentar : C, oh je. :mrgreen:

[Jan]

Zitat:

Würde mir in so einem Fall eventuell mal das ClientDataSet ansehen. Das ist quasi eine In-Memory-Table.

Dann noch der obligatorische Kommentar : C, oh je.

Hm jetzt weiß ich wieder nicht ob du von Delphi oder von C# redest. Gibts das auch in C#?
Und wenn es dann doch eine In-Memory-Table ist, dann widerspricht sich das ja mit den vorherigen Aussagen, über die Verwendung der Datenbank.

Naja ich finde C# recht interessant. Ist ja nicht C in dem Sinne. programmiert sich so ziemlich genau wie Java und damit hab ich halt sehr viel gemacht in letzter Zeit.

Zitat:

@Darstellung: Gibbet in D7 eine Prima Klasse für: TValueListEditor

Die klingt interessant, ist allerdings Delphi und ich wollte das Projekt in C# realisieren.
Gibts sowas auch vom .net framework?

Gruß
Jan

[Hansa]

[quote="Jan"]

Zitat:

Hm jetzt weiß ich wieder nicht ob du von Delphi oder von C# redest. Gibts das auch in C#?

Und wenn es dann doch eine In-Memory-Table ist, dann widerspricht sich das ja mit den vorherigen Aussagen, über die Verwendung der Datenbank.
...

Das Stichwort ist ClientDataSet. Also ist als nächstes die Suche gefragt. Wenn Du dir die Mühe machst, diese auch zu benutzen, dann dürfte irgendwo ein interessanter Borland-Link auftauchen.

Ob es das auch in C gibt ? Wer weiß. 8)

[Jan]

Hallo Hansa!
Habe mir da mal nen Artikel zu durchgelesen, den du mal in einem anderen Thread gepostet hast.

Und dann habe ich ein bisschen Source gewälzt und Beispiele geguckt und bin auf das gestoßen:

Code:

public DataSet SelectRows(DataSet myDataSet,string myConnection,string mySelectQuery,string myTableName) 
{
    FbConnection  myConn        = new FbConnection(myConnection);    
    FbDataAdapter myDataAdapter = new FbDataAdapter();
    FbTransaction myTxn            = myConn.BeginTransaction();
    
    myDataAdapter.SelectCommand = new FbCommand(mySelectQuery, myConn, myTxn);
    FbCommandBuilder custCB        = new FbCommandBuilder(myDataAdapter);

    myConn.Open();

    DataSet custDS = new DataSet();
    myDataAdapter.Fill(custDS, "Employee");

    //code to modify data in dataset here

    //Without the FbCommandBuilder this line would fail
    myDataAdapter.Update(custDS, "Employee");

    myConn.Close();

    return custDS;
 }

In dem Fall wäre das Dataset doch sowas wie eine In-Memory-Table, oder sehe ich das falsch?
Also wäre DataSet die Entsprechung zu dem geheimnisvollen "ClientDataSet"?
Gruß
Jan

[Generalissimo]

ja ein DataSet in Net kann als ClientDataset angesehen werden.
Allerdings ist das DataSet in Net viel mächtiger (contraints, relations ...).

Ein Punkt zu dem CommandBuilder -> würde ich nur im Notfall nutzen, da er sehr viel Performance kostet

DataSet als InMemory-Datenbank wird erst unter Net 2.0 wirklich seine "volle" Reife erhalten.
Erst dort wird alles binär von der Datenbank übertragen. Allerdings spielt das bei Embedded keine
Rolle.

PS: für den der den obigen Codeabschnitt nutzt, nicht vergessen die Transaction zu schließen.

Code:

 myConn.Open();
 try
 {
    DataSet custDS = new DataSet();
    myDataAdapter.Fill(custDS, "Employee");

    //code to modify data in dataset here

    //Without the FbCommandBuilder this line would fail
    myDataAdapter.Update(custDS, "Employee");
    myTxn.Commit();

 }
 except
 {
   myTxn.Rollback();
 }
 finally
 {
    myConn.Close();
 }