Diskussion: Umstellung einer Datenbank in einem Projekt

[hoika]

Hallo,

wie es so schön heisst:
Ein Bild sagte mehr als 3 Worte.

Firebird - Architekturen


Heiko

[RWarnecke]

Danke Heiko, die Beschreibung werde ich mir heute Abend zu gemüte führen. Habe Sie gerade nur mal überflogen.

[RWarnecke]

Ich bin gerade dabei die Struktur der DB-Komponenten im Programm zu analysieren. Da ich nicht viel mit den DB-Kompos gemacht habe, treten gerade ein paar Fragen auf.

1. Ich weiß, dass bei einem einfachen TTable die Abfrage
   SQL-Code:

   SELECT * FROM <tabellenname>

   gemacht wird. Was passiert aber, wenn jetzt im TTable noch eine MasterSource mit angegeben ist ?
2. Bei einer TQuery ist noch die Eigenschaft Filter gesetzt. Im SQL-Text steht nur
   SQL-Code:

   SELECT * FROM tabelle1 S LEFT OUTER JOIN tabelle2 K ON (S.ID = K.ID)

   . Müsste dann für den gesetzten Filter der SQL-Befehl so aussehen
   SQL-Code:

   SELECT * FROM tabelle1 S LEFT OUTER JOIN tabelle2 K ON (S.ID = K.ID) WHERE state=2;

3. Was muss ich beachten, wenn mit MasterSource sozusagen eine Kette gebildet wurde ?

Ich muss gestehen, ich blicke da im Moment nicht so richtig durch. Ich hoffe mir kann da jemand weiterhelfen.

[hoika]

Hallo,

zu 2.
WHERE table1.state=2;

Zu allen anderen Sachen bin ich einfach überfragt.
Ich würde eh die Finger von TTable lassen.

Da alle TTable intern eh in Queries umgewamdelt werden (bei SQL-Server),
kannst du nur durch Probieren herausfinden, was passiert.


Heiko

[RWarnecke]

Hallo Heiko,

danke erstmal für Deine Antwort.

Zitat:

Zitat von hoika

Ich würde eh die Finger von TTable lassen.

Ich will ja durch die Umstellung von den TTable's wegkommen und dabei vielleicht Abfragen in Views oder Stored Procedure's setzen.

Zitat:

Zitat von hoika

Da alle TTable intern eh in Queries umgewamdelt werden (bei SQL-Server),
kannst du nur durch Probieren herausfinden, was passiert.

Das ist nicht das was ich hören wollte. :? Da ich über 30 Tabellen habe, wird das dann eher ein munteres Ausprobieren.

[hoika]

Hallo,

dann nennen wird das mal um in

Systematischen Testen ;)

DUnit ist dein Freund


Heiko

[RWarnecke]

Hallo Heiko,

ich habe mir jetzt mal DUnit runtergeladen und mir das Tutorial angeschaut. Ich habe auch den Hintergrund der Unit verstanden. Nur verstehe ich im Moment noch nicht, wie mir die Unit bei der Umstellung helfen soll, wenn ich nichtmal weiss wie das MasterSource in einer TTable funktioniert.

[hoika]

Hallo,

es geht ums Testen.

du hast doch jetzt ein "paar" DB-Methoden,
die richtige Ergebnisse liefern.

Bsp.

Delphi-Quellcode:

function Add2(const theValue: Integer): Integer;
begin
  Result:= theValue+2;
end;

Per DUnit wäre jetzt folgender Test

Delphi-Quellcode:

type
  TTestCase1 = class(TTestCase)
    published
      procedure Check_Add2;
  end;

procedure TTestCase1.Check_Add2;
var
  iValue: Integer;
  iResValue: Integer;
begin
  iValue:= 0;
  iResValue:= Add2(iValue);
  Check(iResValue=2);
end;

So sieht das auch bei deinem (originalem) DB-Code aus.

Änderst du jetzt das Add2 irgendwie ab (TTable->TQuery),
kannst du trotzdem prüfen, ob nach der Änderung immer noch
alles so läufst, wie du es erwartet hast.


Heiko

[RWarnecke]

ok, das es ums testen geht ist mir schon klar. Aber um testen zu können brauche ich ja erstmal einen Ansatz. Dieser fehlt mir, da ich bis jetzt noch nicht weiß wie und was das MasterSource im TTable bewirkt.

[mkinzler]

Die MasterSource dient zur Abbildung einer Master/Detail Beziehung; bei Änderung des aktiven Datensatzes des Masters, wird die Detaildatenmenge entsprechend gefiltert

[Hansa]

Zitat:

Zitat von RWarnecke

..da ich bis jetzt noch nicht weiß wie und was das MasterSource im TTable bewirkt.

Beispiel : Rechnung. Du zeigst die Rechnungsnummern in einem TreeView, VST, Listbox etc. an. Das wäre die Mastersource. Sollen nun die einzelnen Positionen auch aufgeführt werden, z.B. durch anklicken der Rechn.Nr., dann kann man die Referenz auf die Detailsätze als Parameter übergeben. D.h. man wandert quasi über die Mastersource und je nach aktuellem Master-DS können die Detail-DS nachgeladen/angezeigt werden. Äh, bevor ich hier weiterschreibe (so ganz trivial ist das nämlich auch nicht) : gibt es mittlerweile zwei Firebird-Tabellen ? Also Rohdaten, die eine Master-Detail-Beziehung darstellen ? Falls nicht, bleibt das hier nämlich nur reine Theorie.

[mkinzler]

Zitat:

gibt es mittlerweile zwei Firebird-Tabellen ? Also Rohdaten, die eine Master-Detail-Beziehung darstellen ? Falls nicht, bleibt das hier nämlich nur reine Theorie.

Wenn er Abfragen verwendet, nicht. :zwinker:

[Hansa]

Aha, er soll also irgendwelche "Abfragen" auf zwei Tabellen machen, die überhaupt nichts miteinander zu tun haben ? Du erklärst ihm dann aber bitte auch, wie er da die Mastersource vernünftig einsetzt. :mrgreen:

[generic]

Wäre es nicht sinnvoll das Projekt zu modernisieren?

Zitat:

In der OO Welt ist kein Platz für datengebundenes Programmieren.

Sonst können wir doch auch alle MSAccess machen oder?

Hier ein Buch zu den Patterns welche sich eignen könnten:
Patterns of Enterprise Application Architecture

[RWarnecke]

Wenn ich die letzten Beiträge richtig verstehe, dann mache ich also nichts anderes mit dem MasterSource anzuzeigen und bei einem gewählten Masterdatensatz den dazugehörigen Detaildatensatz aus der zweiten Tabelle auszuwählen und anzuzeigen.

Also könnte pseudo-mäßig die SQL-Abfrage so aussehen ?

SQL-Code:

SELECT * FROM detailtabelle where indexfield = (Select indexfield from mastertabelle);

[joachimd]

eher

SQL-Code:

SELECT * FROM detailtabelle where indexfield = :indexfield;

IIRC wird der Parameter bei Master/Detail von Delphi richtig gesetzt. Ich selbst verwende kein Master/Detail, sondern mache das ganze über Timer, die im AfterScroll des Masters aufgezogen werden. Damit wird es zügiger, wenn durch große Datenmengen geblättert wird (Details werden erst beim Stehenbleiben für XXX ms - zB 50 - geholt).