1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Objective C und Datenbanken/Core Data?

Dieses Thema im Forum "OS X-Developer" wurde erstellt von Der Paule, 12.09.09.

  1. Der Paule

    Der Paule Königsapfel

    Dabei seit:
    26.05.07
    Beiträge:
    1.200
    Hallo zusammen,

    ich suche eine Möglichkeit mit Objective C auf Datenbanken zu zugreifen. Habe mal bei Google gesucht aber nicht wirklich etwas gefunden was mir weiterhilft. Habe ein Framework gefunden für MySQL aber mich interessiert vielemehr obs ne API oder ein Framework gibt mit dem ich beliebigen Datenbanken alla MySQL, Oracle, MSSQL oder PostgreSQL ansprechen kann.

    Im Internet stößt man auch sehr häufig auf die Aussage Core Data zu nutzen. Nun für die einfach Speicherung der Daten und Objekte scheint Core Data eine sehr gute Lösung zu sein. Ich stell mir da aber die Frage wie Performant die ganze Sache ist? Kann Core Data mit mehreren 1000 Datensätzen schnell umgehen und wie sieht es mit Suchen aus? Ich habe in der Apple Dokumentation gelesen das Core Data keineswegs ein Ersatz für Relationale Datenbanken ist. Aber genau so eine Anbindung suche ich.

    Kann einer Stellung zu der Sache nehmen und mir sagen wie ich da am besten vorgehen kann und ob es überhaupt möglich ist mit Objective C auf Datenbanken zu zugreifen? Ich möchte mir allerdings nicht selber ne API dafür schreiben müssen. Es kann ja schließlich nicht sein das das ohne Verrenkungen nicht geht. Bei anderen Programmiersprachen ist das ja auch ohne weiteres Möglich. Ich kenne es von Java und .net wo es ohne Probleme geht.

    Danke.

    mfg
    paule
     
  2. Scotch

    Scotch Ananas Reinette

    Dabei seit:
    02.12.08
    Beiträge:
    6.244
  3. Der Paule

    Der Paule Königsapfel

    Dabei seit:
    26.05.07
    Beiträge:
    1.200
    Hast du meinen Beitrag gelesen ;) Hab schon gegoogelt und ich halte ODBC nicht für die beste Lösung. Es wäre eine, ja, wenn es keine Möglichkeit gibt ein Framework oder ne API zu nutzen. Oder vielleicht doch über Core Data?

    Deswegen ja meine Frage hier.

    mfg
    paule
     
  4. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    Vielleicht mal die Search Terms überdenken: Diese Ergebnisse sind vielleicht nicht so übel.
    Inwiefern MacSQL noch supported wird, darfst Du selbst rausfinden.

    Wenn Dir die vorgeschlagenen Lösungen nicht zusagen, mußt Du Deine Fragestellung präzisieren.
    Gruß Pepi
     
  5. Der Paule

    Der Paule Königsapfel

    Dabei seit:
    26.05.07
    Beiträge:
    1.200
    MacSQL habe ich auch schon entdeckt gehabt. Allerdings gibts es nur eine 60 Tage Demo. Immerhin, aber für eine Dauer-Nutzung eher nicht zu gebrauchen. Was die Suchergebnisse angeht. Ja die kenne ich. Aber etwas wirklich hilfreiches ist dort nicht dabei. Wie schon erwähnt gibt es ein MySQL Framework zur Anbindung einer MySQL Datenbank an Objective C. Allerdings scheint es keine Möglichkeit zu geben von Objective C heraus direkt auf Datenbanken verschiedener Arten zu zugreifen, ohne ODBC.
    Diese Vermutung scheint wohl richtig zu sein. D.h. das ich ohne eigen Entwicklung einer API oder Nutzung von ODBC nicht mit Datenbanken arbeiten kann.

    Momentan beschäftige ich mich mit der Core Data. Scheint wohl die von Apple einzige Möglichkeit zu sein, Maßendaten mit Indexen und schneller Suchmöglichkeit zu sein. So weit ich weiß baut iTunes ebenfalls darauf auf? Ist das richtig? Meine frage ist nur wie verhält sich diese Technologie mit vielen Daten/Datensätzen?

    So um nochmal meine Frage zu Präzisieren: Gibt es eine Möglichkeit mit Objective C, ohne eigene API Entwicklung und ohne ODBC, mit verschiedenen Datenbanken zu Arbeiten? Und wie sieht es mit Core Data als "Datenbank Ersatz" aus?

    Hoffe es ist genauer geworden :)

    mfg
    paule
     
  6. Scotch

    Scotch Ananas Reinette

    Dabei seit:
    02.12.08
    Beiträge:
    6.244
    Nein. Denn genau für deine Anforderung wurde ODBC "erfunden" - wenn du also ODBC nicht benutzen möchtest und kein DBMS-spezifisches API benutzen willst, musst du wohl oder übel ODBC neu erfinden :)

    Core Data hilft dir, wenn du eine DB (oder DB-Funktionen) selbst erstellen möchtest - zur Anbindung von (R)DBMS bringt dich das Framework nicht wirklich weiter.

    Gruss,
    Dirk
     
  7. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    "Ich will A."
    "Dann nimm A-Framework."
    "Das will ich nicht, ich sage aber nicht warum."
    "Dann nimm die B-Technologie."
    "Das will ich nicht, ich sage aber nicht warum. Scheint offenbar nicht zu gehen."

    Vielleicht solltest du mal sagen, warum du überhaupt ein rDBMS verwenden möchtest und was dir an den vorgeschlagenen Lösungen nicht gefällt. Andernfalls laufen wir hier alle mit NSWünschelrute durch die Gegend.
     
  8. Der Paule

    Der Paule Königsapfel

    Dabei seit:
    26.05.07
    Beiträge:
    1.200
    Nun folgendes, ODBC möchte ich nicht als optimale Lösung sehen. Warum? Wenn es für die DBMS fertige Frameworks gibt würde ich nicht auf ODBC zurückstellen. Da ja das Framework auf das DBMS passt und somit das System besser ausnutzt.
    Wann würde ODBC in Frage kommen? Nur wenn es tatsächlich keine Frameworks für die DBMS gibt. Gefunden habe ich bis jetzt nur ein Framework (MySQL). Ich frage mich warum es nur das eine zu der einen Datenbank gibt? Wurde diese Thematik nie wirklich angedacht von irgendwem oder wird das nie genutzt in Anwendungen für den Mac? Auch nicht im Professionellen Umfeld bei größeren Anwendungen mit externen Datenbank Servern? Oder wird dort immer ein eigenes Süppchen gekocht?
    Und Core Data? Nun, habe mal erste Gehversuche (wenn ichs so nennen will) gemacht. Alles in allem scheint es ja ne passable Lösung zu sein um mal Flux ein paar Daten zu speichern. Meine Frage ist nun wie Performant Core Data im Gegensatz zu einer DBMS ist? Gibt es da jemanden der damit Erfahrungen hat?

    Warum der ganze Spökes? Speichern von Metainformationen verschiedener Art zu verschiedenen Dateien und Dokumenten. Also nicht nur 5 Spalten/Informationen zu einer Datei. Da kommen einige Informationen mehr zusammen. Und das auch nicht nur für eine Handvoll Dateien. Deswegen möchte ich das ganze nicht in XML packen sondern in eine Datenbank. Schon alleine weil ich durch die Indexierung und der SQL Abfragen die Möglichkeit habe sehr schnell an bestimmte Informationen zu gelangen.

    Jetzt bin ich momentan am schauen wie ich mit Objective C an Datenbanken rankomme. An welche ich ran komme und wie viel Aufwand ich betreiben muss dafür? Was mich schon wundert ist die Tatsache das es anscheinend keine/bis kaum Lösungen dazu gibt. Und ich Frage mich wieso Apple sich dazu keine Gedanken gemacht hat? Wegen Core Data? Keine Lust? Kosten/Zeit Aufwand zu hoch?

    Hoffe doch das es ein bisschen Deutlicher geworden ist worum es mir geht. Und ich habe nie gesagt das ich irgendwas gar nicht nutzen möchte. Sondern habe es nur hinten angestellt. Achja, welches DBMS ggf. in Einsatz kommt weiß ich noch nicht genau. Mitunter auch weil ich nicht genau weiß welche Systeme ich ohne viel Aufwand ansprechen kann. Mit MySQL scheint es zu gehen und bei den anderen?

    mfg
    paule
     
  9. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.252
    Der Mac ist nicht die typische Büromaschine, auf der Clients für Datenbanken läuft. Und wenn dann wird das nur indirekt über den Webbrowser der Fall sein. Es gibt keine aktuelle Version der wichtigsten RBMS für MacOS X: Oracle, DB2 MS SQL. Das betrifft sowohl die Server wie auch die Client-Libraries.
    Wenn man eines der großen RDBMS nutzen will, ist man zur Zeit auf MacOS X zwingend auf Java oder einem ODBC-ODBC Treiber angewiesen. Anders kann man auf diese Server nicht zugreifen.
    Nein, nicht unbedingt, da in der Regel kein Ojective-C genutzt wird. Wenn man Objective-C verwenden will, kommt man nicht umher die C APIs der Clients Libraries zu nutzen.
    Ist nicht dafür gedacht ein RDBMS abzufragen, sondern den internen Zustand einer Applikation in eine Datenbank zu (de)serialisieren. D.h. der Objektgraph kann mittels Core Data gespeichert und wieder geladen werden.

    Ein RDBMS ist grundsätzlich anders strukturiert wie eine OO-Applikation. Wenn man ein RDBMS hundertprozentig ausnutzen will, kommt man nicht umher sich für ein spezielles RDBMS zu entscheiden und dabei zu bleiben. Viele der Funktionen existieren nicht in anderen RDBMS oder in einer anderen Form, die sich nicht so leicht vereinbaren läßt.

    Ein ganz simples Beispiel:
    MySQL kennt keine Sequenzen, die sind aber bei allen anderen RDBMS Standard. Daher muß man bei MySQL nach dem Einfügen eines Datensatzes "last_insert_id()" nutzen, während man beim allen anderen sich vorher aus der Sequenz die notwendige Nummer holt und dann einfügt.
    C API nutzen, was anderes bleibt Dir nicht übrig.
     
  10. below

    below Kalterer Böhmer

    Dabei seit:
    08.10.06
    Beiträge:
    2.865
    ACHTUNG, nicht mein Speizialgebiet, das ist vielleicht eine doofe Frage: Ist IBMs DB2 Viper nicht in aktueller Version für den Mac verfügbar? Ich hab mal eine von IBM bekommen, bin aber noch nicht dazu gekommen, sie mal auszuprobieren.

    Ja. Oder halt einen Obj-C Wrapper schreiben, wenn Du das willst.

    Alex
     
  11. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.252
    Das ist eine Beta, und es ist nur die kostenlose Edition. Immerhin bewegt sich etwas, aber Oracle hatte ja auch einmal eine MacOS X Version angeboten. Jedenfalls wenn man DB2 braucht, dann kann man definitiv nichts mit einer Beta anfangen.
     
  12. Jamsven

    Jamsven London Pepping

    Dabei seit:
    21.11.07
    Beiträge:
    2.046
    Schon mal über MacRuby nachgedacht?
     
  13. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    aber vor hast du geschrieben:

    Wie schon Scotch schrieb, genau dafür wurde ODBC erfunden.
    Wenn Du eine Schnittstelle für (fast) alles willst, dann nehm ODBC.
    Solltest Du aber höchste Performance für ein bestimmtes Datenbanksystem haben wollen, dann nimm die jeweilige C-API bzw. falls vorhanden kannst du ggf auch das OBJ-C-Framework nutzen.

    Zu meinen kannst Du das nicht vergleichen, denn bei CoreData kannst Du zwischen XML (langsam, aber gut für Datenexport und fürs Debuggen), Binär (sehr schnell) und SQLite (recht schnell und recht gut exportierbar) wählen.

    CoreData ist, normalerwiese, nicht für Mulituser-Einsatz gedacht. Die meisten RDBMS sind aber für den Server- und damit Multiuser-Betrib konzipiert.


    Wenn Du die Daten nicht zwischen mehreren Nutzern teilen möchtetst, dann nimm CoreData.

    aber vor hast du geschrieben:

    Wie schon Scotch schrieb, genau dafür wurde ODBC erfunden.
    Wenn Du eine Schnittstelle für (fast) alles willst, dann nehm ODBC.
    Solltest Du aber höchste Performance für ein bestimmtes Datenbanksystem haben wollen, dann nimm die jeweilige C-API bzw. falls vorhanden kannst du ggf auch das OBJ-C-Framework nutzen.

    Zu meinen kannst Du das nicht vergleichen, denn bei CoreData kannst Du zwischen XML (langsam, aber gut für Datenexport und fürs Debuggen), Binär (sehr schnell) und SQLite (recht schnell und recht gut exportierbar) wählen.

    CoreData ist, normalerwiese, nicht für Mulituser-Einsatz gedacht. Die meisten RDBMS sind aber für den Server- und damit Multiuser-Betrib konzipiert.

    Also es gibt schon einige C-APIs, ich glaube nicht, dass da sooo grosser Mangel herrscht.

    Böse gesagt: Wenn es mit MySQL geht, dann geht mit den anderen alle mal ;)
     
  14. Der Paule

    Der Paule Königsapfel

    Dabei seit:
    26.05.07
    Beiträge:
    1.200
    So, nachdem hin und her und googlen nutze ich jetzt MySQL als Datenbank zusammen mit der C Api. Allerdings verwundert mich das MySQL Referenzhandbuch ein wenig. Dort sind teilweise Funktionen enthalten die ich in Xcode gar nicht auswählen kann. Ich arbeite mit dem MySQL Server 5.1.39. Kann das eventuell jemand bestätigen? Als Beispiel wäre da die "myqsl_create_db()" Funktion genannt. Im Prinzip kein Problem da ich ne Datenbank per SQL Query erstelle aber wenn die Funktion aufgeführt wird in der Referenz, sollte diese ja auch vorhanden sein, oder?

    Erstmal danke für die Geduld und ich muss mich entschuldigen. Ich habe mich grade im Eingangspost wohl nicht vernünftig ausgedrückt. Ich wollte nicht alle Datenbanken auf einmal ansprechen sondern "irgendeine" ohne sonder Programmierung. Naja ist ja jetzt auch egal.

    mfg
    paule
     
  15. Bananenbieger

    Bananenbieger Golden Noble

    Dabei seit:
    14.08.05
    Beiträge:
    24.567
    Mal eine ganz dumme Frage am Rande: Wie performant ist eigentlich Core Data in Verbindung mit SQLite und einer Datenbank mit mehreren Tabellen zu je hunderttausend Datensätzen? Skaliert das auf dem Desktop gut?
     
  16. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    a) Core Data ist keine Datenbank (rDBMS)

    b) Es skaliert besser als jedes Model, welches du selbst programmierst.
     
    Bananenbieger gefällt das.
  17. Bananenbieger

    Bananenbieger Golden Noble

    Dabei seit:
    14.08.05
    Beiträge:
    24.567
    Deshalb ja auch "...in Verbindung mit SQLite" (rDBMS) ;)

    Danke, das wollte ich wissen.
     
  18. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.252
    Was Amin schreiben wollte: Core Data ist kein Framework zur Abfrage eines RDBMS, sondern ein ORM, das Objekte in (Relationale) Datenbanken (de)-serialisieren kann. Das hättest Du aber auch nachlesen können, wenn Du diesem Thread gefolgt wärest.
     
  19. Bananenbieger

    Bananenbieger Golden Noble

    Dabei seit:
    14.08.05
    Beiträge:
    24.567
    Spreche ich in Rätseln? ;)

    Ich weiß, was Core Data ist. Ich weiß, was SQLite ist. Ich wollte nur wissen, wie performant die ganze Sache bei großen Datenmengen in Kombination ist.
    Apple meint in den Core Data Docs nur "Core Data is a rich and sophisticated object graph management framework capable of dealing with large volumes of data. The SQLite store can scale to terabyte sized databases with billions of rows/tables/columns.", redet aber um den Brei herum, wenn es darum geht, wie gut das Ganze wirklich skaliert.
     
  20. sumpfmonsterjunior

    sumpfmonsterjunior Morgenduft

    Dabei seit:
    17.03.05
    Beiträge:
    167
    Lies Dir Amins Kommentar nochmals durch...
    Hast es doch selbst zitiert: es skaliert hervorragend auch mit riesigen Datenmengen.
    Probiere es aus, ich halte es für unwahrscheinlich, dass Du an Leistungsgrenzen stösst.
     

Diese Seite empfehlen