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

Alles zum PostgreSQL-Server

Moderator: Moderatoren

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

Beitragvon AUGE_OHR » Di, 23. Sep 2014 6:27

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
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10260
Registriert: Do, 16. Mär 2006 8:55
Wohnort: Hamburg

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

Beitragvon georg » Di, 23. Sep 2014 7:39

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
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1801
Registriert: Fr, 08. Feb 2008 22:29

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

Beitragvon AUGE_OHR » Di, 23. Sep 2014 21:57

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
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10260
Registriert: Do, 16. Mär 2006 8:55
Wohnort: Hamburg

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

Beitragvon Tom » Mi, 24. Sep 2014 15:52

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
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 6706
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin


Zurück zu SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast