Smalltalk Guten Morgen, Guten Tag, Guten Abend Kaffeeklatsch
#177061
geschrieben 05. Juli 2017 - 19:58
Anzeige
#177062
geschrieben 05. Juli 2017 - 20:19
Normal hab ich foobar2000 am laufen und laß den WASAPI Exclusive nutzen. Dann kann kein anderer auf die Saundkarte zugreifen. Aber momentan hab ich grad Stille und also blockiert auch nix. Vielleicht sollt ich ne MP3 nehmen mit 1min an Stille und die auf Endlos laufen lassen?
#177063
geschrieben 05. Juli 2017 - 20:56
Zitat (RalphS: 05. Juli 2017 - 20:19)
mach lieber 2 Minuten, die hält dann doppelt so lange. Das hat ja alles nicht mehr die Qualität von früher. Lieder auf Schallplatte waren damals zum Beispiel auch viel länger in den Charts als heute als mp3.
#177064
geschrieben 05. Juli 2017 - 21:45
Und in der aktuellen Situation heißt das für mich eher, je weiter oben desto scheiße.
Aber guter Hinweis. Ich werde mir die Minute an Stille in Schallplatte konvertieren.
#177065
geschrieben 06. Juli 2017 - 20:36
Einfach den Ordner mit der Qt-Installation umbenennen, damit das System »denkt«, die gibt es nicht. (und sich die DLLs nicht aus der Qt-Umgebung holt)
dann einen Ordner anlegen,
die Anwendung rein,
ALLE in Frage kommenden DLLs rein,
ALLE Unterordner aus dem Plugins-Ordner rein,
die Anwendung starten und bei laufender Anwendung alle DLLs und Ordner löschen, wobei alle die sich nicht löschen lassen zu überspringen sind.
Alles was benötigt wird bleibt übrig - fertig.
#177066
geschrieben 06. Juli 2017 - 20:42
Sollte erstmal funktionieren, könnte aber ggf trotzdem noch irgendwo hängen. Besonders, wenn Du erst irgendwo im Programm selber irgendwelche DLLs nachladen läßt oder ggf auf dynamisch bereitgestellte Funktionalität zugreifen solltest.
Halt also ggf noch ein Auge drauf. Oder sag den Benutzern, daß sie das an Dich zurückmelden sollen, fals irgendwas nicht hinhaut.
#177067
geschrieben 06. Juli 2017 - 21:03
Ansonsten habe ich zum Testen ja meine beiden blanken Systeme, seit ich das mit der VM endlich hingekriegt habe. Da prüfe ich auch immer nochmal gegen.
Dieser Beitrag wurde von Holger_N bearbeitet: 06. Juli 2017 - 21:04
#177068
geschrieben 07. Juli 2017 - 08:39
Nun sucht man hellgrüne Äpfel. Macht es mehr Sinn zuerst nach Äpfeln zu suchen und dann nach der Farbe, also:
SELECT * FROM obstkorb WHERE obst=apfel AND farbe=hellgruen ;
weil es nur zwei Obstsorten gibt und man dann grob vorselektiert und in der kleineren Menge der Äpfel nach Farben sucht oder macht es mehr Sinn erst nach der Farbe zu suchen und dann nach dem Obst, also
SELECT * FROM obstkorb WHERE farbe=hellgruen AND obst=apfel ;
weil man dann bei der zweiten Bedingung nur noch einen ganz kleinen Pool hat oder ist die Reihenfolge für die Abfrage egal?
In dem Beispiel ist es vielleicht nicht ganz so relevant, aber mal angenommen es gäbe ganz wenige Obstsorten und ganz viele Farben.
#177069
geschrieben 07. Juli 2017 - 10:31
SQLite... da ist das immer so ne Sache.
Du kannst mit SQLite vor eine Abfrage immer "EXPLAIN QUERY PLAN" davorschreiben. Also in dem Fall
EXPLAIN QUERY PLAN SELECT * FROM obstkorb WHERE farbe=hellgruen AND obst=apfel;(plus andersrum).
Normal wäre zu erwarten, daß beide Abfragen denselben Abfrageplan haben. Da spielt unter anderem mit rein, wieviele Datensätze jeweils die Tabellen haben, aber auch, ob ggf ein Index da ist und verwendet werden kann.
Ich geh mal davon aus, daß das bei Dir relativ wenig Datensätze sind. Wenn es aber viele sind (oder werden können) und Abfragen nach Obst auf Obsttyp und Farbe üblich sind, dann kannst Du einen Index erstellen, entweder über eine der beiden Spalten oder über beide zusammen.
Mehrspaltige Indices sind dann geordnet in der Reihenfolge der definierten Spalten und Du kannst Deine Abfrage danach ausrichten. Ein Index (obst, farbe) ist nicht dasselbe wie ein Index (farbe, obst). Für ein "WHERE farbe = X" kann die erste Variante nicht verwendet werden, weil "obst" nicht bekannt ist und obst aber den Index primär bestimmt.
Entsprechend sind wenigerspaltige Indices flexibler, mehrspaltige Indices performanter für eine spezifische Abfrage. Demgegenüber sind letztere größer als erstere. Außerdem werden durch Indices Einfügeoperationen gebremst und alle Schreibvorgänge (INSERT,UPDATE,DELETE) lassen einen Index verkümmern, sodaß dieser immer mal neu erstellt werden muß.
Weniger ist hier also mehr. Je weniger Datensätze in einer Tabelle, desto alberner wird ein Index dafür. Dasselbe gilt auch für nicht-eindeutige Spalten: Wenn man in seinem Obstkorb 100 Obst hat und 99 davon sind Äpfel, dann bringt ein Index auf die Spalte "obst" überhaupt nichts; andersherum, wenn von 100 Obst 99 verschiedene Obstsorten sind, dann wäre das für einen Index mehr oder weniger perfekt. Für die Farben gilt das analog. Wenn die sich auf "rot", "grün" und "schweinchenrosa" beschränken, ist ein Index dafür nutzlos.
Hinweis, für so eine Zuordnung sind ggf drei Tabellen sinnvoll: eine Tabelle Obst mit (oid, name, <obstinfospalten>), eine Tabelle Farbe mit (fid, name, <farbinfospalten>) und eine Tabelle Obstkorb mit (oid, fid, <korbinfospalten>).
Dieser Beitrag wurde von RalphS bearbeitet: 07. Juli 2017 - 10:36
#177070
geschrieben 07. Juli 2017 - 11:46
in der zweiten Tabelle die konkreten Einzelnamen aller Früchtchen
in der dritten alle möglichen Farben
und in der vierten Tabelle ist der tatsächliche Bestand nur über die IDs der anderen drei Tabellen zusammengstellt.
Das war das, wo ich neulich mit den Fremdschlüsseln experimentierte, dass ich beispielsweise sagen kann, alle Birnen fliegen aus dem Programm und ich lösche »Birne« aus der Obstsortentabelle und aus den Tabellen der Früchtchen und aus der Zusammenstellung fliegen alle Birnen automatisch raus. Allerdings verliert man da schnell den Überblick und wenn ich dann drei Wochen später den Fremdschlüssel wieder vergessen habe, sehe ich am Code nicht mehr was gelöscht wird.
#177071
geschrieben 07. Juli 2017 - 12:41
Da würd ich einen VIEW drauf setzen. Dann geht das einfacher abzufragen.
ZB so:
CREATE VIEW v_obstkorb AS SELECT n.name AS obst_name, s.name AS sorte, f.name AS farbe FROM obstkorb AS k JOIN obstname AS n ON k.name_id = n.id JOIN obstsorte AS s ON k.sorte_id = s.id JOIN obstfarbe AS f ON k.farbe_id = f.id;
Wenn Du was anderes als SQLITE verwendest - zB Access -- müßtest Du schauen, ob Funktionen unterstützt werden. SQLITE kann das noch nicht (wenn sich das nicht inzwischen geändert haben sollte). Dann könntest Du mit sowas wie CREATE FUNCTION get_obst(varchar, varchar) RETURNS TABLE eine Funktion definieren, die Farbe und Obstsorte übergeben kriegt und die dann eine Tabelle zurückgibt mit den passenden Einträgen.
Wenn Du jetzt viele Datensätze haben solltest, könntest Du in den jeweiligen Tabellen für jede Spalte "name" einen Index draufsetzen. Die JOINs laufen über den Primärschlüssel; der ist automatisch indiziert.
Auch dann ist am Ende völlig egal, wie rum Du Die Abfrage bastelst. Note: Schreiboperationen gehen auf VIEWs nicht, nur SELECTs. Einfügeoperationen müßtest Du per Transaktion über alle beteiligten Tabellen direkt anweisen.
#177072
geschrieben 07. Juli 2017 - 15:54
Da ist garantiert noch irgendwo Optimierungspotential.
und… während ich das Tippe habe ich schon eine Idee.
Wobei sich mir der Sinn von CREATE VIEW nicht erschließt.
Dieser Beitrag wurde von Holger_N bearbeitet: 07. Juli 2017 - 16:20
#177073
geschrieben 07. Juli 2017 - 16:44
Index macht Binärsuche möglich. Ohne ist das linear. Bei einem ordentlichen Index und 1 Million Datensätzen und einer Prüfdauer von 1s pro Datensatz (ist natürlich weniger, nur der Anschaulichkeit halber:
- Ohne Index: 1'000'000 Records x 1s / Record => 1'000'000s / Abfrage <=> 277 Stunden (mehr oder weniger exakt)
- Mit Index: 1'000'000 Records bei log(2) 1'000'000 s => 20 Sekunden / Abfrage (exakt)
Ohne Index weiß die DB nicht, ob der Eintrag einmal oder X-mal da ist. Also müssen alle Datensätze angeschaut werden.
Mit Index ist die bewußte Spalte... eh... indiziert, hat also ein Inhaltsverzeichnis. Außerdem ist sie sortiert. Heißt, wenn man mit Index suchen kann, dann kann aus dem Index der Schlüssel in logaritmischer Zeit rausgefischt werden und weil der Index sortiert ist, ist auch bekannt, daß bestenfalls ein Fenster von n-k Ergebnisdatensätzen da sein KANN.
Schau mal nach, ob Du ggf Abfragen zusammenfassen kannst. Das beschleunigt.
VIEWs dienen einmal der Sicherheit, weil sie Tabellen vor dem Benutzer verstecken (und man dem VIEW andere Berechtigungen geben kann als den Tabellen) der Einschränkung (weil man im VIEW von X Spalten nur X-n Spalten reinnehmen muß) und der Bequemlichkeit (weil ein VIEW letztlich nichts als ein gespeichertes SELECT ist).
Im Beispiel oben würde man deshalb mit
SELECT * FROM v_obstkorb WHERE obst_name = 'Fritzi' AND sorte = 'Apfel';
den Namen, die Sorte und die Farbe für alle Äpfel namens Fritzi bekommen, ohne irgendein JOIN und ohne sich überlegen zu müssen, was für Spalten in den drei Tabellen dahinter vielleicht dazugekommen sein könnten.
Dieser Beitrag wurde von RalphS bearbeitet: 07. Juli 2017 - 16:46
#177074
geschrieben 07. Juli 2017 - 18:26
Aber irgendwie scheint es kein Pedant zu »REPAIR table … « und »OPTIMIZE table …« für Access zu geben.
#177075
geschrieben 07. Juli 2017 - 21:35
Müßtest Du mal in der MySQL-Doku schauen, was das Optimize macht. Gut möglich, daß das so für Access überhaupt nicht zutrifft. Ich hab das bisher noch nirgendwo gebraucht.