C++ -> Datenbank
-
Hallo Forum,
hab mal nen paar grundsetzliche Fragen auf die ich mir hier Antworten erhoffe
Ich bin dabei ein Programm zu entwickeln das mehrere Datensätze einer Excel Tabelle mit jeweils allen Datensätzen einer Access Datenbank vergleicht.
Ich habe bisher mit ADO darauf zugegriffen. In der Access Datenbank befinden sich ca. 22000 Datensätze und ca. 500 in der Excel Tabelle. Für die notwendigen 500 * 22000 zugriffe benötigt das Programm ca. 2 Stunden.
Ziel ist jedoch die Laufzeit so gering wie möglich zu halten, weniger als 60 sekunden sind geplant.Jetzt zu meinen Fragen, was kann ich tun um den Zugriff zu beschleunigen??
1. Anstatt über die ADO mit C++ -> Access zuzugreifen teste ich den Zugriff mit C++ -> SQL -> Access. Ist hier eine optimierung der Zeit zu erwarten ??
2. Eine Alternative zu ADO zu finden ... welche Optionen stehen zur Auswahl, und welches ist die schnellste Möglichkeit ??
3. Um SQL effektiver zu nutzen könnte die Access Datenbank nach MYSQL portiert werden. Werden dadurch die Geschwindigkeiten von SQL -> SQL Datenbank im Vergleich zu SQL -> AccessDB optimiert ???
4. Alles was euch einfällt um die Zugriffe schneller zu machen ....
Danke für alle antworten und Anregungen ...
MFG Blade
-
Hallo,
ich musste auch mal 2 Tabellen mit einander vergleichen, jeweils ca. 13500 Datensätze. Diese Daten wurden mir aus einer Datenbank als Textfile zur Verfügung gestellt. Habe dann ganz einfach die beide Dateien geöffnet und Zeile für Zeile miteinander verglichen. Vielleicht hift es Dir.
-
Wie lange hat das bei dir gedauert ??
Bei 500 * 22000 Datensätzen braucht mein programm bisher ca. 2 stunden
Deutlich zu lange.
-
Hallo
- wie holst du die Daten
- wie vergleichst dusonst kann dir kaum jemand helfen
MfG
Klaus
-
Die daten liegen in Form von Excel Tabellen und einer Accessdatenbank vor.
Bisher. Wie ich sie einlese oder intern abspeicher ist mir überlassen, deswegen suche ich nach der schnellsten Möglichkeit. Die Daten aus der Excel Tabelle habe ich in einen vector gelesen (ca. 500 Datensätze) und mit den Datensätzen der Access DB verglichen (ca. 22000). Wie gesagt .... bisher ... so dauert das ganze ca. 2 stunden.
-
Hallo
sollte mit SQL deutlich schneller sein
pro Suchvorgang 1 SQQ Aufruf "SELECT * from yyy WHERE xxxx
mySQL sollt da auch um einiges schneller sein im Vergleich zu AccessMfG
Klaus
-
Reicht es dann Access als DB beizubehlaten und nur über SQL zuzugreifen oder soll ich einen richtigen SQL server aufsetzten??
-
Hallo
du kannst bei Access bleiben
(besser waere aber ein Umstieg auf mySQL oder aehnliches)
Ist aber abhaengig von dem Art des Programms (privat oder verkauf ... )MfG
Klaus
-
Access ist doch keine Datenbank ?!
Access bietet doch nur ein Frontend für den Zugriff/Visualisiertung von/auf eine(r) Datenbank, standardmäßig SQL.
Mit Frontend ist auch einfach eine selbstgemacht Applikation wir Kundenverwaltung gemeint.
liege ich da falsch ´?
Du kannst die SQL Datenbank einfach aus dem Accessprojekt exportieren und dann mit einem SQL Server und einer C Anwendung die daten vergleichen.
Eine Frage : Vergleichst du mit Hilfe von Fulltext - search ?
-
KlausB schrieb:
- wie holst du die Daten
- wie vergleichst dusonst kann dir kaum jemand helfen
666Blade[DC]666,
das waren bestimmt keine rhetorischen Fragen.
Es könnte (in Abhängigkeit von Deinen Daten) z.B. sein, daß ein einfacher Join Dein Problem in 2 Sekunden löst, denn 22000 Datensätze sind überschaubar. Aber wenn Du nicht mehr Informationen rausrückst können wir nur herumrätseln.666Blade[DC]666 schrieb:
Reicht es dann Access als DB beizubehlaten und nur über SQL zuzugreifen oder soll ich einen richtigen SQL server aufsetzten??
Tja, das hängt halt von Deinen Daten ab. Beim SQL Server (oder der MSDE als kostenlose und für Deine Zwecke gleichwertige Variante) sollte man aber schon Performance-Vorteile gegenüber Access erwarten können.
-
Ich habe einerseits eine Liste mit 22.000 Rohstoffen, wo jeweils die benötigte Anzahl für bei steht. Zusätzlich ist die jeweilige Fertigprodukt nr. dabei.
Ein fertigprodukt besteht aus 4- 7 Rohstoffen. Wo bei von dem einen z.b 1 stück verwendet werden, von anderen 3 und von fetten z.b. auch 0,27g.In einer anderen Tabelle sind die Fertigprodukte deklariert mit gesamtstückanzahlen.
Meine Methode ging bisher mit jeweils einer Nummer des Fertigproduktes aus der 2ten tabelle in die erste und verglich die nummern. Bei übereinstimmung wurden die Rohstoffnummern vermerkt mit anzahl * gesamtstückzahl.
Danach erfolgte ein zweiter durchlauf, bei dem doppelte rohstoffe addiert werden, um so die gesamtanzahl der benötigten mengen eines rohstoffes zu erhalten.
Wie gesagt das ganze war nur ne notlösung weils wirklich dringend war.
Das ganze könnte man mit ner ausgeklügelten SQL anweisung lösen, is mir klar, aber meine frage bleibt. Lohnt es sich einen extra DB Server für SQL oder MYSQL aufzusetzen? Da ich das programm lokal am arbeitsplatz ausführen will wäre ein extra server nich sehr sinnvoll. Nur wenns wirklich nicht anders geht.Access kann doch auch als Front und Backend genutzt werden. Die Struktur lässt sich doch auch in SQL umwandeln basiert doch aber nicht auf SQL oder ?? Naja egal. Was ich meinte war, gibt es keine Möglichkeit eine SQL oder my SQL basierende datenbank kurzzeitig lokal zu emulieren mit c++, damit ich das programm ausführen kann, auf jedem rechner ohne vorher nen apache oder microsoft sql server zu installieren ??? Ähnlich wie ich halt mit c++ über ado auf access zugreife ... ?????
-
Hi ZahlDesTiersKlinge[Gleichstrom]ZahldesTiers (sorry ist mir so aus den Fingern geflossen ;)),
so ganz klar ist mir das Problem nicht geworden... Für eine Stücklistenauflösung hier benötige ich nur wenige Millisekunden, mit einem normalen SQL-Select...
Bei Access läßt sich meist viel an Geschwindigkeit herausholen wenn die Verbindungseinstellung von clUseClient auf clUseServer geändert wird.
Eine weitere Alternative zu Access wäre noch Local ADS (Advantage Database Server), der in der lokalen Version m.E. ebenfalls kostenlos ist.Weitere Hilfe können wir Dir nur geben, wenn Du die Problembeschreibung ein bißchen aufpolierst. Insbesondere eien genauere Tabellenbeschreibung wäre sinnvoll.
Die Probleme Dein Problem zu verstehen beginnen hier:
...wo jeweils die benötigte Anzahl für bei steht...
Außerdem verstehe ich Deine Differenzierung zwischen ADO und SQL nicht. ADO ist eine Zugriffsweg (Alternativen: ODBC, OLE-DB und auch die alte BDE). Aber bei allen diesen Zugriffswegen verwendest Du als Sprache SQL (Structured Query Language).
-
Hallo,
22.000 Datensätze sind sicherlich kein Problem für Access. Trotzdem würde auch ich Dir empfehlen die kostenlose MSDE aus dem Netz zu laden und Dich damit zu beschäftigen, denn die ist unverhältnismäßig schnell. mySQL ist dagegen nicht unbedingt schneller als Access in einer Einplatzumgebung (achso, natürlich hat Access mit der JET- Engine auch ein Datenbank- Backend, wenn es auch nicht besonders leistungsfähig ist).Ich würde an Deiner Stelle die 500 Datensätze beim Programmstart in die SQL - Datenbank schaufeln, und dann die Auswertung komplett via SQL zu machen. Excel- Zugriffe sind nicht sonderlich schnell, im Vergleich zum DB- Server, und lassen sich nicht indizieren.
Allerdings hast Du auch ein irres Design- Problem in Deiner Datenbank, die dazu führt, dass Du jedes Programm quälst. Du hast Fertigprodukte und Rohstoffe, in Deinem Fall sind das jeweils eigenen, unabhängige Entitäten, also jeweils eine eigene Tabelle. Die stehen in einer m:n- Beziehung (jedes Produkt verwendet 1 ... n Rohstoffe, jeder Rohstoff kann in 1 .. m Produkten vorkommen). Beim Umsetzen in der Datenbank macht man daraus eine eigene Tabelle, in dieser steht neben den jeweiligen Schlüsseln des jeweiligen Fertigprodukts und Rohstoffs auch die notwendige Anzahl. Du brauchst also drei Tabellen. Wenn Du das ganze so auflöst, wird die MSDE mit der geeigneten SQL- Anweisung die Aufgabe für Dich in wenigen Sekunden lösen, wenn die Indizes richtig sind.
Schöne Grüße aus Berlin
Volker
-
Hi Volker,
es ist noch die Frage, ob mehr als eine Tabelle überhaupt Sinn macht. In unserem PPS-System sind Endprodukte und Rohstoffe in einer Tabelle organisiert. Hintergrund dafür ist, dass ein 'Rohstoff' durchaus auch mal ein 'Endprodukt' sein kann - je nach Betrachtungsweise. Wir haben z.B. Baugruppen, die intern als 'Endprodukt' gefertigt werden, die dann allerdings eine weiteren Baugruppe oder ein 'echtes Endprodukt' einfliessen.
Der Vorschlag die Exceldaten in die DB zu laden ist prinzipiell korrekt. Unter Umständen ist es aber nicht nötig. Wenn die Exceltabelle als Basis gesehen werden kann, reicht es eventuell für jeden Eintrag in der Exceltabelle eine SQL-Abfrage auf die DB auszuführen. Der Performancevorteil gegenüber einer reinen DB-Lösung ist dann nicht mehr gegeben, respektive ist nur minimal.
-
Hallo Joe,
mit dem Datenbankdesign ist es so eine Sache, ich kenne einige Profis, die predigen, dass eine Normalisierung und eine korrekte Abbildung nicht notwendig sind. Meistens nennen sie sich dann auch "Praktiker". Allerdings habe ich auch schon sehr viele Projekte scheitern sehen, weil diese dann das Ruder in der Hand hatten und sich die Anforderungen etwas geändert haben. Genauso ist es mit dem "Übernormalisieren". Aus meiner Erfahrung kann ich aber nur sagen, dass eine unstimmiges Modell bei größeren Datenmengen zu Performanceproblemen führt.Auch wenn es an der ursprünglichen Frgae vorbeigeht. Obwohl, eigentlich ging es ja um Performancesteigerung, und bei einer Datenbank kann man sicherlich viel durch das Verwaltungssystem und die Hochrüstung von Hardware erreichen, aber wenn das Modell nicht stimmt, geht auch ein S/390 in die Knie.
Es ist sicherlich möglich, Rohstoffe und Fertigprodukte in eine einzige Tabelle zu schreiben, wenn Sie über gleiche Eigenschaften verfügen. Nur sollten dieses keine Vereinigungsmengen sein. Rohstoffe kauft man in der Regel ein, Fertigprodukte verkauft man, er Einkauf braucht andere Informationen, als der Verkauf. Damit sollten sich in einem echten PPS- System um diese Tabelle sehr viele Detail- Tabellen gehören. Was bleibt ist die Beziehung, welcher Rohstoff in welches Produkt in welcher Menge einfließt, der in eine eigene Tabelle gehört. Auch hier hat mir mal ein "Praktiker" versprochen, zu einer Leistung werden maximal 3 Teilleistungen gebündelt, angeblich ginge es gesetzlich sogar nur so. Ich sollte aufhören, "querzudenken", und diese Leistungen horizontal in der Tabelle anordnen, somal es einfacher ist, eine nichtnormalisierte Tabelle auszuwerten. Nach dem das Programm zu 75% fertig war, kam der erste Nutzer, und hatte 4 Leistungen, dann kam einer mit 5, schließlich stellte es sich heraus, dass es keine Beschränkungen gab.
Zu deiner Idee mit den Transaktionen. Es ist für den Server um ein vielfaches schwieriger, die aufeinanderfolgenden Transaktionen zu verarbeiten, somal man gerade (aber nicht nur) im Mehrnutzerbetrieb davon ausgehen muss, dass bestimmte Detaildaten dann mehrfach gelesen werden, da der Server bei Beginn der Verarbeitungen nicht weiss, was noch von ihm verlangt wird. Irgendwann verwirft er dann eventuell im Hauptspeicher geladenen Seiten, um Platz für andere Transaktionen zu haben. Es ist also mit Sicherheit die falsche Entscheidung. Ausserdem darf man die Veränderungen während der Verarbeitung nicht vergessen, wenn also ein anderer Nutzer während Deiner 500 Teilverarbeitungen etwas verändert, gibt es ein falsches Ergebnis, es sein denn, Du packst alle Anforderungen in eine Transaktion, dann hat der Server aber zu kämpfen.
Schöne Grüße aus Berlin
Volker
-
Hallo Volker,
offenbar schreiben wir aneinander vorbei...
Natürlich stehen nicht alle Daten in einer einzigen Tabelle. Die Artikeldaten teilen sich auf etliche Tabellen auf. Die Stammdaten stehen in einer Tabelle. Dort wird auch festgelegt, ob der Artikel ein EK-, oder VK-Artikel (oder nur eine Baugruppe ist). Dazu gibt es dann noch entsprechende Tabellen in denenn die zusätzlichen Daten für die Bereiche festgehalten werden.
Allerdings ist die Stückliste der Artikel in einer einzige Tabelle untergebracht. In dieser Tabelle ist es irrelevant, ob ein Artikel ein Endprodukt, eine Baugruppe oder ein EK-Artikel ist. In dieser Tabelle wird nur definiert, aus welchen anderen Artikeln sich ein Artikel zusammensetzt. Im Prinzip läßt sich die Tabelle auf Endprodukt-Artikel-ID, Pos, Einsatz-ArtikelID, Menge, Mengeneinheit reduzieren. Man filtert also nach der Endprodukt ArtikelID und erhält die erste Stufe der Einsatzartikel, diese Einsatzartikel können dann wieder Endprodukt ArtikelIDs sein und müssen möglicherweise weiter aufgelöst werden (gibt es sogar ein Flag für). Somit läßt sich das Ganze beliebig tief schachteln. Na gut, ich gebe zu, dass es zu dieser Tabelle noch eine Kopftabelle gibt. Aber diese ist nicht unbedingt notwendig, sie dient nur der Geschwindigkeitssteigerung. Allerdings sehe ich bei nur 22000 Stücklistenpositionen keine Notwendigkeit für eine solche Kopftabelle (in unserer DB befinden sich knapp 1 Million solcher Stücklistenpositionen).
-
@joe
kopfdaten? was du beschreibst ist doch eigentlich die beziehungstabelle zwischen den fertigprodukten und den Rohstoffen, genauso wie ich es angeregt hatte, und du schreibst selber, das die artiekldaten in einer anderen tabelle stehen. bei euch ist der fall, dass bestimmte baugruppen wieder als "Rohstoff" in einem neuen Produkt verwendet werden, was aber an dem modell nicht viel ändert. warum behauptest du dann, mit einer tabelle auszukommen? diese stammdaten (ich hoffe du meinstest damit nicht die "kopfdaten" (die Du als nahezu überflüssig siehst)) sind die eigentlichen Entitäten. die "stückliste ist die beziehung. für euer pps-system hoffe ich also, dass du das modell einfach nicht verstanden hast, und etwas schnell geredet hast. man kommt nämlcih nicht mit einer tabelle aus. nehmen wir mal an, zu jedem Produkt gibt es neben der id, über den es direkt angesprochen wird, eine kurzbezeichnung, eine ausführliche beschreibung und einige andere informationen (vielleicht noch ein bild). eigentlich keine ungewöhnliche herangehensweise. ausserdem handelt es sich ja bei der id meistens um einen semantischen schlüssel, oft enthält er auch buchstaben, und dient dazu, das produkt von aussen abzufragen. diese id kann sich also ändern und ist als char- feld meistens etwas länger, müsste aber in vielen anderen tabellen als fremdschlüssel benutzt werden. das heisst, die datenbank wird regelmäßig vergewaltigt, ausserdem kann solche operation auch nach hinten losgehen. ich habe bei einer größeren firma mal erlebt, dass so eine "nebensächlickeit" mehrere millionen gekostet hat. also sollte es einen internen schlüssel als tatsächlichen primary key geben. nun darf jede externe id nur einmal vergeben werden, also definiert man ihn als unique. du musst aber bei deinem ansatz diese mehrfach in deine "eine" tabelle speichern, also hast du weder einen primärschlüssel für ein produkt / rohstoff, noch kannst du mit unquie- key arbeiten. was aber zwangsläufig bedeutet, dass du keine referenzen auf die tabellen mit den ek's und vk's und was dir noch so als detail einfällt bilden kannst. also schlecht, dann solltest du die daten vielleicht besser in textdateien speichern.wenn du bei deinem ansatz jetzt die beschreibung ändern will, und das produkt verwendet 20 rohstoffe, dann muss ich diese 20 mal ändern, ausserdem die verschwendung des speicherplatzes.
minimale zeitersparnis? die datenbank speichert alle informationen in seiten ab (1K, 2K, ...), in der regel werden immer ganze seiten gelesen. wenn ein satz länger als eine seite ist, wird es eh böse, aber ansonsten ist die frage, wieviel sätze ein programm in einer seite hat, sehr entscheidend für die performance. und auch wenn du filterst, muss die datenbank die ganze seite lesen, und liefert dann nur die selektierten sätze zurück (ich hoffe, du filterst nicht erst in der vcl das dataset, sondern selektierst schon über den sql- befehl. manchmal hilft es, sich zu überlegen, was eine datenbank tatsächlich mit den daten macht
schöne grüße aus berlin
volker
-
Hallo Volker,
na ja, so wie ich die Aufgabenstellung verstanden habe geht es um eine reine Stücklistenauflösung und das kann ich in unserem System über eine einzige Tabelle erledigen. Ich kann weitere Tabellen verwenden um mehr Informationen zu erhalten (eben, ob ein Teil ein Einkaufs- oder Verkaufsartikel ist, Einkaufspreise / Konditionen, Verkaufspreise, Umsatzmengen, Informationstexte, Artikelbezeichnungen, Beschaffungs- oder Fertigungszeiten, Arbeitspläne usw.). Aber für die Summenbildung der ist das irrelevant. Bei einer Dispositionsplanung sieht das schon wieder ganz anders aus. Hier komme ich dann nicht mit dieser einen Tabelle aus.
Zu der Kopftabelle: Diese Tabelle enthält die Informationen, die pro Stückliste nur einmal vorhanden sind (Stücklistenname, zugehöriger Arbeitsplan, Erstelldatum, Änderungsdatum usw)
-
@666Blade666
Ich hab letztens gesehen, als ich eine Access Datenbank unter ODBC verfügbar machen wollte, daß das auch für Excel- Tabellen möglich ist.
Dann kannst Du diesen Bereich in der Excel-Tabelle auch als Datenbank ansprechen. Schau mal in der Excel-Hilfe nach inwieweit Du Namenfelder/Namensbereiche festlegen kannst, die dann unter ODBC ansprechbar sind.
Auf jeden Fall kann ich bei mir Excel-Dateien als ODBC-Datenbank einfügen.
Diese sind dann auch (vorrausgesetzt Namenfeld/bereich sind festgelegt)
als ODBC Datenquelle ansprechbar. hoffe ich konnte helfenHermie