Moin,

ich habe jetzt längere Zeit gesucht und leider keine praktikable Lösung gefunden, um sich aus Objective-C (OS X Applikation, nicht iOS) heraus mit einer MS SQL Datenbank zu verbinden. Das geht aus Java oder C# deutlich einfacher.
In dem Fall dachte ich an Plan B: MySQL. Aber selbst das scheint irgendwie nicht "einfach so" zu gehen sondern wieder nur über Umwege. Das kann ich aber irgendwie nicht glauben, es muss doch auch für Obj-C ordentliche Abstraktionen geben wie z.b. Hibernate. Gibt es hier ein wohlgehütetes Geheimnis?

Danke!

Das Cocoa Framework verfügt nicht über so etwas wie z.B. JDBC bei Java. Es bleibt die Client Library der jeweiligen Datenbank direkt anzusprechen oder halt ODBC. Das sind i.d.R. C/C++ APIs. Aber das geht ja von ObjC aus problemlos.

Ansonsten gibt es noch CoreData - da ist SQLite untendrunter.

Darüber hinaus mag es auch kommerzielle Anbieter von propritäre DB Frameworks für Cocoa/ObjC geben - damit habe ich mich aber noch nicht befasst.

1. MySQL hat eine C Client - Library. Die kann man auch aus Objective-C verwenden.

2. http://cocoapods.org/?q=SQL

3. Muss es den unbedingt eine SQL Datenbank sein. Wenn Du Macs als Client verwenden willst, ist vielleicht eine Datenbank, die sich einfach über HTTP ansprechen lässt, die bessere Wahl (CouchDB, Riak, etc.) TouchDB sollen ja eigene Leute mit CouchDB ganz erfolgreich einsetzen. (https://github.com/couchbaselabs/TouchDB-iOS).

wie meine Vorredner schon sagten, gibt es leider keine "Apple" Lösung dafür. Aber es ist ziemlich leicht, MySQL über den Connector anzusprechen. Doku & download hier: http://dev.mysql.com/downloads/connector/c/

Wenn die DB nur für die eigene Anwendung ist, dann würde ich lieber CoreData nutzen. Gibt im Netz viele Tutorials dazu!

CoreData ist vom Konzept der letzte Rotz. Langsam, umständlich, unflexibel, steile Lernkurve für nix. Würde ich schön die Finger von lassen.

Nimm lieber http://realm.io oder https://github.com/yaptv/YapDatabase.

Ja, deine Lernkurve kommt bei CoreData wirklich nicht mit.
Schon weil du nicht begriffen hast, dass CoreData keine Datenbank sondern ein ORM ist.
Ich finde CoreData und andere ORMs sind die einzig ware Art sich den unsäglichen SQL-Datensenken zu nähern.
CoreData rockt und das im Prinzip schon seit WebObjects.

schau mal hier wenns unbeding MSSQL sein muss

Sonst gibt's auch noch die Möglichkeit direkt auf SQLite (die übliche CreData Datensenke)zuzugreifen FMDB :
Zudem würde ich dazu tendieren Datenbanken über "definierte" Platformunabhängige Services von mobile aufzurufen (e.g. SOAP z.B. via SharePoint) oder Rest, ... mindestens aber über ODBC.

@strife
Was für ein dummes Geschwätz!

strife
Es ist definitiv erforderlich, sich mit CoreData auseinanderzusetzen bevor man es nutzt. Sonst fällt man auf ziemlich viele Sachen rein und erreicht keine akzeptable performance. Wenn man weiss wie man es nutzen sollte ist die performance absolut in ordnung.

Das wäre ja fast lustig, wenn es nicht so traurig wäre wieviel Zeit meines Lebens in ich den letzten Jahren mit CoreData verschwendet habe.

Und weil ich keine Ahnung von ORMs habe empfehle ich Realm und YapDB? Ich glaube, jemand anders hier guckt nicht über den Tellerrand.

Aber einer bestimmten Datenmenge ist das Teil einfach nicht mehr zu gebrauchen. Schon allein SQLite3 is einfach zu langsam, und CoreData obendrauf macht die Sache nicht besser.

Schau mal hier bei Seite 5: https://raw.githubusercontent.com/facebook/rocksdb/gh-pages/intro.pdf

Einfach ALLES ist schneller als SQLite.

strife
Du musst halt wissen wofür du es einsetzt. Wenn du das letzte Quäntchen an Performance brauchst bist du bei CoreData definitiv falsch.

+1

Mendel Kucharzeck
Es ist ja nicht nur die Performance. Es ist das ganze Konzept von CoreData, dass nicht richtig zu Objective-C zu passen scheint.

Warum brauche ich eine extra Schema Datei, wenn man die Information zur Laufzeit aus der Runtime bekommt (siehe Realm.io)?
Warum ist der Stack so überfrachtet (NSPersistentStoreCoordinator, NSPersistentStore, NSManagedObjectContext) ?
Warum funktioniert Synching über iCloud nur ordentlich über Umwege wie Ensembles.io?
Warum kann man einen Datenbestand nicht auf ein altes Schema zurück migrieren?
Warum ist das Threading Model so kompliziert?

... und und ...

CoreData ist eines der enttäuschendes Frameworks von Apple. Wenn man wenig Daten hat, und es eigentlich nicht bräuchte, dann ist es ganz ok, aber sobald das Schema komplexer wird und mehr Daten vorhanden sind, dann geht der Krampf los.

Das heißt also, dass realm und yap das alles von Haus aus können und der Entwickler nichts weiteres tun muss?

Duck Dockers
Alles kriegen diese Projekte auch nicht gelöst, aber ein paar Sachen sind schon wesentlich besser: Der Zwang zur extra Schema Datei entfällt, man braucht nicht mehr so viel Boilerplate Code um eine App an den Start zu bringen.

Yap nutzt noch SQLite als Backend, dürfte also nicht viel schneller als CoreData sein. Realm behauptet , wesentlich schneller als CoreData zu sein. Ich habe das nicht überprüft, aber ich halte das für sehr wahrscheinlich.

CoreData orientiert sich aufgrund seines EOF Hintergrunds an SQL-basierten Servern. Den NoSQL Zug, auf den die Serverwelt schon längst aufgesprungen ist, hat Apple wohl verpennt.

Naja schön, dass du Yap und Realm so anpreist, aber (wie du selber sagst) kannst du gar nicht beurteilen, wie viel einfacher und schneller das ist!! Sorry gerade deshalb kann ich deine erste PAUSCHALE Aussage absolut nicht nachvollziehen. CoreData hat wie jede andere DB sein Berechtigung ...

Duck Dodgers
In unserer Firma haben wir unsere eigenen CoreData Ersatz, alá Realm, auf Basis von Googles LevelDB Bibliothek im Einsatz.

Deshalb kann ich zur Realm im Speziellen nichts sagen. Da es aber vom Konzept unserer eigenen Bibliothek sehr ähnlich ist, wird es wohl ebenfalls um Längen besser zu Benutzen sein als CoreData.

Was ich aber sagen kann, ist das CoreData dermaßen altbacken ist, dass man damit nicht mehr seine Zeit verschwenden sollte.

wird wohl