Hallo Zusammen Ich habe ein Leitsystem mit einer M-CPU und max. 16 IO-Baugruppen entwickelt man spricht bei dieser Zusammenstellung von einer Komponente und ich werde für mein Vorhaben in etwa 20 Komponenten benötigen. Um diese Anlagen parametrieren zu können habe ich ein Tool in C# geschrieben und eine Access (2013) Datenbank für die Parameter verwendet. Aber leider habe ich den Umfang der Datensätze unterschätzt und bei 20 Komponenten komme ich ca. auf 350000 (dreihundertfünfzigtausend) Datensätzen in der Parameter-Tabelle und da gehen einige Funktionen sehr zäh. Bei zwei Komponenten in der Datenbank habe ich eine Funktion die ca. 15 Sekunden benötigt und mit 20 Komponenten habe ich sie nach 7 Minuten abgebrochen will ich dachte das sich der PC aufgehängt hat. Ich verwende reader = cmd.ExecuteReader(); und cmd.ExecuteNonQuery für die Bearbeitung der Datensätze. Macht es Sinn auf eine andere Datenbank umzusteigen oder welche Möglichkeiten habe ich um die Laufzeit der Datenbankbearbeitung brauchbar zu gestallten? Bitte um eure Hilfe. Danke. Lg. Johann K.
Indexe für alle oft benötigten Queries hast du angelegt? 350k Einträge sollten für keine Datenbank ein Problem darstellen.
indices auf felder in where-bedingungen. falls ms sowas unterstützt: b-tree auf felder mit hoher kardinalität, bitmap auf solche mit niedriger. ohne indices hast du bei jeder abfrage full table scans. wobei ich mssql nur als "schlechte datenbank", bzw. schlecht entwickelte frontends kennegelernt habe - ich komme eigentlich aus der oracle ecke mit ein wenig rumspielerei mit mysql/mariadb.
Klatec schrieb: > und eine Access (2013) Datenbank für die Parameter > verwendet. wenn ihr Access wirklich nur als DB nutzt, dann würde ich vorschlagen auf MS-SQL zu wechseln. Bis 2GB Datenbank ist es kostenlos, ist ein Datenbanksystem was sehr gut skaliert und nicht bloss ein Treiber wie bei Access, wo es nicht mal einen wirklichen Prozess gibt. Wir haben dort weiter mehr als 500.000.0000 Einträge in einer Tabelle und es geht flott.
Es gibt zu sicherlich jeder Datenbank Texte über die Optimierung von Abfragen und die Gestaltung der DB hinsichtlich Indizes. 350k Einträge sind recht wenig, aber ohne Index, aber dafür umfangreicher Bestückung mit teuren Funktionen im WHERE. zwingt man eine DB trotzdem in die Knie.
:
Bearbeitet durch User
c.m. schrieb: > wobei ich mssql nur als "schlechte datenbank", bzw. schlecht entwickelte > frontends kennegelernt habe Yep. Webentwickler und Datenbanken sind oft wie Hund und Katz. ;-)
Klatec schrieb: > [...] und eine Access (2013) Datenbank für die Parameter > verwendet. [...] > Macht es Sinn auf eine andere Datenbank umzusteigen? Ja. fast egal welche, nimm was dir am besten passt. Selbst sqlite wird besser performen.
A. K. schrieb: > Es gibt zu sicherlich jeder Datenbank Texte über die Optimierung von > Abfragen und die Gestaltung der DB hinsichtlich Indizes. 350k Einträge > sind recht wenig, aber ohne Index, aber dafür umfangreicher Bestückung > mit teuren Funktionen im WHERE zwingt man eine DB trotzdem in die Knie. ja, das kann ACCESS auch. Aber das dumme an ist, das es keinen Serverprozess gibt. Der Treiber ist die Datenbank und öffnen die Datei direkt. Sobald ein paar mehr Leute die DB nutzen, muss die ganze Synchronisierung übers Dateisystem laufen. Auch muss jeder Treiber die Daten selber cachen weil es kein gemeinsamen ram gibt. Ein Wechsel auf mssql sollte um unproblematischsten sein, weil beide doch ein paar Ähnlichkeiten haben. Bei MySQL und Postgresql könnte das etwas mehr aufwand sein. Und da es eh C# ist, passt doch ein MS-Datenbank recht gut dazu. Dort kann man dann sogar sehr effiziente Bulk-Operationen nutzen.
c.m. schrieb: > wobei ich mssql nur als "schlechte datenbank", bzw. schlecht entwickelte > frontends kennegelernt habe - ich komme eigentlich aus der oracle ecke > mit ein wenig rumspielerei mit mysql/mariadb. meinst du jetzt ACCESS oder MSSQL? MSSQL ist schon ein guten DB-System. Mich nervt Oracle da schon viel mehr, da geht alles irgendwie umständlich.
Hallo Planlos Ich tu mir etwas schwer dich mit Planlos anzusprechen wenn da wer planlos ist bin das sicher ich. Nein ich habe keine Indexe angelegt ich habe schon davon gelesen aber bei den Datenbankanwendungen die ich bisher gemacht habe war die Zugriffszeit kein Thema und daher habe ich mich damit nicht beschäftigt. Wie du schon bemerkt haben wirst bin ich jetzt nicht der große Programmierer und danke dir für deinen Tipp. Ich werde versuchen diesen umzusetzen. Schönen Abend. Johann K.
Peter II schrieb: > MSSQL ist schon ein guten DB-System. MS SQL ist völlig ok, insbesondere innerhalb der Limitierungen der kostenlosen Version (Express?). Ist halt ein etwas grösserer Klops auf der Platte als MySQL und wenn man irgendwann doch die Limitierungen überschreiten sollte, dann wärs besser, wenn man sich über die Lizenzierung vorher Gedanken gemacht hat. Zu beachten ist, dass bei der Grössenbeschränkung meiner Erinnerung nach die Transaction Logs mitgerechnet werden. Wenn man ausgiebig modifiziert und mit vollem Logging arbeitet spielt das schon eine Rolle. > Mich nervt Oracle da schon viel mehr, da geht alles irgendwie > umständlich. Oracle wäre hier mit Kanonen auf Spatzen geschossen und würde voraussichtlich eher in einem Rohrkrepierer enden als den Spatz töten. Das ist ein System für Experten.
:
Bearbeitet durch User
Die Größenbeschränkung ist bei neueren Express-Versionen nach oben angehoben worden; SQL Server Express 2014 bietet 10 GB pro Datenbank. https://msdn.microsoft.com/library/cc645993.aspx
A. K. schrieb: > MS SQL ist völlig ok, insbesondere innerhalb der Limitierungen der > kostenlosen Version (Express?). Ist halt ein etwas grösserer Klops auf > der Platte als MySQL und wenn man irgendwann doch die Limitierungen > überschreiten sollte, dann wärs besser, wenn man sich über die > Lizenzierung vorher Gedanken gemacht hat. aktuell sind bis zu 10GB je Datenbank drin. http://www.microsoft.com/en-gb/server-cloud/products/sql-server-editions/overview.aspx Und wenn man will, legt man jede Tabelle in eine extra Datenbank. Was dann nur nicht geht sind contraints. Sonst ist das auch kein Problem Datenbankübergreifend abzufragen.
Klatec schrieb: > Nein ich habe keine Indexe angelegt ich habe schon davon gelesen Nicht nur lesen, auch beherzigen. Wenn du in einem Katalog einen bestimmten Artikel suchst, tust du dich ohne sortierte Liste der Warengruppen/Artikel auch fürchterlich schwer, einen bestimmten Artikel zu finden. Alternativ kann der Datenbestand natürlich auch passend sortiert sein. Das kommt auf die Daten und das dahinter stehende Datenmodell drauf an. Aber 350000 Datensätze wild durcheinander mit möglicherweise noch irgendwelchen aufwändigen Berechnungen in der Abfrage, zwingen fast jeder Performance in den Keller.
Man möge sich mal mit dem MySQL-Ableger "MariaDB" befassen. Insbesondere die Möglichkeit, notfalls für jede einzelne Tabelle eine eigene Storage-Engine (außer MyISAM oder InnoDB gibts nämlich noch reichlich andere, z.B. "Memory") zu definieren, verleiht gewissermaßen "Flügel" ... !
Frank E. schrieb: > Man möge sich mal mit dem MySQL-Ableger "MariaDB" befassen. Insbesondere > die Möglichkeit, notfalls für jede einzelne Tabelle eine eigene > Storage-Engine (außer MyISAM oder InnoDB gibts nämlich noch reichlich > andere, z.B. "Memory") zu definieren, verleiht gewissermaßen "Flügel" > ... ! ob das für Ihn sinnvoll ist? [...] It is best-used for read-only caches of data from other tables, or for temporary work areas. [...] für die paar Daten kann er jeden DB nehmen, es müssen nur die Daten passend indiziert sein.
Felix A. schrieb: > Mal so nebenbei: Access ist KEINE Datenbank wie kommst du darauf? was ist an Access anders als z.b. an sqllite?
Hallo Zusammen Ich bin überwältigt welch intensive Diskussion meine Frage vom Zaun gebrochen hat. Ich muss zugeben das mich einige Antworten überfordert haben aber ich werde jetzt einmal Schritt für Schritt versuchen meine Tabellen zu indizieren und werde mir dazu aus dem www einige Beispiele an sehen. Ich bedanke mich für eure Hilfe. Lg. Johann K.
Peter II schrieb: > Felix A. schrieb: >> Mal so nebenbei: Access ist KEINE Datenbank > > wie kommst du darauf? Doch Peter, auch Access ist eine Datenbank, schliesslich bezeichnen auch viele VSAM und ISAM als Datenbanken :-)
Der Andere schrieb: > Doch Peter, auch Access ist eine Datenbank, schliesslich bezeichnen auch > viele VSAM und ISAM als Datenbanken Die Microsoft Jet Engine, auf der Access aufbaut, kann man als RDBMS betrachten. Relationale Datenbanknutzung über SQL ist drin, Transaktionsverarbeitung und Zugriffsrechte ebenfalls. Access ist aber kein Datenbank-Server wie MySQL, MS SQL oder Oracle und findet bei gleichzeitigem Zugiff durch mehrere Anwender sehr schnell seine Grenzen. Dafür ist es nicht konstruiert, ebensowenig wie das im Ansatz grob ähnliche SQLite. https://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
:
Bearbeitet durch User
@Peter II https://de.wikipedia.org/wiki/Liste_der_Datenbankmanagementsysteme Access ist danach einfach kein Datenbankmanagementsystem. Wohingegen sqlite das jedoch ist. Eine exakte Erklärung, weshalb das so ist, finde ich gerade nicht.
Felix A. schrieb: > Eine exakte Erklärung, weshalb das so ist, finde ich gerade nicht. Weil Access eine Anwendung ist und nur dessen Jet Engine ein RDBMS - und die Jet Engine steht drin in der Liste. SQLite und Microsofts Jet Engine sind Programmbibliotheken, die es Programmen ermöglichen, wesentliche von klassischen RDBMS zur Verfügung gestellte Features in Programmen zu nutzen, ohne dafür einen separat arbeitenden Datenbankserver einrichten zu müssen. Zugriff durch mehrere gleichzeitig laufende Instanzen ist dank dieser Arbeitsweise allenfalls über sehr grobes Locking auf Fileebene möglich, wenn überhaupt. Access wiederum setzt auf die Jet Engine eine Anwendung oben drauf. Insoweit ist Access genau genommen kein Datenbanksystem, sondern eine Anwendung mit integrierter Datenbank-Engine. Und steht deshalb nicht als "MS Access" drin, sondern als "Jet Engine". Man kann Access auch als Frontend zu anderen RDBMS verwenden, also z.B. Oracle dahinter an Stelle der Jet Engine.
:
Bearbeitet durch User
A. K. schrieb: > bei gleichzeitigem Zugiff durch mehrere Anwender Zwei davon sind definitiv zuviel für sicheren Betrieb. Georg
Georg schrieb: > Zwei davon sind definitiv zuviel für sicheren Betrieb. so schlimm ist es nun auch wieder nicht. es können schon mehre Leute in einer ACCESS db gleichzeitig arbeiten - nur schneller wird es dadurch nicht. Stabil ist es aber trotzdem.
Aber Jet Engine ist File-basiert, jeder Prozess liest Seite aus dem DB-File und kann (sinnvoll) nur auf Ebene dieser DB-Seiten in der Datei sperren. Und all das geht üblicherweise übers Netzwerk. Bei SQL-Server gibt es EINE Prozess, der die Files verwaltet/seitenweise cached und der kann Sperren auf Satzebene benutzen. Den Unterschied merkt man besonders bei parallelen Zugriffen. Es fließt auch nur das Ergebnis über's Netzwerk. Ich kann mich an ein Experiment in einem O'Reilly Buch erinnern, wo ein Webserver 10x soviele Anfragen in einem 10-tel der Zeit bedient hat. Rein durch Umstieg Jet auf SQL-Server. Beide via JDBC.
Frank E. schrieb: > Man möge sich mal mit dem MySQL-Ableger "MariaDB" befassen. Bei MySQL/MariaDB sollte man aber aufpassen, das man direkt zu Beginn den strict-Mode aktiviert hat: http://www.tocker.ca/2014/01/14/making-strict-sql_mode-the-default.html ...und die DB diverse Ferkeleien erst gar nicht zu lässt ;D
Ich habe mal vor langer Zeit mit Access als Datenspeicher gearbeitet, so richtig problematisch wurde es erst als die Datei über 100 MB groß wurde. Aktuell verwende ich Sqlite auch mit 90.000 Datensätze und 10 Datenfelder pro Datensatz, also 900.000 Daten. Dies läuft alles im Sekundenbereich, also absolut unproblematisch. Wie ist denn ein Datensatz aufgebaut? Und wie sind denn die Abfragen aufgebaut, werden dort eventuell viele Verknüpfungen unter mehreren Tabellen gefordert? Vielleicht kannst Du beispielhaft mal die Struktur der Datenbank darstellen, so dass man das ganze mal simulieren kann (nur in Sqlite, Access macht für mich keinen Sinn). Und dann auch mal formulieren, wie die Abfragen aussehen. Vielleicht ist es nur ein Problem der Datenbankstruktur. Gruß Marvol
Hallo Marvol Alle Abfragen beginnen mit in der Tabelle KOMP (Komponnenten Nr.) Tab KOMP RNr KNr StaNr Bez SetNr 10 254 255 Test 16 10 25 255 Test25 17 Hier ermittle ich die SetNr mit Hilfe der Regions- und Komponentennummer die ist für jede Komponente eindeutig und schreibe sie in eine Variable. Mit dieser SetNr werden dann in der Tabelle Value1 alle nötigen Abfragen durchgeführt. Die Tabelle Value1 hat dann 52 Spalten und ca. 350000 Datensätze bei 20 Komponenten. Die meisten Datensätze haben die Ausgabebaugruppen knapp 2000. In der Tabelle Value1 wird durch die Spalten SetNr und BGNr (Baugruppennummer) und je nach Parameter gibt es dann noch 2 bis drei Spalten nach denen gefiltert wird. Aber die Abfragen erfolgen immer nur über eine Tabelle. Ich hoffe ich konnte es einiger maßen erklären. Lg. Johann K.
Hallo Marvol Habe vergessen die Datei hat 1,1 GB. Lg. Johann K
A. K. schrieb: > Weil Access eine Anwendung ist und nur dessen Jet Engine ein RDBMS - und > die Jet Engine steht drin in der Liste. Nicht nur die, man schaue mal unter 'M' nach: "Microsoft Access – das relationale Datenbanksystem von Microsoft für PCs"
Ist ja sehr lustig wie viele hier gleich mit der Wechsel-die-Datenbank-Keule um sich schlagen - mit absolut 0 Informationen wie seine Datenbank aussieht und wie er darauf zugreift (nach eigenen Aussage ist er ja nicht so der Crack oder?) Regel bei Datenbanken: -Vermeide viele kleine iterative Selects/Abfragen um dein Ergebniss zusammen zu sammeln - das ist in jeder Datenbank absolut tödlich - SQL ist sehr mächtig -arbeite mit Indices - aber nicht einfach wild einrichten - zu viel ist auch nicht gut -nicht immer alles mit TEXT oder sonstige "Übertypen" für Zahlen usw. benutzen - kostet alles zu deinen Tabellen/Queries am besten schreibst du die mal sauber auf Tabelle1 TYP feld1 TYP feld2 usw. und die Tabellenbezüge und dazu GENAU die Abfragen/Ablauf die du tätigst/machst - es kommt auf die Details an - moeglicherweise einfach zu iterativ du koenntest deine Beispiel auch einfach für SQL Fiddle vorbereiten dann kann man gleich damit spielen http://sqlfiddle.com/#!9/dcb16/1
Hallo Zusammen Ich möchte mich bei allen sehr herzlich für eure Unterstützung bedanken. Die Lösung war die Indizierung und nun flutscht's, weit schneller als vorher mit nur einer Komponente. Ich bin begeistert. Danke. Lg. Johann K.
Klatec schrieb: > Ich bin begeistert. Danke. Schön dass es so gut klappt. Wenn deine Datenbank dann auf 350 Mio Einträge angewachsen ist, sprechen wir uns wieder :)
Hallo Planlos Das wird nicht passieren weil ich nicht viel mehr als 20 Komponenten benötige. Lg. Johann K.
>Die Lösung war die Indizierung und nun >flutscht's, weit schneller als >vorher mit nur einer Komponente. wenn du uns jetzt noch deine SQL-Abfrage(n) usw. zeigst lernst du dann vielleicht auch gleich was für die nächste, noch größere DB - wo dann z.B. nur ein Index hinzufügen auch nicht mehr reicht
Test87 schrieb: > wenn du uns jetzt noch deine SQL-Abfrage(n) usw. zeigst lernst du dann > vielleicht auch gleich was für die nächste, noch größere DB - wo dann > z.B. nur ein Index hinzufügen auch nicht mehr reicht bei einer Tabelle und einer Abfrage - kann es nicht einen sinnvollen index gehen. Maximal kann man noch nach Typ unterscheiden( clustered, unique ... )
von Klatec so geschrieben >Hier ermittle ich die SetNr mit Hilfe der Regions- und Komponentennummer >die ist für jede Komponente eindeutig und schreibe sie in eine Variable. >Mit dieser SetNr werden dann in der Tabelle Value1 alle nötigen Abfragen >durchgeführt. schreibe sie in eine Variable...alle nötigen Abfragen das könnten auch mehrere sein - eine einzige reicht - aber es ist nicht klar ob es so ist
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.