Excel - OData-Abfragen beschleunigen

[HoneyBadger]

Hi,

kennt zufällig jemand eine Möglichkeit, wie ich Abfragen aus externen Datenfeeds beschleunigen kann? Früher habe ich das über Jet-Reports gemacht. Wenn man hier aber nicht direkt die SQL-Datenbank ansteuert, so wie wir das aktuell machen müssten, da sonst der Server in die Knie geht, dauert das ganz mindestens 30 min und länger. Je nachdem welche Tabelle man anspricht. Gilt aber auch schon bei kleinen Standardtabellen, die keine historischen Daten enthalten. Zum Beispiel die Kundenstammdaten.

Die Daten liefert unser ERP-System. Hierüber werden die Tabellen über WebServices zur Verfügung gestellt. Der schnellere Weg im Vergleich zu Jet geht über OData. Das läuft auch soweit ganz gut. Ich komme nur an meine Grenzen, wenn ich Abfragen erstellen muss, die auf mehrere teilweise sehr große Tabellen zugreift. Im Moment muss ich immer mal wieder Daten aus dem Artikelhauptbuch ziehen und diese mit anderen Tabellen verknüpfen, um dann entsprechende Auswertungen zu fahren. Problem ist nur, dass die Tabelle logischerweise tägl. größer wird, da dort alle Artikelbewegungen auflaufen. Für dieses Jahr sind da alleine weit über 100.000 Zeilen drin. Wenn ich im Query Editor vorfiltere, habe ich das Ergebnis zwar in der Auswertung eingeschränkt, aber dennoch wird jedes mal die komplette Datenbank durchwühlt. Kann man da evtl. eine Art Index drüber ziehen, sodass nicht immer alles komplett durchsucht werden muss oder muss man bei solchen Abfragen immer alles durchsuchen lassen?
Das kostet jedes Mal einige Minuten. Summiert sich schnell, wenn man hier und da mal feststellt, dass man eine Zeile zu viel/wenig hat oder man noch einen Filter mehr bräuchte usw. bis die Auswertung mal steht und jedes Mal irre große Abfragen laufen.

Ich hoffe, ich konnte es halbwegs verständlich erklären.

 

[drfuture]

Was für eine SQL-Datenbank ist es dann? MSSQL, Mysql?
Was meinst du damit das der Server in die Knie geht wenn ihr ihn direkt ansteuert und wenn ihr nun über die Webdienste geht läuft es?
Klar wenn der Webdienst so *lahm* ist das er die Daten nur langsam aus der DB sieht dann ist der DB-Server entlastet... dadurch dauert es dann ewig.

Nur sollten "einfache" DB-Abfragen den Server erst gar nicht in die Knie zwingen?

 

[HoneyBadger]

In

You do not have permission to view link please Anmelden or Registrieren

sieht man ganz gut, welchen direkt Weg ich meine. Müsste eine MSSQL-DB sein.

Mir wurde gesagt, dass wir nicht direkt an die SQL gehen können, da bei großen Abfragen das System ausgebremst werden würde, was das normale Arbeiten beeinträchtigen könnte.

Bei uns laufen Abfragen von JET über den WebService. Da dauert aber jede Abfrage ewig. Dazu ist Jet ziemlich blöd zu bedienen. Daher habe ich es mit OData-Abfragen probiert. Die laufen zwar auch über die WebServices, jedoch dennoch erheblich schneller. Zumindest in kleineren Tabellen. Bei großen DB braucht´s auch wieder eine Weile. In der Zeit geht dann nichts weiter.

 

[sia]

Wenn man nicht über Umwege geht, sondern direkt SQL-Abfragen bastelt, die man dann auf Laufzeit optimiert, ist das weitaus effizienter als das über Webservices zu erledigen. Ob man das direkt in Excel über ODBC oder über ein kleines Python-Script macht, ist Geschmackssache.

OData ist leider schlecht zu parallelisieren. Vielleicht redest du doch noch mal mit dem Verantwortlichen? Kann man den OData-Feed nicht irgendwie beschränken, dass nur die x letzten Transaktionen überhaupt drin stehen?

 

[HoneyBadger]

Man kann die Abfragen in der Tat beschränken. Man kann direkt im Query Editor z.B. über Datum >= XY gehen. Allerdings läuft, wenn man den Filter anwählen will, direkt ersteinmal eine ewig lange Abfrage vorweg. Später beim Laden habe ich das Gefühl (auf Grund der Zeit), dass dennoch alle Einträge einmal durchgelesen werden.
Inzwischen habe ich rausfinden können, warum die Abfragen (zumindäst später) immer länger gedauert haben. Gerade die riesen DBs haben gerne mal einen Timeout produziert, sodass man durchaus mehrmals abfragen musste, bis ein Ergebnis ankam. Nur hat der Server die Leichen dann nicht von sich abgestoßen, sondern bis ins Nirvana weitergerechnet. Das ging dann irgendwann zu Lasten der Performance.

 

[sia]

Dann rede mit dem DB-Admin, das kann ja nicht sein. Der soll mal seinen Scheiß fixen.

 

[drfuture]

Sorry war im Urlaub,
Also dein Problem ist unter Garantie der Webservice - und passende Querys dürfen den sql-server nicht ausbremsen - vor allem könnte man dir ja passende Rechte geben z.B. nur Views einzusehen die eine zu hohe Serverlast verhindern.

Möchtest du unbedingt mit diesen Jet-Tools arbeiten oder eigentlich "nur" in Excel?
Sonst - wenn du direkt auf die DB zugriff haben könntest dann kannst du dir auch

You do not have permission to view link please Anmelden or Registrieren

installieren - da ist ein MSSQL-Nativer Datenbank-Treiber dabei den du per ODBC / OLE in Access, Excel usw. direkt anbinden kannst.

Das dürfte das performanteste für excel sein.

 

[HoneyBadger]

Ich kann schon direkt an die DB. Entsprechende Rechte wurden mir eingeräumt. Auch ins ERP-System kann ich ziemlich tief rein. Das ist nicht das Problem. Ich glaube fast, dass die produzierten Timeouts bei mir mit einem anderen Problem (zumindest teilweise) zu tun haben. Das der Server sich nicht selbst aufgeräumt hat, hat dann wohl sein übriges dazugetan.

Ich persönlich möchte gar nicht mit Jet arbeiten. Wenn man Daten nur tabellenübergreifend nutzen muss, ist das manchmal Mittel der Wahl. Ich komme mit OData ganz gut klar. Läuft ODBC auch gut im Query-Editor?

 

[drfuture]

ODBC ist ja nur ein verallgemeinerungs-layer für div. Einstellungen der Verbindung und welche dll du als Treiber nutzen möchtest - daher sollte das gehen...
Wenn ich mit der DB arbeite was ich an sich recht häufig mache, mache ich das immer direkt im MSSQL-Datenbank-Studio ^^