Wie würdet Ihr das lösen?

[mkinzler]

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

[Kralle]

Moin,

Zitat:

Zitat von mkinzler (Beitrag 1286737)

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

und wie würdest Du schematisch Gesehen das in meinem Fall einsetzen?

Gruß Heiko

[Perlsau]

Zitat:

Zitat von Kralle (Beitrag 1286752)

Zitat:

Zitat von mkinzler (Beitrag 1286737)

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

und wie würdest Du schematisch Gesehen das in meinem Fall einsetzen?

Die XML-Struktur ist bereits das Schema.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1286681)

Eine Datenbank kann komplett ohne Index arbeiten und tadellos funktionieren, ist dann aber um ein Vielfaches langsamer, als eine halbwegs ordentlich indizierte DB.

Ein Index verlangsamt die INSERT und DELETE-Operationen, da dieser aktualisiert werden muss. Auch ein UPDATE ohne WHERE wird dann langsamer. Auch für ein ungeordnetes SELECT benötigt man keinen Index und ein Index beschleunigt die Abfrage auch nicht (oder?).
Wenn man das allerdings auf eine ganze Datenbank ausdehnt, also mit Beziehungen zwischen den Tabellen, hast Du vollkommen Recht-

Allerdings fallen mir nicht viele sinnvolle Anwendungen ein, wo man komplett ohne Index auskommt.

Zitat:

...teilweise legt eine DB Indizes automatisch an...

Ich kenne hier nur den Primary-Key Constraint. Wo passiert das noch?

[Sir Rufo]

Also auf jeden Fall würde ich mir ein Repository anlegen, von wo aus ich auf den Kontext zugreifen kann.

Delphi-Quellcode:

TDataContext = class
  private
    FIdent: Integer;
    FText: string;
  public
    constructor Create( Ident: Integer; const Text: string );
    function ToString: string; override;

    property Ident: Integer read FIdent;
    property Text: string read FText;
  end;

IDataContextRepository = interface
  function Find( Ident : Integer ) : TDataContext;
end;

Wenn an dem Datenkontext jetzt auch noch fest der Datentyp der Eingabe festgemacht werden kann, dann haue ich den auch noch dazu. Daraus kann ich mir dann die passende Datenklasse zusammenbauen und den Wert dort hineinlegen.

Delphi-Quellcode:

  TDataValue = class abstract
  private
    FDataContext: TDataContext;
  public
    constructor Create( DataContext: TDataContext );
    property DataContext: TDataContext read FDataContext;
  end;

  TDataValueClass = class of TDataValue;

  TDataValue<T> = class( TDataValue )
  private
    FValue: T;
  public
    property Value: T read FValue write FValue;
  end;

Und so geht man Schritt für Schritt weiter bis man die gesamte Struktur logisch abgebildet hat. Dann baut man sich noch einen Importer/Exporter für die benötigten Datenformate (Text, XML, HTML, Datenbank) und jagt das da einfach durch.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Zitat:

Zitat von jobo (Beitrag 1286681)

Eine Datenbank kann komplett ohne Index arbeiten und tadellos funktionieren, ist dann aber um ein Vielfaches langsamer, als eine halbwegs ordentlich indizierte DB.

Ein Index verlangsamt die INSERT und DELETE-Operationen, da dieser aktualisiert werden muss.

Kommt drauf an, Du hast selbst unten nach mit und ohne 'Where' unterschieden.
Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Auch ein UPDATE ohne WHERE wird dann langsamer.

'dann'? Wann? Mit Index ohne 'where'? Auch das ist von anderen Bedingungen abhängig.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Auch für ein ungeordnetes SELECT benötigt man keinen Index und ein Index beschleunigt die Abfrage auch nicht (oder?).

Benötigt sowieso nicht, das war ja meine Kernaussage. Ungeordetes Select? Ich nehme an, Du sprichst nicht von Order by clauses oder doch? Beschleunigen sollte er trotzdem, wenn der Index für die Abfrage genutzt werden kann.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Wenn man das allerdings auf eine ganze Datenbank ausdehnt, also mit Beziehungen zwischen den Tabellen, hast Du vollkommen Recht-

Meine Ausführungen zum Index waren eher grundsätzlicher Natur. Ich glaube nicht, dass es dem TE an erster Stelle hilft, solche Unterscheidungen zu berücksichtigen, wenn der Begriff selbst nicht richtig verstanden ist oder ein vages Verständnis besteht, aber unter einem falschen Begriff.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Allerdings fallen mir nicht viele sinnvolle Anwendungen ein, wo man komplett ohne Index auskommt.

Wie gesagt, es ging nur um eine plastische Darstellung der Bedeutung/Funktion eines Index.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Zitat:

...teilweise legt eine DB Indizes automatisch an...

Ich kenne hier nur den Primary-Key Constraint. Wo passiert das noch?

[/QUOTE]
Kann ich nicht allgemein sagen, würde sogar davon ausgehen, dass es irgendwo da draußen Systeme gibt, die nicht mal bei einem Primärschlüssel automatisch indizieren. Es gibt aber bspw. Systeme, die das automatisch bei Unique Constraints machen.
Solche und ähnliche Konstrukte beeinflussen sicherlich auch die Insert / Update Geschwindigkeit positiv mit Index und ohne dessen direkte Verwendung in der Where Clause.

Den TE dürfte das aber eher wenig interessieren.

[mkinzler]

Zitat:

Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Es müssen aber alle Indizes (der Tabelle) mit angepasst werden.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1286783)

Zitat:

Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Es müssen aber alle Indizes (der Tabelle) mit angepasst werden.

Das ist richtig.
Es müssen u.U. sogar noch mehr Indizes als nur die der einen Tabelle angepasst werden, wenn z.B. Cascade Delete Constraints verwendet werden. Wenn in einem CRM System ein(!) Personendatensatz gelöscht wird, betrifft das dann auch alle abhängigen Datensätze, das führt u.a. zu einem Vielfachen an Löschoperationen und erneuten Indexkorrekturen. Gleichzeitig können die vorhandenen Indizes der Fremdschlüssel aber zur Lokalisierung der zu löschenden Datensätze verwendet werden und Summa Summarum ist es immer noch schneller als ohne Indizes und den dann notwendigen Full Scans.

Ich bin mir aber immer noch sicher, dass diese Diskussion hier im Thread fehlplaziert ist. Es ging mir darum Indizes und ihre Verwendung von Schlüsselfeld Definitionen zu unterscheiden. Und ein Index hat nunmal (fast) keine funktionale Bedeutung für ein Datenmodell bzw. eine Datenbank.

Hier können jetzt Anmerkungen gemacht werden, dass man gar keine Datensätze löschen soll...

[Dejan Vu]

Ohne Index sind DML-Operationen (ohne WHERE) schneller. Ich hätte das auch so einfach schreiben können. Ob das den TE interessiert, glaube ich auch nicht, aber wenn man schreibt das eine DB mit Index schneller wird, darf man das doch wohl mal klarstellen (und zwar für andere, die das dann lesen), ohne das einem das Mund im Drehen verwirdet wort, oder Wortklauberei betrieben wird oder jedes Wort auf die Goldwaage gelegt wird oder Sätze mit nicht eindeutigem Bezug in Frage gestellt werden oder obwohl wirklich sonnenklar ist, was gemeint ist, oder? :roll: Manchmal, aber nur manchmal, nervt das Forum bzw. einige kleinkarierte Beiträge und ob nun dieser oder mein voriger Beitrag dazu gezählt wird oder nicht, überlasse ich den Kleinkarierten.

[BUG]

Zitat:

Zitat von Perlsau (Beitrag 1286771)

Die XML-Struktur ist bereits das Schema.

Nicht wirklich.
Das XML-Dokument ist zwar selbstbeschreibend; es beschreibt wie es selbst aufgebaut ist. Ein XML-Schema ermöglicht es zu prüfen, ob das Dokument richtig aufgebaut ist.