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.