Im Februar startet der Microsoft TechDay mit einer Sonderreihe. Unter dem Motto „Best Practice Day- Neues und Unbekanntes für den Systemadministrator“ geht es an fünf Tagen in fünf Städten – München, Karlsruhe, Frankfurt, Leipzig und Hamburg – um das Thema „System-Administrator“.
Die täglichen Aufgaben des SysAdmins unterstützen zahlreiche Tools, die oft unbekannt sind oder unterschätzt werden. Diese Tools, zusammen mit vielen Tipps und Tricks, werden von den Microsoft Evangelisten im Rahmen des Microsoft TechDays vorgestellt.
Weitere Infos und Anmeldung unter: http://go.microsoft.com/?linkid=9645348
Im Rahmen dieser Veranstaltung gibt es bei c++.de ein Gewinnspiel, bei dem unter anderem 2 kostenlose Eintrittskarten für den TechDay zu gewinnen sind, sowie weitere Preise:
3 Microsoft Livecams VX-7000
3 Halo 3
3 Leatherman Kick
Registrierte Benutzer von c++.de können über den folgenden Link zum Preisrätsel kommen und an dem Gewinnspiel teilnehmen. Einsendeschluß ist der 06.02.2009.
http://www.c-plusplus.net/forum/profile-var-mode-is-email-and-u-is-108643.html
Die Datenbank-FAQ
Bitte schaut ob einige eurer Fragen vielleicht schon beantwortet sind. Benutzt dazu auch die Suchfunktion. Beachtet beim posten bitte auch die gängigen Regeln -> Wie man Fragen richtig stellt
Basiswissen rund um Datenbanken und zu SQL - Links und Erklärungen über Datenbanken Basiswissen und SQL.
Datenbanken in Programmen ansprechen - Wie man Datenbanken (wie MySQL oder Access) an ein Programm anbinden kann.
Freie/Kostenlose Datenbanken - eine Liste von freien oder kostenlosen Datenbanken.
Ist mir schon klar. Ich verstehe bloss deinen Beitrag
@Wutz sagte in Sqlite Variablen in Datenbank einfügen:
Dafür existiert der 1.Parameter in callback und der 4. in sqlite3_exec.
nicht. Weil der nichts mit dem hier Diskutierten zu tun hat.
@RudiMBM
Dann fallen mir nur diese Optionen ein:
ASCII Kodierung als Hex, damit kannst du auf Attribute deines Datentyps anhand von Substrings zugreifen, wid mitm Indizieren aber wohl schwierig. KA, wie gut MySQL Indzierung von Substrings unterstützt
Attribute deines Datentyps in eigener Spalte ablegen
deinen Datentyp als JSON Objekt ablegen. Auch hier weiß ich nicht, wie gut MySQL JSON Objekte indizieren kann.
@DocShoe sagte in MySQL Connector C++:
Ansonsten hast du recht, viele tausend einzelne Queries sind oft langsamer als eine Query mit einer komplexen where-Klausel.
@Leon0402 sagte in Datenbank für C++:
Sehr spannendes Thema, aber bitte in einem anderen Thread.
Die hier nicht mehr sichtbare Diskussion findet man nun hier:
https://www.c-plusplus.net/forum/topic/351066/ständig-wachsende-komplexität-im-programmiereralltag-fork-aus-datenbank-für-c/9
@asc sagte in Gibt es eine Entscheidungshilfe für die geeigneste Datenbankart nach Anwendungsfall?:
unterschiedlicher NoSQL-Ansätze, wie KeyValue, Graph, Document und Column-Familie)
Ich finde die Unterschiede aber gar nicht so groß, zumindest subjektiv. Bis auf Graphdatenbanken, aber das ist ein Spezialfall.
Ansonsten... Ich kann eine Key Value Datenbank mit einem eindeutigen Key und einem Json Objekt als Value nehmen. Oder eine Dokumenten-Datenbank. Ebenfalls mit einem eindeutigen Key + Json Dokument. Und Column Store ist jetzt auch nicht großartig anders.
Die Frage ist für mich eher, was will ich damit erreichen, und was erhoffe ich mir davon.
Und das lief bei mir bisher fast immer darauf hinaus, dass ich entweder Sqlite hernehme (mehr oder weniger als Key-Value mit Json als Value, evtl. paar Json Indizes), oder vielleicht mal LevelDb.
Also hundertausende bis mehrere Millionen Datensätze. Das klingt nach einem guten Fall für irgendeine freie Datenbank (ziemlich egal welche, da du sie nur als Datenhalde benutzen wirst), und dem Analysegespann Python/Pandas/Jupyter.
@ravenheart_ggg
Ist da ein Fehler drin?
Wenn der unique_ptr nach Gebrauch zerstört wird, ist das Ok.
Dann liegt das Problem woanders, da kenne ich mich dann aber nicht aus.
Falsche Sprache.
Don't get me wrong. Real programmers might do list processing in fortran, accounting in fortran, ai in fortran. But heck, that was 30 years ago. Wanna do db stuff? Use some state of the art language.
Hi,
doch noch ne Lösung gefunden.
Aufmachen oder anschauen ging gar nicht.
Aber mit nem SQL-Befehl nach der Art
Select * into Tabelle from Tabelle in "Datei.mdb"
ließen sich die Daten in eine neue aktuelle Datenbank reinziehen.
Nur falls mal ein anderer vor dem gleichen Problem steht.
Basis war ein TAdoDataset von Embarkadero (Delphi)
Gruß Mümmel
Danke für die Hilfe, konnte jedes Problem lösen, waren die richtigen Denkanstöße dabei, die entweder Denkfehler von mir aufgezeigt haben oder ich die Richtigen Stichworte zum googeln bekommen habe.
Ich kenn mich leider mit Oracle nicht aus, aber ich kann dir ein paar Sachen sagen die du probieren könntest.
INSERT ALL mit expliziter NULL für die Key-Spalte. Bei manchen Datenbanken funktioniert sowas.
Explizite Transaktion rund um die einzelnen INSERT mit einem einzigen COMMIT am Schluss.
UNION ALL
Ala
INSERT INTO tbl_name (a,b,c)
SELECT 1, 2, 3
UNION ALL SELECT 4, 5, 6
UNION ALL SELECT 7, 8, 9;
Manche DBs haben Funktionen mit denen man sich explizit den nächsten Wert für ne Autoinkrement Spalte einer bestimmten Tabelle holen kann.
Oder gibt es vielleicht Funktionen mittels derer man Rowsets aus Strings erzeugen kann? MSSQL kann z.B. XML parsen und ein Rowset zurückgeben das man dann in SELECT verwenden kann. Das kann man dann in einem INSERT ... SELECT verwenden. Dazu muss man natürlich vorher die Daten erstmal in XML verwandeln, aber von der Performance her ist es bei MSSQL deutlich besser als einzelne INSERTs.
Table Variablen. Auch keine Ahnung ob Qracle sowas kann, aber es gibt DBs die in-memory Table-Variablen können - wie z.B. auch MSSQL. Falls es sowas gibt wäre es möglich dass lauter einzelne INSERTs in ne Table-Variable schneller sind als direkt in den Table. In dem Fall dann die Zeilen erst einzeln in die Table-Variable einfügen und dann wieder mit INSERT ... SELECT weiter in die Tabelle schieben.
Wenn das alles nix hilft, dann bleibt noch die Möglichkeit in nen Temp-Table mit INSERT ALL einzufügen, und dann von dort weiter mit INSERT ... SELECT in die permanente Tabelle.
Problem ist gelöst, ist jetzt wieder 10 - 30 x schneller: Das Hauptproblem war ein PK (einer anderen gejointen Tabelle), der versehentlich auf 2 Feldern definiert war, anstatt dass das 2. Feld als separater Index definiert wurde.
(wegen Bedienung einer zusätzlichen Werte-Historie wurde pro "Update" folgende Sequenz in einer Schleife duchgeführt: Select mit Join -> Update -> Insert in Historie. Vermutete zuerst, dass das die Transaktion ineffektiv machen könnte und wollte Select, Updates und Inserts separieren. Aber das scheint jetzt nicht mehr nötig.)
Vielen Dank für eure Hinweise!
