was ist besser und schneller als die abs db ?

[agm65]

hey ich suche nach einer besseren lokalen db als die abs ? wenn ich da 2000 einträge habe und zB count(field) mach, dann dauert die jahre...was ist besser und schneller ?

[mkinzler]

FB embedded, SQLlite, MySQL embedded

[agm65]

und welche würdest du selber nehmen oder nimmst du ?

[mkinzler]

FB, daß ist aber eine subjektive Meinung.

[agm65]

ist die schnell und kann die sql befehle und was kostet die ? danke dir .

[shmia]

Zitat:

Zitat von agm65

hey ich suche nach einer besseren lokalen db als die abs ? wenn ich da 2000 einträge habe und zB count(field) mach, dann dauert die jahre...

Die Geschwindigkeiten von Abfragen hängen von deiner Datenbankstruktur und von deiner konkreten Abfrage ab.
Wie sieht denn deine konkrete Abfrage aus?
Beispiel für eine Abfrage, die immer lange dauern wird:

SQL-Code:

SELECT COUNT(*) AS Anzahl FROM Tabelle WHERE Feld1 like 'Delphi%'

Also es liegt nicht immer an der Datenbank.

[mkinzler]

Zitat:

ist die schnell

Ja,

Zitat:

und kann die sql befehle

Zitat:

ja und was kostet die ?

Ist kostenlos
www.ibphoenix.com

[agm65]

also ich hab hier bei ca 1900 einträgen und einem sql der wie folgt aussieht

Delphi-Quellcode:

select from test where deleted = 1

2 einträge und 10 sekunden wartezeit ? ist das normal ?

[mkinzler]

Das kommt u.a. auf die Indexstruktur an

[shmia]

Zitat:

Zitat von agm65

also ich hab hier bei ca 1900 einträgen und einem sql der wie folgt aussieht

SQL-Code:

select from test where deleted = 1

2 einträge und 10 sekunden wartezeit ? ist das normal ?

Hast du einen Index auf dem Feld "deleted"? Falls nein -> anlegen
Ohne Index muss jeder Datensatz untersucht werden.
Evtl. hat die Tabelle sehr viele Felder; es kommt auch darauf an, wie "breit" die Tabelle ist.

[agm65]

was heisst das genau ? wie ich die db angelegt habe ? oder wie die abs an sich aufgebaut ist ?

[agm65]

wie meinst du das ? einen index auf dem feld deleted ?

[mkinzler]

SQL-Code:

Create Index on Deleted;

o.ä.

[agm65]

und was genau bringt mir das ?

[hoika]

Hallo,

Index = schnelle Datenstruktur zum Suchen (b-Tree oder ähnliches).

ohne Index: full table scan, alle Datensätze durchsuchen
mit Index: ~ log(n) n = Datensätze, (kommt aber auf den Index selber drauf an).

1900 lokal suchen sollte schneller als 2 sekunden sein.
sicher, dass die DB daran Schuld ist ?


Heiko

[Bernhard Geyer]

ADS ist in der Regel fix wenn man es richtig anspricht. Wir haben auch Datenbanken im GB-Bereich im Einsatz und haben aktzeptable Performance. Mann sollte jedoch erstmal Grundwissen im Bezug auf SQL mitbrigen und auch wissen was man mit SQL-Abfragen alles anrichten kann.

SQL-Code:

Z.B. ein SELECT * FROM MyFeld like '%wert%'

bring so ziemlich jede Datenbank aus dem Tritt.


Noch ein Tipp für ADS. Mal die Extensions von ADS vom Virenscanner ausnehmen lassen.

[agm65]

ja, in meinem programm geht das sogar schneller als in deren db manager da brauch das doppelt so lange

[mkinzler]

Existiert den jetzt ein Index für das Feld Deleted?

[agm65]

noch nicht, ich weiss nicht wie ich den anlege.....

[mkinzler]

Man schaue in der Anleitung nach, bzw. schaue im Admin-Tool

[agm65]

alles klar..okay, danke mach ich !

[alzaimar]

Zitat:

Zitat von agm65

also ich hab hier bei ca 1900 einträgen und einem sql der wie folgt aussieht

Delphi-Quellcode:

select from test where deleted = 1

2 einträge und 10 sekunden wartezeit ? ist das normal ?

Also ich denke mal, da ist man zu Fuss besser, als 10 Sekunden :shock: , oder hab ich da etwas misverstanden? Bei 1900 Einträgen sollte das auch mit der dämlichsten DB in weniger als 100ms zu machen sein. Richtig lustig wird es doch erst ab 10.000-100.000 Einträgen, oder wenn man viele (auch kleinere) Tabellen per JOIN miteinander verknüpft.

Das spricht nicht gegen die Verwendung eines Index, sondern soll einfach mal diese Frage beantworten.

[Alloc]

Also die AbsoluteDB ist definitiv nicht so langsam. Ich verwende die DB in einem größeren Projekt, bei dem eine Tabelle ~10k Einträge hat. Ein komplettes auslesen per

SQL-Code:

SELECT name, id, extension FROM ...

(2 * String + 1 * Integer) und Eintragen in ein Array of String dauert "nur" 0,5 Sekunden. Und gefilterte Abfragen (auch auf das String-Feld "name", ohne Index) dauern noch weniger lange.

Grüße,
Chris

[agm65]

cool, okay...dann mach ich was falsch ..ich schaus mir nochmal genau an. danke

[alzaimar]

Zitat:

Zitat von Alloc

Also die AbsoluteDB ist definitiv nicht so langsam. Ich verwende die DB in einem größeren Projekt, bei dem eine Tabelle ~10k Einträge hat. Ein komplettes auslesen per

SQL-Code:

SELECT name, id, extension FROM ...

(2 * String + 1 * Integer) und Eintragen in ein Array of String dauert "nur" 0,5 Sekunden. Und gefilterte Abfragen (auch auf das String-Feld "name", ohne Index) dauern noch weniger lange.

Grüße,
Chris

Die 500ms kommen eher von der Tatsache, das die Daten auch übertragen werden müssen. Bandbreite ist begrenzt, und bei einer angenommenen Größe von 10.000 Zeilen zu 50 Zeichen = 500kb dauert das eben auch ein paar ms (4MB max Traffic = 250ms + extra Overhead in der SW)...

Wie gesagt: Indexe bitte erst bei Tabellen > einigen Tausend Einträgen (prüfen, ist abhängig von der DB, CPU, RAM etc.)...

[Hansa]

Zitat:

Zitat von alzaimar

...Größe von 10.000 Zeilen zu 50 Zeichen = 500kb dauert das eben auch ein paar ms (4MB max Traffic = 250ms + extra Overhead in der SW)...

Wie gesagt: Indexe bitte erst bei Tabellen > einigen Tausend Einträgen (prüfen, ist abhängig von der DB, CPU, RAM etc.)...

Alzaimer traut sich lediglich nicht zu sagen, dass das DB-Design wohl für die Katze ist. :mrgreen:

Zitat:

Zitat von alzaimar

..Wie gesagt: Indexe bitte erst bei Tabellen > einigen Tausend Einträgen (prüfen, ist abhängig von der DB, CPU, RAM etc.)...

Dazu würde ich mal ergänzend sagen : zigtausend passt eher. :zwinker:

[mkinzler]

Es kommt darauf an, ob die Datenbank eher einfüge-/änder- oder abfrage-belastet ist, ob und wieviile Indizes man verwendet.

[Hansa]

Schon klar, aber in diesem Fall ist das irrelevant. Zigtausend Datensätze sind eher lächerlich.