Core Data vs. SQLite, Geschwindigkeitsvergleich

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

    • Core Data vs. SQLite, Geschwindigkeitsvergleich

      mal nebenbei, ein Geschwindigkeitsvergleich von Core Data vs. SQLite -> auf der zweiten Seite dann die Ergebnisse

      ich habe leider keine Zeit, mir das ganze genauer anzugucken.
      Vielleicht hat ja einer der Core Data Profis Lust sich das genauer anzugucken, ob irgendwelche Haken oder Fehler dabei gemacht worden sind.

      In jedem Fall scheinen die ganzen Vorteile Core Data nicht viel an Geschwindigkeit zu kosten (eher sogar schneller als direkt über die Standard sqlite-bibliothek)
    • SteveJ schrieb:

      kmr schrieb:

      In der Regel weist CD zur Entwicklungszeit erhebliche Geschwindigkeitseinbußen auf


      Weil? Du kriegst ja praktisch den halben Model-Layer geschenkt...


      Weil der konzeptionelle Einstieg nicht der leichteste ist. Das nächste Forum-T-Shirt könnte den Slogan "Core Data ist keine Datenbank" tragen. ;) Wenn man's einmal kapiert hat, ist CD eine gute Sache, keine Frage.
    • Dann arbeite mal in komplexen Anwendungen mit SQL - nicht umsonst sind im JEE-Bereich Tools wie Hibernate oder EclipseLink Standard. CoreData/SQLite als "EOF light" ist halt weniger flexibel als sein Väterchen, aber was nicht ist, kann ja noch werden. Damit meine ich die Anbindung an DB's wie MySQL oder kommerziell Oracle, Sybase, SQLServer, Der große Unterschied zu EOF bei CD ist, dass Du keinerlei Kontrolle über das Mapping der Klassen auf die DB hast. Wer EOF mal ausprobieren möchte, dem empfehle ich folgende freie Implementierung - Apple hat das Framework ja verschwinden lassen:

      github.com/tdmartin102/ajrdatabase

      Als DB kann man sehr gut Oracle unter Linux in einer VirtualBox laufen lassen, die VM's der Oracle Developer Days sind ein guter Startpunkt.
    • ajrdatabase hat zumindestens einen Adaptor für Postgres, der aber wohl einen unklaren Zustand hat. Ich nehme halt gern Oracle, weil der Adaptor funktioniert , ich es auch beruflich nutze und durch die VB eben keine zusätzlichen Dienste auf meinem iMac laufen habe.
      Und immer im Kopf behalten - objekt-relationale Mapping-Tools sind so, als wenn man jeden Abend von der Arbeit nach Hause kommt, sein Auto in Einzelteile zerlegt und in Fächer in der Garage ablegt. Und am Morgen wieder der umgekehrte Vorgang. ;)
    • WernerB schrieb:


      Und immer im Kopf behalten - objekt-relationale Mapping-Tools sind so, als wenn man jeden Abend von der Arbeit nach Hause kommt, sein Auto in Einzelteile zerlegt und in Fächer in der Garage ablegt. Und am Morgen wieder der umgekehrte Vorgang. ;)
      Ich habe lange mit EOF und auch anderen OR-Mappern gearbeitet. Diese Aussage verstehe ich trotzdem nicht.
      „Meine Komplikation hatte eine Komplikation.“
    • Eigentlich ist der Übergang objektorientierte Welt zu relationalen DB's ein Bruch. Schau Dir mal ein OODBMS an - wenn die auch, wie Versant, ihre API's als ORM-Tool anbieten.Das Problem ist, dass die relationalen DB's so ausgereift und damit schnell sind, dass man OODBMS, wenn überhaupt, nur in Bereichen wie (Telefon-)Netzverwaltung antrifft.
      Mein Hinweis auf Oracle bezog sich darauf, dass im ajrdatabase-Framework der Postgres-Adapter einen unklaren Zustand besitzt, "maybe broken". So lange man nur spielen will, reicht mir da VB mit Oracle.