PostgreSQL "Index"

Alles zum PostgreSQL-Server

Moderator: Moderatoren

PostgreSQL "Index"

Beitragvon AUGE_OHR » So, 22. Jul 2012 17:40

hi,

wieder so eine Newbie Frage : wofür "benötige" ich einen "Index" wie ihn pgDBE anlegt ?

wenn ich "ORDER BY" verwende habe ich doch eine "Sortierung" wie bei einem "Index" , oder ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon georg » So, 22. Jul 2012 20:19

Hallo, Jimmy -


wieder so eine "esoterische" Frage :D

Es gibt verschiedene Gründe.

1. ein PRIMARY KEY erzwingt einen Index, da der Server sonst nicht prüfen kann, ob bei der Anlage eines Satzes eine Verletzung des PRIMARY KEY CONSTRAINTS auftritt;
2. zur Suchoptimierung

Das Thema Suchoptimierung ist etwas umfangreicher, und ich kann es hier nur in grundsätzlichen Zügen anreissen.

Wenn Du mit einer Tabelle arbeitest, die tausend Datensätze hast, kannst Du das Thema Index eigentlich knicken, da jeder SQL Server schnell genug sein sollte, hier jede Sortierung im Handumdrehen zur Verfügung zu stellen. Reden wir über eine Million Datensätze, sieht das Thema anders aus, dann kann der SELECT ... ORDER BY schon ordentlich dauern. Manche SQL Server dokumentieren das auch, indem sie im Log einen Hinweis hinterlassen, dass ein Index (!) erstellt wurde. Dieser Index ist aber temporär und wird danach "entsorgt".

Jetzt kommen wir zum "Grundsätzlichen", denn jeder SQL-Server verhält sich hier anders. Der eine Server mag den Index zwar temporär anlegen, hält ihn aber so lange am Leben, wie Deine Session dauert und aktualisiert ihn auch in dieser Zeit, ein anderer Server kann den temporären Index sofort löschen, nachdem der SELECT Befehl abgearbeitet ist. Meine Ausführungen gelten für das grundsätzliche Verhalten, wie sich PostgreSQL oder MySQL verhält, hängt immer von der Implementierung ab.

Wenn Du also weisst, dass Deine Anwender eine bestimmte Suchreihenfolge bevorzugen, ist es sinnvoll, hierfür einen Index anzulegen, da durch einen solchen Index die SELECT Anweisungen deutlich schneller abgearbeitet werden als ohne.

Query-Optimizer - das ist jetzt ganz "esoterisch". Ich komme halt mal wieder auf die IBM iSeries (oder heisst sie jetzt i5?) zurück. Dort arbeitet ein richtig geiler Query-Optimizer, der alle vorhandenen Index-Dateien überprüft und die verwendet, die der Suchabfrage am ehesten entsprechen. Das könnte so aussehen:

Du hast ein
Code: Alles auswählen
SELECT * FROM kunden WHERE KName = 'Müller' AND KGeboren = '1977-06-13'


Es gibt einen Index über KName, KVorname - dann nimmt ein guter Optimizer diesen Index, sucht dort alle 'Müller' raus und jagt die Abfrage nach dem Geburtsdatum über dieses Subset, was natürlich rasend schnell ist (es sei denn, es gibt zwei Millionen 'Müller' in der Tabelle). Gibt es noch einen Index über das Geburtsdatum, würde ein richtig guter Optimizer prüfen, bei welchem Index weniger Zeilen rauskommen, diesen Index verwenden und dann die zweite Abfrage über das Subset jagen.

Aber das ist alles abhängig von der Implementierung des jeweiligen Servers, und es kann auch schon vom Betriebssystem des Servers abhängen, was geht und was nicht.

Jetzt schaue ich in meine Glaskugel und sehe Deine nächste Frage: "Soll ich dann einen Index über jedes Feld legen?" Die Antwort lautet: "Am besten nicht", denn jeder Index muss gepflegt werden, und das kann zu Verzögerungen führen. Bei richtig grossen Tabellen würde ich über die Felder, die voraussichtlich als Suchkriterium dienen, einen Index legen.

Beispiel (ich weiss, ich schweife ab, aber was solls, das tun andere auch): MySQL auf Linux ist case sensitive. meineTabelle <> meinetabelle <> MEINETABELLE. Unter Windows wäre diese drei Tabellen- (oder Datenbank-)namen identisch. Grund: MySQL legt für jede Database ein Verzeichnis an, und für jede Tabelle eine Datei. Da diese unter Linux (normalerweise) auf einem Dateisystem abgelegt werden, das case sensitive ist, schlägt ein
Code: Alles auswählen
SELECT * FROM meineTabelle
fehl, wenn die Tabelle mit
Code: Alles auswählen
CREATE TABLE meinetabelle
angelegt wurde.

Leider sind diese Hinweise oft sehr tief im Handbuch versteckt, und man wundert sich, warum die Anwendung auf dem heimischen PC (SQL Server unter Windows) beim Kunden nicht läuft, obwohl der die gleiche Version des Servers auf Linux (oder Mac OS) einsetzt.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » So, 22. Jul 2012 21:25

georg hat geschrieben:wieder so eine "esoterische" Frage :D
das ist meine "innere" Stimme die immer alles hinterfragt was nicht "[erledigt]" ist ;)
georg hat geschrieben:1. ein PRIMARY KEY erzwingt einen Index, da der Server sonst nicht prüfen kann, ob bei der Anlage eines Satzes eine Verletzung des PRIMARY KEY CONSTRAINTS auftritt;
2. zur Suchoptimierung
ad 1.) das wäre beim öffnen einer DBF gewöhnlich die erste Index Datei / Tag.

ad 2.) grundsätzlich habe ich es verstanden das ich unbedingt mittels "WHERE" eingrenzen muss um schneller ein Result zu bekommen.

wenn ich die Kunden Nummer "weiss"
Code: Alles auswählen
"SELECT "+cFields+" FROM "+ cTable+ " WHERE kdnr = '" +cSeekID+"'"
das ist schnell ... gibt ja auch nur "1" in oResult:rows zurück (wenn er ihn findet .. )

wenn ich die kdnr aber nicht "weiss" kommt der Browse ... und der Scrollbar (vertical -> Lastrec)
ich kann aber nicht am Anfang "eingrenzen" bevor der User "inkrementell" eine Eingabe gemacht hat
Code: Alles auswählen
"SELECT "+cFields+" FROM "+ cTable
und das kann ja "dauern" ...

wenn der User nun was eingibt müsste ich "jeweils" einen neuen SQL Befehl abschicken (ich gehe mal davon aus das es SUBSTR gibt ...)
Code: Alles auswählen
"SELECT "+cFields+" FROM "+ cTable+ " WHERE SUBSTR(xxx,1,"+STR(nLen))+") = '" +SUBSTR(cSeekxxx,1,nLen)+"'"
das werden ja eine Menge Anfragen ... kann man das "optimieren" ?
der "Index" wäre meistens nicht der "PRIMARY KEY" (kdnr) sondern Name, Strasse etc. als xxx (Type "C" ) also die "anderen" Index Dateien / Tags.

für meine Xbase++ Anwendung mit DBF sind "alle" Indexe / Tags "wichtig" aber auch dort macht "mehr" auch "mehr" an Arbeit / Pflege notwendig.
da Alaska für pgDBE im DbfUpsize.EXE die Option für Index Dateien anbietet scheint es wohl Sinn zu machen "zusätzlich" (?) zum "PRIMARY KEY" noch weiter "Indexe" in PostgreSQL anzulegen.

Frage : man müsste die "festen" Index Dateien ja "pflegen" ... wie ? "Trigger" ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon Martin Altmann » So, 22. Jul 2012 21:44

Jimmy,
es gibt kein substr() - das heißt bei SQL: LIKE
Indexe müssen nicht per trigger o.ä. gepflegt werden - sind sie angelegt, kümmert sich der Server um die Pflege!

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

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
 
Beiträge: 12738
Registriert: Fr, 23. Sep 2005 3:58
Wohnort: Berlin

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » So, 22. Jul 2012 23:57

Martin Altmann hat geschrieben:es gibt kein substr() - das heißt bei SQL: LIKE
ok wieder was gelernt, danke
Martin Altmann hat geschrieben:Indexe müssen nicht per trigger o.ä. gepflegt werden - sind sie angelegt, kümmert sich der Server um die Pflege!
d.h. ich muss mich nicht um die Alaska "Index" Felder kümmern ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon Martin Altmann » Mo, 23. Jul 2012 0:17

Moment!
Felder haben per se nichts mit Index zu tun. Es gibt Felder, für die implizit ein Index angelegt wird. Für alle anderen Felder, für die Du ein Index haben willst, musst Du ihn einmalig anlegen.

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

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
 
Beiträge: 12738
Registriert: Fr, 23. Sep 2005 3:58
Wohnort: Berlin

Re: PostgreSQL "Index"

Beitragvon brandelh » Mo, 23. Jul 2012 0:30

Was Jimmy wohl meint sind die (internen) Felder, die Alaska anlegt um die zusammengesetzten Indexe einer DBF zu simmulieren.
Vermutlich hat Alaska für die Pflege auch dieser (internen) Felder trigger angelegt und auch hier sollte man wohl besser die Finger weg lassen.
Viele Köche verderben den Brei und wenn Alaska schon versucht eine DBF in einen SQL Server zu quetschen, sollten die wissen was man braucht.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: PostgreSQL "Index"

Beitragvon georg » Mo, 23. Jul 2012 5:19

Martin Altmann hat geschrieben:Jimmy,
es gibt kein substr() - das heißt bei SQL: LIKE
...

Viele Grüße,
Martin


Hallo, Martin -


zumindest für MySQL trifft dies nicht zu:

Code: Alles auswählen
SELECT * FROM UserDB WHERE UserName LIKE 'Mart'


ergibt

Empty set (0.04 sec.)


Man muss dem Server sagen, dass auch eine Wild Card im Spiel ist:

Code: Alles auswählen
SELECT * FROM UserDB WHERE UserName LIKE 'Mart%'


Diese Aufgabe übernimmt übrigens das Prozent-Zeichen, und nicht der *.

Hier gilt mein immer wiederholter Hinweis: Implementierungsabhängig.

SQLite reagiert so:

'Weber' = 'WEBER' => falsch
'Weber' LIKE 'WEBER' => richtig

MySQL reagiert so:

'Weber' = 'WEBER' => richtig
'Weber' LIKE 'WEBER' => richtig


Martin Altmann hat geschrieben:Jimmy,
es gibt kein substr() - das heißt bei SQL: LIKE
...

Viele Grüße,
Martin


Auch der Aussage, es gäbe kein substr(), muss widersprochen werden:

Code: Alles auswählen
SELECT substr('Peter', 1, 3)


ergibt ...

Code: Alles auswählen
+--------------------------+
| substr('Peter', 1, 3)    |
+--------------------------+
| Pet                      |
+--------------------------+
1 row in set (0.00 sec)


Geht doch ... Es gibt eine ganze Menge Funktionen, die man bei SQL Anweisungen verwenden kann. Man glaubt es kaum.

Darum geht auch ein

Code: Alles auswählen
SELECT * FROM Kunden WHERE Substr(KName, 1, 3) = 'Web'


Welche Variante schneller ist (denn da liegt letztendlich der Unterschied) muss man im Vergleich feststellen.

Und wo wir gerade bei der Optimierung des User Interface sind, warum nicht gleich

Code: Alles auswählen
SELECT * FROM Kunden WHERE KName LIKE '%web%'



Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL "Index"

Beitragvon Martin Altmann » Mo, 23. Jul 2012 6:59

Georg,
bist Du Dir sicher, dass es substr() bei allen SQL-Derivaten gibt (also ANSI-SQL ist)? Ich nicht - bei LIKE bin ich mir das aber schon.
Ich würde davon absehen, etwas mit der Syntax einem bestimmmten "SQL-Derivates" zu lösen, wenn es auch in ANSI-SQL gelöst werden kann - wer weiß, was Morgen ist.... ;-)
Und substr() gibt es so nur unter Oracle und DB/2 (was die bekannteren anbelangt). Bei Postgres, MySQL, MS-SQL-Server heißt die substring().

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

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
 
Beiträge: 12738
Registriert: Fr, 23. Sep 2005 3:58
Wohnort: Berlin

Re: PostgreSQL "Index"

Beitragvon georg » Mo, 23. Jul 2012 8:44

Hallo, Martin -


unter MySQL geht substr() und substring(). Meine Beispiele kommen normalerweise von meinem unter Linux laufenden MySQL Server.

Daher auch meine immer wiederkehrenden Hinweis auf die Implementierung beim jeweiligen Server.

Aber, SUBSTRING() gehört zu ANSI SQL Definition und wird daher von den "grossen" Namen unterstützt, während SUBSTR() eine Verkürzung ist, deren Implementierung wieder mal ... serverabhängig ist. Für uns als Xbase-Programmierer ist SubStr() natürlich "normaler".

Daher gehört SUBSTRING auch zu den reservierten Begriffen im ANSI SQL:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.quickref/html/quickref/BEIJHIFE.htm


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 1:14

brandelh hat geschrieben:Was Jimmy wohl meint sind die (internen) Felder, die Alaska anlegt um die zusammengesetzten Indexe einer DBF zu simmulieren.
YUP
brandelh hat geschrieben:Vermutlich hat Alaska für die Pflege auch dieser (internen) Felder trigger angelegt
YUP
brandelh hat geschrieben:... und auch hier sollte man wohl besser die Finger weg lassen.
Viele Köche verderben den Brei und wenn Alaska schon versucht eine DBF in einen SQL Server zu quetschen, sollten die wissen was man braucht.
das sehe ich aber aus einer anderen Perspektive.
wie will man mit "etwas" arbeiten wenn man nicht weiss wie es funktioniert ? wo sind die "System" bedingten Limits ?

ich möchte ja später, wenn es funktioniert, mit pgDBE arbeiten also mit dem Konzept von Alaska.
wir sehen aber welche "Problem" bei der Umsetzung entstehen und "lernen" von "vorhandenem" Lösungen.

beim "Index" stellte sich für mich nun die Frage ob ich den für PostgreSQL überhaupt noch brauche ?
bei OFFSET "dachte" ich ja ich konnte ihn damit gleich "Positionieren", aber das er dafür "skippen" muss war mir nicht klar.

Frage : muss er bei einem "Index" auch noch "skippen" ?
wäre " WHERE x='a' " genau so schnell wie " WHERE x= 'z' " ?

bleibt noch die Frage nach der "Position" ... "wo" befinde ich mich wie bei OrdKeyNo() von "Comix"
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon UliTs » Di, 24. Jul 2012 8:45

AUGE_OHR hat geschrieben:ich möchte ja später, wenn es funktioniert, mit pgDBE arbeiten also mit dem Konzept von Alaska.

Noch einmal zurück zu Select-Bereichen mit all den Nachteilen :shock: . Da verzichte ich gern :) :!:
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2356
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: PostgreSQL "Index"

Beitragvon georg » Di, 24. Jul 2012 8:55

UliTs hat geschrieben:
AUGE_OHR hat geschrieben:ich möchte ja später, wenn es funktioniert, mit pgDBE arbeiten also mit dem Konzept von Alaska.

Noch einmal zurück zu Select-Bereichen mit all den Nachteilen :shock: . Da verzichte ich gern :) :!:
Uli


Hallo, Uli -


da stimme ich Dir aus vollem (und mit ganzem) Herzen zu!


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL "Index"

Beitragvon bgl » Di, 24. Jul 2012 13:39

1. ein INDEX ist im Zugriff schneller, als eine nicht-index-spalte, da der Cache ihn anders behandelt. Es ist also für die Verwendung als Teil einer WHERE-clause besser, einen INDEX zu nutzen.

2. ein INDEX in PostgreSQL kann für unterschiedliche Arten der Abfrage optimiert werden, Standardvorgabe ist ein INDEX-typ, der für numerische Vergleiche und einfache Gleichsetzung (WHERE COLUMN_NAME_HERE='nur diese eintraege!') optimiert ist, es ist aber auch möglich z.B. einen INDEX-Typ, der für Volltextsuchen optimiert ist zu verwenden (WHERE COLUM_NAME_HERE LIKE '%worin dies enthalten ist%').

3. Constraints (ausser CHECK) erzeugen fast immer einen INDEX - dies gilt vor allem für UNIQUE und PRIMARY KEY

4. FOREIGN KEYs benötigen einen INDEX um darauf zu verweisen - das führt hier aber glaube ich zu weit und im Fall des Alaska-Ansatzes könnte man da schätze ich meistens mit dem Emulator-für-die-physikalische-Datenposition-Schlüssel arbeiten, der ja glaube ich ohnehin als PRIMARY KEY definiert wird.
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
 
Beiträge: 43
Registriert: Di, 30. Aug 2011 19:45

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 19:32

georg hat geschrieben:
UliTs hat geschrieben:Noch einmal zurück zu Select-Bereichen mit all den Nachteilen :shock: . Da verzichte ich gern :) :!:
da stimme ich Dir aus vollem (und mit ganzem) Herzen zu!
das müsst ihr mir jetzt erklären was ihr damit meint :?: was ist das "Problem" mit Select Bereichen ?

wenn ich später mal pgDBE verwenden will muss ich doch mein Xbase++ Konzept nicht umstellen. das wäre doch der Vorteil von pgDBE
pgDBE "sollte" doch sauber mit SELECT arbeiten oder welche Probleme entstehen dadurch ?

p.s. sehe ich das richtig das ich für jede Table "eine Connection" benötige ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 19:34

hi,
bgl hat geschrieben:1. ...
Danke für die Zusammenfassung. Ich "denke" ich habe es nun langsam kapiert ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon georg » Di, 24. Jul 2012 20:18

AUGE_OHR hat geschrieben:p.s. sehe ich das richtig das ich für jede Table "eine Connection" benötige ?



Hallo, Jimmy -


da liegt das Problem im Kopf:

Code: Alles auswählen
SELECT * FROM table1, table2, table3 WHERE table1.field1 = table2.field3 AND table2.field4 = table3.field6


Das erzeugt EIN RESULT SET aus DREI Tabellen.

Wenn Du im Alaska-PostgreSQL Ansatz bleibst, hast Du Recht.

Sofern Du auf SQL umstellst/umstellen willst, musst Du hier umdenken.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1769
Registriert: Fr, 08. Feb 2008 21:29

Re: PostgreSQL "Index"

Beitragvon brandelh » Di, 24. Jul 2012 20:57

Alaska hat ja immer propagiert, dass die Datenzugriffe egal mit was immer gleich funktionieren ...

nun bis auf SDFDBE, dass eine Beschreibungdatei braucht und einen viel strikteren Aufbau wie unter Clipper ... oder war das die DELDBE ...
und natürlich funktioniert das auch mit ODBC so (ODBCDBE) egal ob dahinter ein Excel XLS, MDB oder ein Oracle auf einem SuperServer läuft ...
und auch mit der pgDBE braucht man seine Programme nicht umschreiben und kann das alles so schön mischen, weil es ja dadurch einfacher wird ... :^o

Sicherlich geht alles, aber ich konnte mich mit der ODBCDBE (vielleicht sind die neuren besser) genausowenig anfreunden wie mit der DELDBE (womöglich noch mit Index) =D>

Es ist ja auch richtig, dass vom Prinzip her ein 1000 PS Supermotz Rennwagen, ein Golf, ein Fahrrad, ein 60 Tonner LKW alle in der Lage sind, ein paar Brötchen vom Bäcker um die Ecke nach Hause zu bringen. Aber genauso richtig ist, dass jeder auf seinem Spezialgebiet wesentlich sinnvoller ist :D

Ich warte auf die direkte SQL Einbindung, das könnte mir gefallen insbesondere auch im Zugriff auf Array und DBF Daten.
Ich bleibe bei SQLExpress für alles was flexibel auf SQL Server (Dateien) zugreifen muss.
Eine lokale SQLite wäre eine schöne Option, wenn es einfach geht.
Ansonsten gilt immer noch ... versprechen kann man viel und versprochen hat man sich schnell :badgrin:
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 22:30

georg hat geschrieben:
Code: Alles auswählen
SELECT * FROM table1, table2, table3 WHERE table1.field1 = table2.field3 AND table2.field4 = table3.field6

Das erzeugt EIN RESULT SET aus DREI Tabellen.
Ja ... verstehe, danke
ich meint es etwas anderes ... mit mehreren "Fenstern" mit jeweils 1 Table
georg hat geschrieben:Wenn Du im Alaska-PostgreSQL Ansatz bleibst, hast Du Recht.
YUP
georg hat geschrieben:Sofern Du auf SQL umstellst/umstellen willst, musst Du hier umdenken.
ok, aber ich möchte zunächst das Konzept von Alaska evaluieren.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon UliTs » Di, 24. Jul 2012 22:34

AUGE_OHR hat geschrieben:
georg hat geschrieben:Sofern Du auf SQL umstellst/umstellen willst, musst Du hier umdenken.
ok, aber ich möchte zunächst das Konzept von Alaska evaluieren.

Ich bin gespannt, zu was für einem Ergebnis Du kommen wirst :) .
Ich kann mir nicht vorstellen, dass man dauerhaft sinnvoll mit dem Alaska-Konzept arbeiten kann ohne auf viele Vorteile von SQL-Servern verzichten zu müssen.
Insbesondere die Beschränkung auf eine inzwischen veraltete Version von PostGreSQL macht mich sehr skeptisch.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 2356
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 22:39

brandelh hat geschrieben:Alaska hat ja immer propagiert, dass die Datenzugriffe egal mit was immer gleich funktionieren ...
soweit waren wir ja schon ... aber einiges lässt sich wohl nicht so umsetzten wie gedacht oder hat andere "Side-Effecte".

der Thread hier über "Index" sollte das verdeutlichen und nachdem ich "grosse" Table anlegen konnte kann ich nun mit pgDBE meine "native" Ergebnisse "vergleichen".

passend dazu hat Alaska "heute" ja das Devcon Material zur Verfügung gestellt ;)
brandelh hat geschrieben:Ich warte auf die direkte SQL Einbindung, das könnte mir gefallen insbesondere auch im Zugriff auf Array und DBF Daten.
em, äh ... was willst du "mehr" als pgDBE ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Di, 24. Jul 2012 22:52

UliTs hat geschrieben:Insbesondere die Beschränkung auf eine inzwischen veraltete Version von PostGreSQL macht mich sehr skeptisch.
es gibt keinen Grund die neue v9.1 nicht zu installieren und es auszuprobieren ob pgDBE läuft auch wenn Alaska die Version dafür nicht freigegeben hat.

allerdings lässt es sich dann schwierig raus finden "was" im Fall eines Crash mit pgDBE nicht funktioniert hat.
Die API der v9.1x "scheint" sich IMHO nicht geändert zu haben. klar gibt es "neues" und man muss auch wieder die \bin\*.DLL in sein Workverzeichniss kopieren damit die "native" Version funktioniert.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon brandelh » Mi, 25. Jul 2012 7:03

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:Alaska hat ja immer propagiert, dass die Datenzugriffe egal mit was immer gleich funktionieren ...
soweit waren wir ja schon ... aber einiges lässt sich wohl nicht so umsetzten wie gedacht oder hat andere "Side-Effecte".

der Satz war die Einleitung für die 3 folgenden Sätze. Wenn er alleine steht, könnte man meinen ich glaube an die Aussage :badgrin:
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13267
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Mi, 25. Jul 2012 23:46

brandelh hat geschrieben:
AUGE_OHR hat geschrieben:
brandelh hat geschrieben:Alaska hat ja immer propagiert, dass die Datenzugriffe egal mit was immer gleich funktionieren ...
soweit waren wir ja schon ... aber einiges lässt sich wohl nicht so umsetzten wie gedacht oder hat andere "Side-Effecte".

der Satz war die Einleitung für die 3 folgenden Sätze. Wenn er alleine steht, könnte man meinen ich glaube an die Aussage :badgrin:
ok ... ich wollte nicht soviel "quoten".
ich wollte nur den Ball aufgreifen das es schon unsere Sache ist herauszufindenden was an pgDBE dran ist.

durch die Dieskussion beim entwickeln der "native" Version PGu haben wir ja nun vieles raus gefunden was PostgreSQL "kann" und was "nicht empfehlenswert" ist. wie hat nun Alaska mit pgDBE das ganze in Griff bekommen ... oder auch nicht ...

mir sind nun viele "System" bedingte Mechanismen klarer geworden wo man "nicht viel machen kann" ... ausser "Power"
so ist mir durchaus klar mit pgDBE ein DbGoTop() viel schneller ist als ein DbGoBottom(), aber mit einem "Index" als "ORDER BY" sollte er doch ...

auch wenn das "sinnlose" REINDEX > 2 Std auf einem i7 2630QM gebrauchte, hat es sich zumindest für den "ORDER BY" Test gelohnt ...
erschreckend langsam der Aufbau im BROWSE() !!! und für die "Hardcore" Jungs noch der Tip CTRL-PGDN :badgrin:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Do, 26. Jul 2012 0:58

hi,

nach der REINDEX Tortur hab ich das in den Eigenschaften der Function ( "Index") vorgefunden
FS_Statistiken.PNG
FS_Statistiken.PNG (21.66 KiB) 4527-mal betrachtet
einige Zahlen scheinen "sehr gross" ... was bedeuten die ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10146
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Nächste

Zurück zu SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast