PostgreSQL "UPDATE " Teil2

Alles zum SQL-Dialekt

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

PostgreSQL "UPDATE " Teil2

Beitrag von AUGE_OHR »

hi,

ich sende ein SELECT, mit 28 FELDern, auf eine Table mit > 500000 Records.
das Result Object benötigt einige Zeit zu zusammenstellen bis ich es im Browse anzeigen kann.
SELECT a.fkdnr, ... FROM fs_ustrich AS a
Start request
finsh request after 13.91 Sec.

create Browse :
Browse Pop-Up after 0.83 Sec.

UPDATE fs_ustrich AS a SET fartikel='ohne Limit 1' WHERE a.__record=14
saved
UPDATE :0.01 Sec.
Result RefreshAll() :13.12 Sec.
Result goTo() :0.01 Sec.
wenn ich nun einen Record "editiere" und "save" geht das schnell, aber ein "refresh" bedeutet "neu einlesen".

Ich habe aber die Records nicht in einem Array sondern nur das Result Object mit "Informationen" ( Pointer) "wo" ich mit o:GetValue(nRow,nCol) die Daten finde. das Result Object ist dabei rekursive aufgebaut ähnlich einem Array ( oder DataObject )

Wenn ich nun den "refresh" per

Code: Alles auswählen

WHERE a.__record=14
beim "re-read" begrenze bekomme ich auch nur Information für 1 Record d.h. mein Browse zeigt nur 1 Zeile an.

wenn ich nun das "alte" Result Object nicht "lösche" kann ich über die MemberVar ::Row <-> __record den betreffenden Teil identifizieren.

Frage : kann ich die Informationen vom "neuen" Pointer "so" in das "alte" Result Object einbauen ?
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: PostgreSQL "UPDATE " Teil2

Beitrag von georg »

Hallo, Jimmy -


indem Du anders denkst. Vor einigen Jahren habe ich mal einen Thread zum Thema Paradigmenwechsel gestartet, der aber sehr schnell im Sande verlaufen ist, weil sich (damals) keiner für genau diese Fragen interessierte.

Das Problem liegt darin, dass SQL den Focus auf Result Sets legt, während bei Xbase/Clipper immer die gesamte Datei (eventuell gefiltert) gesehen wird. Das lässt sich am einfachsten am XbpBrowse-Object beweisen, denn die gesamte Navigation (gerade der vertikale Scrollbar) basieren auf einer satzweisen Navigation, die SQL einfach fremd ist.

Um das hinzubekommen, hat Alaska ja diese ganzen "internen" Felder und CONSTRAINTs definiert, damit man mit SQL das Verhalten einer Clipper-Datei simulieren kann.

Du übersiehst aber auch Probleme, die hier im Zusammenhang auftreten. Wenn die Tabelle z.B. nach Nachname angezeigt wird, und der Nachname einer Kundin, die geheiratet hat, wird geändert, würde Dein Einlesen des einen Datensatzes den zwar im Browse aktualisieren, die Sortierfolge aber wäre "kaputt".

Du musst Dich jetzt entscheiden, wie das neue Paradigma Deines Programms aussehen soll. Fällt der so geänderte Datensatz "aus dem Fokus" (= sichtbarem Bereich), oder verankerst Du den Browse an diesem Datensatz und musst folglich auch das Umfeld neu einlesen?

Sätze vor der Änderung:

Müller, Klaus
Müller, Martin
Müller, Martina <== heiratet und heisst jetzt Schmitz
Müller, Norbert
Müller, Ottilie

Alternative a:

Müller, Klaus
Müller, Martin
Schmitz, Martina
Müller, Norbert
Müller, Ottilie

Alternative b:

Schmitz, Gerd
Schmitz, Gerda
Schmitz, Martina
Schmitz, Nobilia
Schmitz, Peter

Alternative c:

Müller, Klaus
Müller, Martin
Müller, Norbert
Müller, Ottilie
Müller, Paule


Alternative a wäre das Ergebnis Deines Ansatzes, den "einen" Satz zu refreshen.

Alternative b erscheint uns von der Datenlogik in Clipper her "normal", wir sind "auf dem Datensatz" von Martina Schmitz, und daher positionieren die Navigationsblöcke die Daten um diesen Datensatz.

Alternative c wäre das Ergebnis, wie es ein SQL-Server native (!) nach einem erneuten SELECT mit den gleichen Parametern (!) liefern würde.

Zurück zu Alternative b: Diese Logik greift nicht bei SQL, da wir mit dem SELECT eine KOPIE von Datensätzen erhalten haben, die auch (normalerweise, aber auch abhängig von der Cursor-Implementierung) nicht zwingend aktualisiert werden, sondern Du musst den SELECT Befehl erneut ausführen.

Damit kommen wir zum grundlegenden Thema, der Performance. Ein SELECT <Feldliste> FROM <Tabelle> ohne LIMIT führt zu grandiosen Verzögerungen, die man einem Kunden/Anwender heute nicht mehr erklären kann, insbesondere, wenn man auf einen SQL-Server "umstellt".

Paradigmen-Wechsel.

Für die Anzeige des Browse reicht ein SELECT <Feldliste> FROM <Tabelle> LIMIT 50. Damit kannst Du die erste Seite anzeigen. Meine Programme haben dann ein XbpSLE, mit dem die Ansicht POSITIONIERT werden kann. Hier muss man zwischen POSITIONIEREN und FILTERN unterscheiden (daher werden das in Zukunft zwei Felder werden), da beide unterschiedliche Ergebnisse haben. Wird gefiltert, reduzieren sich die Ergebnis-Zeilen des SELECT manchmal dramatisch: liegt SELECT Count(*) FROM <Tabelle> WHERE <Bedingung> unter 50 Zeilen, kann man das ganze Ergebnis einlesen und anzeigen.

Bei einer POSITIONIERUNG hingegen will der Anwender weiterhin Zugriff auf ALLE Daten haben, daher muss eine entsprechende Eingrenzung und Navigation her. Aber dafür muss man sich mal überlegen, "wie verhält sich mein Programm heute - und WARUM?" und "wie soll sich mein Programm zukünftig verhalten - und WIE realisiere ich das?"

Für mich habe ich einen Lösungsansatz gefunden, den ich auch auf der JHV als Vortrag halten würde (kam bis jetzt noch keine offizielle Stellungnahme dazu), aber mich würde interessieren, wie Ihr das lösen wollt, denn vielleicht findet sich ja noch ein besserer Ansatz.


Gruss,

Georg
Zuletzt geändert von georg am Sa, 14. Jul 2012 16:31, insgesamt 1-mal geändert.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Hans Zethofer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 278
Registriert: Fr, 27. Jan 2006 8:29
Wohnort: 2700 Wiener Neustadt
Hat sich bedankt: 1 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von Hans Zethofer »

gut erklärt =D>
_____________
lg
Hans
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: PostgreSQL "UPDATE " Teil2

Beitrag von AUGE_OHR »

hi georg,

danke für deine Antwort. Die Frage mit "Sortierung" / re-fresh etc. stellt sich bei mir nicht da ich ja nicht mit einem Array arbeite.
wie man an pgAdmin.EXE sehen kann dauert das bei > 500000 ca. 25Sec ... neeee [-X

ähnlich wie bei einer "detached local" arbeitet mein o:datalink Codeblock direkt auf eine Methode in PgResult.
diese "holt" mir dann "live" die Daten für den DbSkipper mittels der Informationen (Pointer) von PgResult.
PgResult hat also selbst gar keine Daten die ich "refresh"en müsste sondern nur die Informationen müssten stimmen.

wenn ich nun 1 Satz "ändere" dann sind die anderen 499999 Informationen doch noch "valid", oder ?
nur 1 Satz "liegt" jetzt wo anderes und nur diese neue Information müsste ich "updaten".

wo es "noch" harkt wäre bei einem "neuen" Datensatz, also 500001, den meine Informationen gehen ja nur bis 500000.


***

das ganze ist jetzt betrachtet zu PgAdmin.EXE wo ich auch kein "automatisches" update von Änderungen anderer User im Browse mitbekomme.
bei einem Array hab ich ja immer den Zustand wie er beim "erzeugen" war ... das könnte ein anderer User im Netzwerk geändert haben.
hier greift nun mein "Benachrichtigungs-Modul" was ich für MAPI im Netzwerk verwende wenn ich keinen Exchange Server habe.


***

es sind also 2 Punkte beim "UPDATE ..." zu beachten, aber ich möchte mich auf den ersten Teil konzentrieren und das "schneller" machen.
gruss by OHR
Jimmy
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: PostgreSQL "UPDATE " Teil2

Beitrag von AUGE_OHR »

georg hat geschrieben:Für mich habe ich einen Lösungsansatz gefunden, den ich auch auf der JHV als Vortrag halten würde.
der Vortrag würde mich interessieren, aber nicht zur JHV :!:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von brandelh »

Hallo Jimmy,

SQL-Server sind nicht automatisch schnell :!:
Ich musste Access Anwendungen bedienen, die auf einen SQL Server zugriffen und beim skippen von einem Datensatz auf den nächsten (max. 1500 Records
in der führenden Datei) gut 30 Sekunden Wartepausen einlegten. Bei meinen 5 Datensätzen habe ich es ertragen ... aber es gab auch Personen die 500 so bearbeiten mussten. Offensichtlich wurde immer SELECT * ... ausgeführt und dann per Schleife nach den benötigten Datensätzen gesucht.
Auf einer MDB für einen Einzelplatzrechner wäre dieser Zugriff ja noch OK gewesen, ein normaler Rechner hätte das schnell erledigt.
Aber 30 Mann fast gleichzeitig über das Netz und der Server sollte ja noch andere bedienen :badgrin:

Der SELECT Befehl soll nur die Daten zurückliefen, die man wirklich braucht (Datensätze und Felder) und dann ist es auch flott.
Unter DOS CLIPPER war das ja auch OK:

Code: Alles auswählen

do while lastkey()<>K_ESC
     inkey()
enddo
der Rechner war allein für eine Aufgabe da ... unter Windows kamen so die Progbleme - wie jeder wissen sollte.
Nun hat man eben keine lokale DBF sondern einen SQL Server der viele Anwender bedienen soll.
Dem Server kann man das Leben schwer oder leicht machen.
Gruß
Hubert
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16501
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von Martin Altmann »

Jimmy,
AUGE_OHR hat geschrieben:
georg hat geschrieben:Für mich habe ich einen Lösungsansatz gefunden, den ich auch auf der JHV als Vortrag halten würde.
der Vortrag würde mich interessieren, aber nicht zur JHV :!:
selbstverständlich nicht zur JHV, sondern im Anschluss an das gemeinsame Mittagessen.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige 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: PostgreSQL "UPDATE " Teil2

Beitrag von AUGE_OHR »

Martin Altmann hat geschrieben:selbstverständlich nicht zur JHV, sondern im Anschluss an das gemeinsame Mittagessen.
da geht es dann weiter mit Teil2 der JHV. Ihr glaubt doch nicht im Ernst das wir mit der JHV in 1-2 Std durch sind ...
gruss by OHR
Jimmy
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: PostgreSQL "UPDATE " Teil2

Beitrag von AUGE_OHR »

brandelh hat geschrieben:SQL-Server sind nicht automatisch schnell :!:
das habe ich schon verstanden ;)
brandelh hat geschrieben:beim skippen von einem Datensatz auf den nächsten gut 30 Sekunden Wartepausen einlegten. Bei meinen 5 Datensätzen habe ich es ertragen ... aber es gab auch Personen die 500 so bearbeiten mussten. Offensichtlich wurde immer SELECT * ... ausgeführt und dann per Schleife nach den benötigten Datensätzen gesucht.
soweit bin ich auch gewesen mit 500000 / 12 Sec. und musste einsehen das es "so" nicht geht.
auch das "Gegenteil" mit "LIMIT 1" bringt es "so" nicht denn in einem Browse habe ich ja mehrere Zeilen.
vielmehr muss man wohl mit LIMIT und OFFSET arbeiten und benötigt eine eigene Cursor Navigation um "nachzuladen".
gruss by OHR
Jimmy
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16501
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von Martin Altmann »

AUGE_OHR hat geschrieben:
Martin Altmann hat geschrieben:selbstverständlich nicht zur JHV, sondern im Anschluss an das gemeinsame Mittagessen.
da geht es dann weiter mit Teil2 der JHV. Ihr glaubt doch nicht im Ernst das wir mit der JHV in 1-2 Std durch sind ...
Aber sicher werden wir mit der JHV bis zum Mittag durch sein :!:

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von UliTs »

AUGE_OHR hat geschrieben:
Martin Altmann hat geschrieben:selbstverständlich nicht zur JHV, sondern im Anschluss an das gemeinsame Mittagessen.
da geht es dann weiter mit Teil2 der JHV. Ihr glaubt doch nicht im Ernst das wir mit der JHV in 1-2 Std durch sind ...
Du glaubst doch nicht im Ernst, dass es länger dauert :lol: .
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von UliTs »

Martin Altmann hat geschrieben:Aber sicher werden wir mit der JHV bis zum Mittag durch sein :!:
Um wieviel Uhr geht denn jetzt die JHV los?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
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: PostgreSQL "UPDATE " Teil2

Beitrag von georg »

Hallo, Uli -


im Eintrag von Martin gibt's eine Aussage dazu:

http://www.xbaseforum.de/viewtopic.php? ... =75#p71404


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von UliTs »

Danke,

ist aber sowieso schon fast egal, da fast alle günstigen DB-Tickets bereits weg sind...

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16501
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: PostgreSQL "UPDATE " Teil2

Beitrag von Martin Altmann »

Georg,
Danke. Die Einladung wird (sehr) bald verschickt an alle.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Antworten