interne SQL Field(s) für ISAM Style ?

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

interne SQL Field(s) für ISAM Style ?

Beitrag von AUGE_OHR »

hi,

pgDBE verwendet ja interne Field

Code: Alles auswählen

   // add "internal" Field(s)
   //
   cQuery += " __deleted    boolean NOT NULL DEFAULT false, "
   cQuery += " __record     serial  NOT NULL, "
   cQuery += " __rowversion integer NOT NULL DEFAULT 0, "
   cQuery += " __keyversion integer NOT NULL DEFAULT 0, "
   cQuery += " __lock_owner integer NOT NULL DEFAULT 0, "

   // Alaska have this
   //
   // CONSTRAINT artikel_pkey PRIMARY KEY (__record)
   //
   cQuery += " CONSTRAINT " + xtab + "_pkey PRIMARY KEY (__record)"
ich frage mich ob für MySQL die selben Fields nützlich währen ?
__deleted als "TinyInt(1)" und __record mit "int(11) NOT NULL auto_increment" würden ja Sinn machen.

für die anderen müsste man dann noch die Trigger anlegen

Code: Alles auswählen

      IF lAlaskaPGDBE = .T.
         cQuery := "CREATE TRIGGER " + xtab + "_isam_rowversion AFTER UPDATE ON " + ;
                   xtab + " FOR EACH ROW EXECUTE PROCEDURE isam_rowversion_update()"
         oPG:exec( cQuery )
         IF ResultStatus( oPG, oMain )
         ENDIF

         cQuery := "CREATE TRIGGER " + xtab + "_isam_tablemeta AFTER INSERT OR UPDATE OR DELETE ON " + ;
                   xtab + "  FOR EACH ROW EXECUTE PROCEDURE isam_tablemeta_update()"
         oPG:exec( cQuery )
         IF ResultStatus( oPG, oMain )
         ENDIF
      ENDIF
die beiden PROCEDURE isam_rowversion_update() / isam_tablemeta_update() sind ja pgDBE spezifisch ... macht das Sinn die auf MySQL umzuschreiben ?
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: interne SQL Field(s) für ISAM Style ?

Beitrag von georg »

Hallo, Jimmy -


ich persönlich halte das nicht für sinnvoll, sondern für eine bedenkliche Krücke.

Diese Felder dienen überwiegend dazu, DBF-Style Verhalten auf SQL zu übertragen - damit bremst Du SQL aus und verkomplizierst Abfragen, die Du direkt gegen die Tabellen ausführst, so musst Du vor jedem SELECT prüfen, wie SET DELETED steht und eine entsprechende Abfrage auf das Feld _deleted mit in die WHERE-Bedingung hineinnehmen. Oder zwei VIEWs definieren, eine mit, eine ohne die "deleted" Felder.

Wenn ein "Löschen" kein "Löschen" sein soll, dann arbeite mit einem Status-Feld oder schiebe die "gelöschten" Sätze in eine Schattentabelle und lösche sie in der Originaltabelle. Und wenn eine Übersicht über die Gesamtmenge der Sätze erforderlich ist, erzeuge einen JOIN von beiden Tabellen. Geht alles.

Du wirst - im Laufe der Programmentwicklung - nur mit dieser Krücke laufen können. Klar, Stabilität der Datenhaltung ist ein Gewinn, und sicher auch Geschwindigkeit, aber durch die Alaska-Krücken bremst Du Dich an anderen Stellen aus.

Ich habe es wieder und wieder gesagt, und werde nicht müde, es zu wiederholen: ein Paradigmenwechsel ist deutlich besser, als auf Alaska und ihre schauderhafte Implementierung zu warten. Ich weiss, es sind nur noch sieben Tage bis zum 30. September 2014, aber meine Programm laufen schon native unter SQL, und ich kann alle Features nutzen, die ich nutzen will ohne meinen Programmcode unnötig aufzublähen.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: interne SQL Field(s) für ISAM Style ?

Beitrag von AUGE_OHR »

georg hat geschrieben:ich persönlich halte das nicht für sinnvoll, sondern für eine bedenkliche Krücke.
YUP
georg hat geschrieben:Diese Felder dienen überwiegend dazu, DBF-Style Verhalten auf SQL zu übertragen - damit bremst Du SQL aus und verkomplizierst Abfragen, die Du direkt gegen die Tabellen ausführst, so musst Du vor jedem SELECT prüfen, wie SET DELETED steht und eine entsprechende Abfrage auf das Feld _deleted mit in die WHERE-Bedingung hineinnehmen. Oder zwei VIEWs definieren, eine mit, eine ohne die "deleted" Felder.
leider fängt man bei einer neuen Applikation nicht völlig ohne Vorgaben an. Das betrifft nun den "Inhalt" von DBF Dateien die auch Deleted() Records enthalten.
georg hat geschrieben:Wenn ein "Löschen" kein "Löschen" sein soll, dann arbeite mit einem Status-Feld oder schiebe die "gelöschten" Sätze in eine Schattentabelle und lösche sie in der Originaltabelle. Und wenn eine Übersicht über die Gesamtmenge der Sätze erforderlich ist, erzeuge einen JOIN von beiden Tabellen. Geht alles.
JA, das wäre natürlich der elegantere Weg
georg hat geschrieben:Du wirst - im Laufe der Programmentwicklung - nur mit dieser Krücke laufen können. Klar, Stabilität der Datenhaltung ist ein Gewinn, und sicher auch Geschwindigkeit, aber durch die Alaska-Krücken bremst Du Dich an anderen Stellen aus.
Ok, die Trigger kannst du schon mal streichen, aber __record mit "auto_increment" würden ja Sinn machen.
georg hat geschrieben:Ich habe es wieder und wieder gesagt, und werde nicht müde, es zu wiederholen: ein Paradigmenwechsel ist deutlich besser, als auf Alaska und ihre schauderhafte Implementierung zu warten. Ich weiss, es sind nur noch sieben Tage bis zum 30. September 2014, aber meine Programm laufen schon native unter SQL, und ich kann alle Features nutzen, die ich nutzen will ohne meinen Programmcode unnötig aufzublähen.
Die Idee eine DBE für SQL zu entwickeln ist im Prinzip das selbe wie unsere native Schnittstelle.

die DBE kann aber die normalen Xbase (all Version) Navigation Befehle verwenden während wir diese mit METHOD(en) in unserer Class nachbilden.

ob die ISAM Style Umsetzung auf SQL das hält was es verspricht hängt von der Erwartung des Käufers ab.
wer vorher noch nicht mit SQL gearbeitet hat kennt ja nur DBF Befehle die durch die pgDBE in SQL "SELECT ..." umgewandelt werden.

Im Prinzip hat Alaska also seine Ansage gehalten das man "nur" die DBE austauschen und die DBESYS anpassen muss um mit einem PostgreSQL Server zu arbeiten.
Die Frage ist nur wie die User programmiert haben und wie deren DBF Dateien aussehen und ob es Sinn macht den Source Code "so" zu überarbeiten ... oder neu schreiben.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: interne SQL Field(s) für ISAM Style ?

Beitrag von Tom »

Hallo, Georg.
ich persönlich halte das nicht für sinnvoll, sondern für eine bedenkliche Krücke.
Okay, aber dann ist Xbase++ selbst auch eine "bedenkliche Krücke", da ja damit der Versuch unternommen wurde, zwei Welten zu vereinen, um den "Legacy Code" zu schützen und zugleich Zukunftsfähigkeit zu garantieren. Dieser Ansatz hat zwar eine Weile gebraucht, funktioniert aber - und er hat nicht wenige von uns gerettet. Er wird mit dem "ISAM-SQL" wiederholt. Ob das gelingt, auch in komplexen Anwendungen mit großen Datenbanken, werden wir demnächst sehen.

Und auch in/mit Xbase++ selbst haben viele von uns irgendwann damit aufgehört, Hybride und Kompatibiltäten zu nutzen, um dazu überzugehen, Anwendungen zu renovieren. Ich denke, dass das hier auch passieren wird.

Schauen wir doch einfach mal. Der Ansatz mag seine Nachteile haben, aber sicher auch nicht wenige Vorteile. Klar wäre es eleganter, einfach von vorne anzufangen, aber darüber muss man kaum reden.
Herzlich,
Tom
Antworten