Konzeptionelle Frage: Zentrale Datenbank und Client-App

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

  • Konzeptionelle Frage: Zentrale Datenbank und Client-App

    Liebes Forum,

    rein konzeptionell gefragt: Ich möchte eine zentrale Datenbank auf einem Webserver erstellen, die ich
    1) mit einer Backend-App befüllen möchte und
    2) von der ich Daten abrufen möchte im Kontext einer Client-App (das ist letztlich das Produkt)

    Welche Werkzeuge / best-practice-Beispiele empfehlt ihr?

    Ich würde gern mit Swift arbeiten: Backend-App soll eine OSX-, die Frontend-App eine iOS-App werden.

    Persönlich habe ich etwas Erfahrung mit mySQL und hatte die Hoffnung, auf eine entsprechende Datenbank direkt zugreifen zu können. Auf meiner Recherche habe ich aber nichts entsprechendes finden können und bin oft über den Zwischenweg von Webservices/APIs gestolpert. Ich verstehe auch deren Berechtigung, suche an dieser Stelle jedoch nach einer möglichst einfachen Lösung - ich bin kein herausragender Programmierer - und mein Anwendungskontext ist nur für mich, nicht für Kunden o.ä.

    Dank vorab für eure Beitrage,
    viele Grüße

  • Was spricht gegen einen Webservice?

    Bei fast allen Hostern ist der Zugriff von "außen" auf eine MySQL-DB nicht möglich. Diese ist nur über localhost erreichbar und das ist auch gut so.
    Natürlich kann man das ändern und die DB auch von "außen" erreichbar machen. Hier spielt aber der Aspekt Sicherheit eine große Rolle. Man müsste die Zugangsdaten in der App (Backend und Frontend) speichern. Dieses zu "knacken" ist fast ein Kinderspiel.

    Auch wenn es nur für Dich selbst ist, würde ich die Variante mit einem Webservice in jedem Fall bevorzugen. Den Webservice zu schreiben, z.B. in PHP, ist auch nicht schwieriger als eine direkte Connection zur DB, im Gegenteil, wie ich finde.
    Ich bin gegen Signaturen!!!

  • beage schrieb:


    Auch wenn es nur für Dich selbst ist, würde ich die Variante mit einem Webservice in jedem Fall bevorzugen. Den Webservice zu schreiben, z.B. in PHP, ist auch nicht schwieriger als eine direkte Connection zur DB, im Gegenteil, wie ich finde.
    Ich empfand einen Webservice als zusätzlichen Aufwand, den ich nicht zwingend betreiben wollte - offenbar ist er aber unumgänglich. Außerdem wollte ich nicht noch ein Thema starten, bei dem ich mich auf fachlich unsicherem Terrain bewege.

    Wie muss ich mir einen Webservice vorstellen? Meine Backend-App authentifiziert sich gegenüber einem PHP-Script, welches mir daraufhin Daten bspw. als JSON zurückgibt bzw per post-request Daten in die mySQL speist? Hat da evtl. jemand ein einfaches Beispiel parat mit einer niederkomplexen Datenbank?

  • Weder noch. Hintergrund ist einfach, dass wir auf den Servern selbst kompilieren. Aber das wird sich demnächst ändern und man kann auch Binaries hochladen. Und die kann man ja kompilieren aus was man möchte. Es ginge natürlich jetzt schon, wenn man seinen Swift-Code in Frameworks kompiliert. Aber das will man niemanden als Lösung vorschlagen.

    Ganz ohne Objective-C geht es natürlich nicht, da Swift nicht so funktioniert.

    .9 wird allerdings bleiben, bis .11 stabil ist. Ein Umstieg auf .10 wird es nicht geben. (Es sei denn, es passiert etwas ganz Unerwartetes.)
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    .9 wird allerdings bleiben, bis .11 stabil ist.
    Also ungefähr zur WWDC 2016…

    Meine Erfahrung mit datenbanklosen Datenbanken +ähm+ wie CouchDB sind auch nicht sehr weitreichend.
    Allerdings habe ich Transactions lieben gelernt. Wie konkurrierender Zugriff auf CouchDB 'Tabellen' sinnvoll realisiert werden kann, habe ich bis dato nicht herausgefunden.
    Aus gleichem Grund würde ich auch SQLite vermeiden. Auf Grund der Dateibasis ist das super bei genau einem Anwender, also beispielsweise auf dem Phone oder lokalen Apps.
    Bei zwei gleichzeitigen Zugriffen kann aber immer nur einer irgendwas machen – im Gegensatz zu MySQL wird mit einem Zugriff auf SQLite gleich die gesamte Datenbank blockiert.

    Insofern nimm mal MySQL und einen WebService.
    Sieh den WebService einfach als eine Abstraktionsebene. Wenn Dir MySQL irgendwann mal auf den Sack geht und Du wechselst zu PostgreSQL, MongoDB, IBM i5 oder sonstwas, bleibt Deine App davon völlig unberührt. Du musst lediglich den WebService anpassen. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • SteveJ schrieb:

    Marco Feltmann schrieb:

    Allerdings habe ich Transactions lieben gelernt. Wie konkurrierender Zugriff auf CouchDB 'Tabellen' sinnvoll realisiert werden kann, habe ich bis dato nicht herausgefunden.
    How do I use transactions with CouchDB?

    Nicht, dass du das jetzt machen sollst - nur zur Info.
    Optimistic Locking ist aber leider noch meilenweit von Transaktionen entfernt, da du damit im Allgemeinen keine Atomarität sicherstellen kannst. Eine Aufgabe mit zwei oder mehr schreibenden Operationen lässt sich über Optimistic Locking jedenfalls nicht absichern.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Eine Aufgabe mit zwei oder mehr schreibenden Operationen lässt sich über Optimistic Locking jedenfalls nicht absichern.

    Nö, so was willst du ja auch nicht. Client 1 lockt eine Tabelle, schreibt einen Eintrag und verliert die Verbindung, während er die zweite Operation durchführen will Client 2 wartet jetzt auf das Timeout...

    RDBMS ist keine schlechte Technik, das will ich damit nicht sagen. Die meisten Anwendungen brauchen die Skalierbarkeit der NoSQL-Datenbanken ja auch nicht. Und sogar auf dem Server ist SQLite oft ausreichend:

    sqlite.org/whentouse.html

    Das Geschäftsmodell mit Objective-C eine PostgreSQL-Datenbank ansprechen zu wollen erschließt sich mir allerdings nicht so ganz...

  • SteveJ schrieb:

    Nö, so was willst du ja auch nicht. Client 1 lockt eine Tabelle, schreibt einen Eintrag und verliert die Verbindung, während er die zweite Operation durchführen will Client 2 wartet jetzt auf das Timeout...
    Weder Optimal stic Locking noch Transactions haben etwas mit Tabellen- oder gar Datenbanklocks zu tun. Explizite Locks braucht man im Vergleich zu Transaktionen auch relativ selten in der Praxis.

    Optimistic Locling kannst im Prinzip auf jedem Datenbanksystem durchführen, das Updates mit Bedingungen erlaubt. Das ist die allereinfachste Strategie, konkurrierende Zugriffe ohne Transaktionen abzusichern, und einige OR-Mapper wie beispielsweise EOF bieten das frei Haus.
    „Meine Komplikation hatte eine Komplikation.“