Abfragen auf MySQL Dump via Cocoa Anwendung?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Abfragen auf MySQL Dump via Cocoa Anwendung?

    Hallo,
    Gibt es eine möglichkeit auf einen MySQL Dump direkt von einer Cocoa Anwendung aus zuzugreifen? Oder mag Cocoa Dateien die auf .sql enden generell nicht?
    Wie macht ihr das wenn ihr auf eine .sql Datenbank von euerer Anwendung aus zugreifen wollt?
    Gruß,

    druesbe
  • SQL-Dateien sind keine Datenbanken sondern Anweisungen für SQL-Datenbanken, um deren Schema und / oder Daten zu verändern. Wenn es sich bei Deinen Dateien tatsächlich um komplette Dumps handelt, solltest Du die Datei zuerst in eine passende Datenbank einspielen. Dann kannst Du sie über eine entsprechende Bibliothek oder Framework auslesen.
    „Meine Komplikation hatte eine Komplikation.“
  • Was wäre denn eine passende Datenbank? Sry für die wahrscheinlich dämliche Frage, aber ich schwebe in dieser Thematik gerade ohne halt...
    Ich kann vielleicht erstmal so viel erklären, dass ich eine .sql datei habe und wenn ich sie in MySQL importiere, steht mir alles zur Verfügung, was ich brauche. Heißt, alle Daten sind da und ich kann auf diese Daten auch Operationen anwenden.
    Ein ähnliches Verfahren hatte ich mir von einer Cocoa Anwendung erhofft: Man gibt irgendwo den Pfad der .sql datei an und diese wird dann importiert. Mit dieser erstellten Datenbank kann man dann "irgendwie" über die normale SQL interagieren.

    Liege ich eigentlich völlig falsch, wenn ich .sqlite dateien mit .sql dateien vergleiche? Mit SQLite3 funktioniert das oben Beschriebene ja, nur dass man hier leider nur .sqlite Dateien öffnen/importieren kann.
  • system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.
    Das mit der SQLite Datenbank hatte ich mir vorgestellt, aber wenn ich in sqlite3_open() (als ersten parameter) den pfad einer .sql datei angebe, bekomm ich füher oder später die meldung, dass ich angeblich entweder gar nicht mit einer datenbank arbeite, oder dass die db verschlüsselt sei.
  • Datenbank-Dumps werden in der Regel nur erzeugt, um die Datenbank zu sichern oder weiterzugeben. Das sind Hilfsdateien, die einen Datenbankzustand in einer lesbaren Form serialisieren. Es gibt zwar mehrere SQL-Standards aber die meisten Datenbank-Hersteller haben spezifische Erweiterungen, so dass sich eine SQL-Datei nicht einfach so für Datenbanksysteme verschiedener Hersteller verwenden lässt. Häufig gibt es sogar schon Probleme, wenn das Major-Release unterschiedlich ist...

    Du solltest also Deinen Dump in eine MySQL-Datenbank einspielen.

    system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.

    Das ist Unsinn. Genauso sind .m-Dateien einfache Textdateien, die einfach direkt eingelesen und interpretiert werden können. Du wirst auch arge Probleme bekommen, einen MySQL-Dump in eine SQLite einzuspielen.

    Am besten lest ihr beide erstmal etwas Grundlegendes zu relationalen Datenbanken.
    „Meine Komplikation hatte eine Komplikation.“
  • DrUeSBe schrieb:

    system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.
    Das mit der SQLite Datenbank hatte ich mir vorgestellt, aber wenn ich in sqlite3_open() (als ersten parameter) den pfad einer .sql datei angebe, bekomm ich füher oder später die meldung, dass ich angeblich entweder gar nicht mit einer datenbank arbeite, oder dass die db verschlüsselt sei.

    Weil eben (My-)SQL Anweisungen sind und keine sqlite Datenbank. Du kannst versuchen, Deine *.sql Datei kompatibel zu sqlite zu gestalten, ich weiss hier jetzt aber nicht genau, was Du alles anpassen muesstest. Dann importierst Du diese *.sql in eine sqlite-db (in etwa im Terminal "sqlite bla.sqlite < dump.sql") und kannst dann in Cocoa auf der sqlite-db arbeiten.
    Die Konvertierung von MySQL in sqlite wird nur nicht ganz so trivial sein, denk ich mal.
    C++
  • Verbirgt sich denn hinter einer .sqlite datei wirklich eine Datenbank, oder eben auch wieder ein dump? Ich dachte bisher immer, dass sei auch ein dump.

    Und nocheinmal: Ich habe ein SQLite dump, lese diesen in eine SQLite Datenbank ein (mit sqlite3_open()) und kann dann mit den ganzen C Befehlden mit der SQLite Datenbank arbeiten.

    mich interessiert aber: Ich habe ein MySQL dump, lese diesen in eine MySQL DB ein (hier fängts schon an: geht sowas standardmäßig überhaupt mit Cocoa?) und möchte dann auch gerne in einer stink normalen Obj-C Klasse damit arbeiten können.

    Verbirgt sich hinter dem, was ich jetzt geschrieben habe, ein grober Denkfehler? Und wenn nein, wie funktioniert dann dieser zweite Fall, den ich beschreiben habe und der mich interessiert, ganz konkret?
  • DrUeSBe schrieb:

    Das mit der SQLite Datenbank hatte ich mir vorgestellt, aber wenn ich in sqlite3_open() (als ersten parameter) den pfad einer .sql datei angebe, bekomm ich füher oder später die meldung, dass ich angeblich entweder gar nicht mit einer datenbank arbeite, oder dass die db verschlüsselt sei.
    Die Datei, von der Du redest, enthält SQL-Statements – aber sqlite3_open (ebenso wie auch meinetwegen das sqlite-Executable an der Shell) erwarten eine Datenbankdatei, also eine Binärdatei im SQLite-Format. Du kannst ja auch nicht eine SQL-Datei in MySQLs Data-Verzeichnis legen und erwarten, dass die funktioniert.

    Carsten
  • DrUeSBe schrieb:

    Verbirgt sich denn hinter einer .sqlite datei wirklich eine Datenbank, oder eben auch wieder ein dump? Ich dachte bisher immer, dass sei auch ein dump.

    Und nocheinmal: Ich habe ein SQLite dump, lese diesen in eine SQLite Datenbank ein (mit sqlite3_open()) und kann dann mit den ganzen C Befehlden mit der SQLite Datenbank arbeiten.

    mich interessiert aber: Ich habe ein MySQL dump, lese diesen in eine MySQL DB ein (hier fängts schon an: geht sowas standardmäßig überhaupt mit Cocoa?) und möchte dann auch gerne in einer stink normalen Obj-C Klasse damit arbeiten können.

    Verbirgt sich hinter dem, was ich jetzt geschrieben habe, ein grober Denkfehler? Und wenn nein, wie funktioniert dann dieser zweite Fall, den ich beschreiben habe und der mich interessiert, ganz konkret?

    *.sqlite ist bereits die gesamte Datenbank und nicht etwa nur ein dump.
    sqlite ist genau darauf ausgelegt, dass soetwas funktioniert, wie Du das beschrieben hast, weil jede Anwendung ihren eigenen Server importiert/startet.
    MySQL ist nicht dafuer gedacht, darum funktioniert das nicht (so einfach).
    C++
  • DrUeSBe schrieb:

    mich interessiert aber: Ich habe ein MySQL dump, lese diesen in eine MySQL DB ein (hier fängts schon an: geht sowas standardmäßig überhaupt mit Cocoa?) und möchte dann auch gerne in einer stink normalen Obj-C Klasse damit arbeiten können.

    Verbirgt sich hinter dem, was ich jetzt geschrieben habe, ein grober Denkfehler? Und wenn nein, wie funktioniert dann dieser zweite Fall, den ich beschreiben habe und der mich interessiert, ganz konkret?

    Du musst den Dump, über ein Terminalprogramm namens mysql (1) in ein MySQL-Datenbankmanagemensystem (DBMS) einspielen. Das legt die Daten in eigenen Dateien ab. Danach kannst Du mit verschiedenen Clients (z. B. dem Terminalprogramm mysql, selbst geschrieben Programmen) auf die Daten zugreifen. Da MySQL nach dem Client-Server-Prinzip arbeitet, läuft auf dem Rechner mit der Datenbank ständig ein Programm (mysqld) im Hintergrund, über das andere Programme auf die Datenbank(en) zugreifen können. Das geht sogar über Rechnergrenzen hinweg.

    Wahrscheinlich musst Du aber erst das MySQL-System auf Deinem Rechner installieren. Dazu gibt es fertige Installer und die Verwaltung des Servers erfolgt über die Systemeinstellungen.
    „Meine Komplikation hatte eine Komplikation.“
  • DrUeSBe schrieb:

    Verbirgt sich denn hinter einer .sqlite datei wirklich eine Datenbank, oder eben auch wieder ein dump? Ich dachte bisher immer, dass sei auch ein dump.

    Und nocheinmal: Ich habe ein SQLite dump, lese diesen in eine SQLite Datenbank ein (mit sqlite3_open()) und kann dann mit den ganzen C Befehlden mit der SQLite Datenbank arbeiten.

    mich interessiert aber: Ich habe ein MySQL dump, lese diesen in eine MySQL DB ein (hier fängts schon an: geht sowas standardmäßig überhaupt mit Cocoa?) und möchte dann auch gerne in einer stink normalen Obj-C Klasse damit arbeiten können.
    Eine SQLite-Datenbank ist eine SQLite-Datenbank und kein Dump. Du kannst einen Dump nicht mit sqlite3_open() öffnen.

    »Standardmäßig« weiß Cocoa nicht, was MySQL ist, aber es gibt natürlich Wege, mit MySQL zu kommunizieren. Sei es über die normale C-API von MySQL, Userland-APIs in Cocoa (z.B. SMySQL Framework) oder einfach, indem Du z.B. (um beim Beispiel des Einlesens des Dumps zu bleiben) diesen einfach per NSTask shell-mäßig in MySQL reinpumpst:

    Quellcode

    1. mysql -u foo -pbar dbname < /path/to/dump
    Carsten
  • Danke Leute, dank euch hat jetzt alles geklappt.
    Für alle, die vor der gleichen Aufgabe stehen:

    1. Den MySQL Dump, also eine .sql Datei, in ein MySQL Datenbankmanagementsystem importieren. Dieses erstellt daraus eine Datenbank.
    1.1 Dies geht u.A. wie folgt: XAMPP herunterladen, den Apache und den MySQL Server starten und in einem Internetbrowser "localhost/phpmyadmin" eingeben.
    1.2 Dort ganz rechts oben auf "imortieren" drücken und die entsprechende .sql datei auswählen. -> Der Dump wird importiert und eine Datenbank wird daraus automatisch erzeugt.

    2. MySQL Datenbank in eine SQLite Datenbank "konvertieren"
    2.1 Ich habe mir das Programm "DBConvert for SQLite & MySQL" in der Trialversion heruntergeladen. Andere Konvertierprogramme gehen natürlich auch.
    2.2 Dort als Source die MySQL Datenbank auswählen, wobei das Konvertierprogramm auf den entsprechenden MySQL Server zugreifen muss.
    2.2 Als Destination dann den Pfad angeben, wo die SQLite Datenbank gespeichert werden soll.

    3. Die nun entstandene Datei (kann z.B. die Endungen .sqlite, .sqlite3 oder auch .db haben) per sqlite3_open() öffnen

    So, Aufgabe gelöst :)
  • macmoonshine schrieb:

    system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.

    Das ist Unsinn. Genauso sind .m-Dateien einfache Textdateien, die einfach direkt eingelesen und interpretiert werden können. Du wirst auch arge Probleme bekommen, einen MySQL-Dump in eine SQLite einzuspielen.

    Leider schreibst nur du Unsinn. Bei mysqldump kann man über "--compatible=name" sogar angeben, welche anderen Datenbank die Datei noch einlesen können sollen. Ich kann dir versichern, dass SQLite mit einem normalen MySql-Dump auch ohne irgendwelche Extra-Optionen absolut keine Probleme hat. Wie bereits gesagt, erzeugt man einfach eine neue leere temporäre Datei und führt dann jeden Befehl aus dem Dump einfach hintereinander aus, schon hat man ein ungefähres Abbild der ursprünglichen Datenbank im Speicher. Wie kann man nur auf die Idee kommen, dass SQlite mit ein paar simplen "create table"- und "insert into"-Anweisungen Probleme haben soll.
  • system schrieb:

    macmoonshine schrieb:

    system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.

    Das ist Unsinn. Genauso sind .m-Dateien einfache Textdateien, die einfach direkt eingelesen und interpretiert werden können. Du wirst auch arge Probleme bekommen, einen MySQL-Dump in eine SQLite einzuspielen.

    Leider schreibst nur du Unsinn. Bei mysqldump kann man über "--compatible=name" sogar angeben, welche anderen Datenbank die Datei noch einlesen können sollen. Ich kann dir versichern, dass SQLite mit einem normalen MySql-Dump auch ohne irgendwelche Extra-Optionen absolut keine Probleme hat. Wie bereits gesagt, erzeugt man einfach eine neue leere temporäre Datei und führt dann jeden Befehl aus dem Dump einfach hintereinander aus, schon hat man ein ungefähres Abbild der ursprünglichen Datenbank im Speicher. Wie kann man nur auf die Idee kommen, dass SQlite mit ein paar simplen "create table"- und "insert into"-Anweisungen Probleme haben soll.

    Auf die Idee kann man kommen, wenn man weiss, was MySQL alles kann. Unter anderem inzwischen Stored Procedures und Views, und da hoert es denke ich bei sqlite schon auf. Dazu kommt, dass ich nicht weiss, ob sqlite mit den MyISAM und InnoDB Schluesselworten klar kommt. Nutzerrechte koennten auch in einem MySQL Dump enthalten sein, ob die sqlite ohne Zoegern ignoriert muesste ich auch raten.
    Das --compatible ist aber natuerlich ein guter Hinweis :)
    C++
  • system schrieb:

    macmoonshine schrieb:

    system schrieb:

    Nun, da SQL-Datein einfache Textdatein sind, kann man sie entweder direkt einlesen und auswerten oder man erzeugt etwa eine temporäre SQLite-Datenbank im Speicher und füttert die mit der Datei.

    Das ist Unsinn. Genauso sind .m-Dateien einfache Textdateien, die einfach direkt eingelesen und interpretiert werden können. Du wirst auch arge Probleme bekommen, einen MySQL-Dump in eine SQLite einzuspielen.

    Leider schreibst nur du Unsinn. Bei mysqldump kann man über "--compatible=name" sogar angeben, welche anderen Datenbank die Datei noch einlesen können sollen. Ich kann dir versichern, dass SQLite mit einem normalen MySql-Dump auch ohne irgendwelche Extra-Optionen absolut keine Probleme hat. Wie bereits gesagt, erzeugt man einfach eine neue leere temporäre Datei und führt dann jeden Befehl aus dem Dump einfach hintereinander aus, schon hat man ein ungefähres Abbild der ursprünglichen Datenbank im Speicher. Wie kann man nur auf die Idee kommen, dass SQlite mit ein paar simplen "create table"- und "insert into"-Anweisungen Probleme haben soll.

    Meine Aussage mit dem Unsinn bezieht sich auf Deine Aussage, dass SQL-Dateien einfache Textdateien seien, die
    einfach direkt eingelesen und interpretiert werden können.
    . Das ist Unsinn. Deswegen habe ich auch den Vergleich mit Objective-C geschrieben. Eine MySQL-Datei in SQLite zu importieren habe ich nicht grundsätzlich ausgeschlossen. Wie zerm aber bereits angemerkt hat, wirst Du mit Stored-Procedures o. Ä. Probleme bekommen.
    „Meine Komplikation hatte eine Komplikation.“