Inoffizielles deutsches Xbase-Forum

hi,

pgDBE verwendet ja interne Field 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 die beiden PROCEDURE isam_rowversion_update() / isam_tablemeta_update() sind ja pgDBE spezifisch ... macht das Sinn die auf MySQL umzuschreiben ?

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.

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.

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.