AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Tabellen für viele kleine Datensätze optimieren
Thema durchsuchen
Ansicht
Themen-Optionen

Tabellen für viele kleine Datensätze optimieren

Ein Thema von Medium · begonnen am 9. Jul 2014 · letzter Beitrag vom 10. Aug 2014
 
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#34

AW: Tabellen für viele kleine Datensätze optimieren

  Alt 10. Jul 2014, 20:43
Ist es da besser einen kombinierten Index auf vdate und valueID zu legen, oder jedes Feld seinen eigenen? Oder gar beides? Welche Art von Index eigenet sich hier? (Beide Felder sind für sich genommen non-unique, in Kombi aber unique.) Mein MySQL Tabellen-Tool bietet mir hier die Optionen:
Index Kind: Index, Primary, Unique, Fulltext, Spatial
Index Type: Default, BTree, Hash, RTree
Ich habe mich bisher schämlich wenig damit befasst, welche Index-Arten für welche Fälle geeignet sind
Ich würde es mit getrennten Indizes machen. Das ist flexibler. Ein kombinierte Index greift u.U. nicht, wenn weitere Bedingungen ins Spiel kommen.
Die uniqueness kannst Du separat per constraint definieren. NOrmalerweise tuen RDBMS einem den "Gefallen" abhängig vom Constraint direkt auch einen Index zu bauen, aber das kann man unterbinden, löschen, ändern.

Aber bei vielen Daten ist ein View doch auch nicht so gut, wenn er erst stundenlang rumrechnen würde, bei jeder Abfrage.
Das kann man pauschal nicht sagen. Ein View ändert per se nichts an der Abfragegeschwindigkeit.
Ausnahme wäre bspw. wenn ein Abfrage Paramter besser "innerhalb eines Views" aufgehoben ist, weil er dort eine größere Selektivität entfaltet (stärkere Datenreduktion bringt, Folgekosten spart, ..)

Jetzt machst du mich aber spontan unglücklich,
..
Bei Views wüsste ich jetzt nicht so genau, wie ich die Anforderung erfüllen sollte, die in dem längeren Kommentar beschrieben ist. Und Views werden doch auch dynamisch ausgeführt oder? Die Abfrage auf die originalen "feinen" Daten würde damit ja trotzdem nötig werden. Zwar dann verdichtet über's Netzwerk gehen, aber der Server hätte dennoch die volle Arbeit zu tragen. Bin da skeptisch.
Ein Materialized View, der für kumulierte Daten verwendet werden könnte ist m.E. auch nicht unbedingt effizient. Kommt drauf an, wie das Refresh arbeitet. In Deinem Fall ist klar, es müssen immer nur Daten nachgetragen werden, nicht eine ganzer Mat.View refreshed werden.
Das kann man auch gezielt je Tag oder so manuell in eine eigene Tabelle kippen. Falls dort Indizes definiert sind, dann eben die Indizes disablen und nachher wieder aktualisieren, ist etwas schneller.
Gruß, Jo
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:41 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz