@DocShoe sagte in Abfrage über 3 Tabellen, Zeile mit höchstem Wert als Condition bestimmen:
@Swordfish
Keine Ahnung, was du mir sagen willst. Schlechte Laune? Bei Postgres galten CTEs als Optimization Fence, kA, ob das immer noch so ist. Und deshalb muss ich benchmarken, ob die CTE Lösung langsamer ist als die Lösung mit zwei identischen Subqueries. Weiß jetzt echt nicht, wo dein Problem liegt.
No problem at all. Du bestätigst nur das was ich geschrieben habe. Miss die Kacke.
@hustbaer sagte in Abfrage über 3 Tabellen, Zeile mit höchstem Wert als Condition bestimmen:
Das ist natürlich keine Rocket-Science, aber es kostet Zeit.
Ja, das kostet Zeit. Wenn man das so in ein Forum knallt kostet es jedem der es liest Zeit. Ich würde mich sowas nicht trauen bzw. es würde meiner Nächstenliebe zuwider sein.
Hallo Leon0402,
Ich beschäftige mich schon seit geraumer Zeit mit objektorientierten Datenbanken für C++-Klassen. Das Ziel ist ja, Objekt zu speichern ohne sich um das wie zu kümmern.
Schau Dir doch mal GlobalObjects an, vielleicht ist das etwas für Dich. Ist open source und eigentlich schon weit gediehen.
Einen schnellen Überblick bekommst Du über die Videos.
Gruß Helmut
@DocShoe sagte in DBMS gesucht:
@john-0
Irgendwie erinnern mich deine Antworten immer an MS-Doku. Technisch korrekt, aber irgendwie nicht zu gebrauchen.
Du bist auf einem Tripp der die Dich in die komplett falsche Ecke führt, sehen willst Du das aber nicht. Weshalb nutzt Du überhaupt ein RDBMS, wenn es eine simple Textdatei auf einem Fileserver auch täte bzw. ein Blob im RDBMs? Die Vorteile eines RDBMS nutzt Du durch Deiner Art und Weise der Nutzung des selben definitiv nicht. Key-Value-Paare legt man in keinem RDBMS ab, denn die „Keys“ gehören in die Tables d.h. der Struktur der Datenbank.
Anstatt nun die Bohrhammer dafür zu nutzen ein Loch zu bohren, dieses anschließend aus zu saugen, dann einen Dübel rein zu stecken und anschließend die Schraube einzuschrauben, hast Du Dich dazu entschlossen mit dem Hammer die Schraube in die Wand zu schlagen. Ja, das geht, aber sinnvoll ist es nicht.
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.
