Welche Datenbank und welcher Host?

Schön, dass Du Deine Anforderungen relativ gut umrissen hast, sonst hätte ich geschrieben "Nimm ne AS/400, ne geilere Datenbank gibt's nicht."

Für dein Vorhaben wäre das allerdings ungefähr so wie mit einer 50m-Luxus-Yacht durch einen dünnen Seitenarm der Donau zu schippern...

Anyways.
SQLite ist sowohl komplett richtig für dich als auch total die falsche Wahl.
Die Frage ist halt das 'wo'.

Auf dem Android Gerät kommst du nicht um eine SQLite Datenbank herum. Alles Andere wäre jedenfalls hochgradiger Implementierungs-, Test- und Resourcenaufwand.
Für die iPhone App würde ich von SQLite die Finger lassen und Core Data nehmen. Alles Andere wäre jedenfalls hochgradiger Implementierungs-, Test- und Resourcenaufwand.
Diese Datenbanken solltest du regelmäßig mit der Datenbank deines Servers synchronisieren.
Ich persönlich halte jedenfalls nix von Apps mit permanenter Internetverbindung.

Auf einem Server fällt SQLite einfach aus. Es ist ein dateibasiertes Datenbankmanagementsystem, das heißt, es kann maximal eine Person zur Zeit auf die gesamte Datenbank zugreifen - lesend wie schreibend. Bei größeren SQL Datenbanken hingegen können mehrere Leute gleichzeitig lesend nicht nur auf eine Datenbank sondern sogar auf eine Tabelle zugreifen. Schreiben kann natürlich nur einer zur Zeit. Doch dafür gibt es ja glücklicherweise Transaktionen, von denen du rege Gebrauch machen solltest.

Dabei ist es egal, ob das jetzt MySQL, MaxDB, MSSQL, Oracle SQL oder PostgreSQL wird. Hat alles seine Stärken und Schwächen.
Was das kostet hängt stark vom Hoster ab. Und er Hoster hängt stark von der bevorzugten Datenbank ab. Allerdings gibt es von 'für lau' über 2€/Monat bis hin zu ein paar Hundert im Jahr so ziemlich alles. Es ist auch eine Frage des Services, den man wünscht.
Am Verbreitesten ist all-inkl.com mit 4,95€/Monat, soweit ich informiert bin.

Hoi,

ich persönlich finde folgenden Weg sinnvoll/gut:

Ich stelle vom Android-Device aus eine Anfrage an ein PHP-Formular, das auf meinem Server mit Apache2 und PHP5 liegt. Das Formular holt sich Daten aus der MySQL Datenbank. Die Datenbank sollte nicht von aussen, also öffentlich, zugreifbar sein. (bind-address)
Das Formular verarbeitet die Daten bzw. packt sie in ein brauchbares Format wie z.b. JSON und schickt sie als Antwort ans Android-Device. Das Android-Device verwurstet die Daten und speichert sich mal pauschal alles in einer SQLite DB zwischen.
Gearbeitet wird dann lokal mit der SQLite Datenbank.

Hat den Vorteil, dass du deine MySQL Datenbank nicht öffentlich und angreifbar im Netz stehen hast. Es werden nicht zich Connections geöffnet, weil die Clients (Android-Devices) direkt auf die DB wollen und du kannst dein PHP-Script auch noch mit .htaccess und .htpasswd steuern und absichern. Auch umgehst du unschöne Dinge wie nicht sauber geschlossene Connections, wenn die Android-Devices aufgrund von Netzschwankungen die Verbindung verlieren.

Lokales Zwischenspeichern finde ich wichtig, da der Benutzer dann im Falle Offline trotzdem noch ein paar Daten hat, wenn auch nicht die Aktuellsten. Besser als eine komplett leere App ohne jeglichen Inhalt.

Zum grundsätzlichen Verständnis MySQL und SQLite:

SQLite ist dafür ausgelegt, lokal für einen Benutzer eine Datenbank zur Verfügung zu stellen, ohne dass dieser erstmal einen MySQL Server installieren muss. Du kannst also Anwendungen direkt mit Datenbank ausliefern und musst nicht erst Einrichtungsaufwand bzgl. Datenbank leisten. Das ganze wird natürlich sinnlos, wenn du das alles nicht lokal für nur einen Benutzer willst sondern eben für mehrere Benutzer zentral. Dann brauchst du einen richtigen Datenbank-Server.

Anstatt "MySQL" kannst du natürlich auch Alternativen, wie von Lucas genannt, verwenden. Ich persönlich bin mit MySQL aber sehr zufrieden, weshalb ich noch nicht zu anderen DB-Servern gegriffen habe.

Gruß,
matze

Zitat von Wrigley

SQLite wird also bei Android als Abfragesprache verwendet.

SQLite ist nur das Datenbanksystem. Genauso wie MySQL und alles andere. Ein System, in dem die Daten gespeichert werden. Wie dieses System das macht kann dir (fasst) egal sein.

SQL ist hier die Abfragesprache. Du machst auf deinem Server eine MySQL Datenbank. Dort speicherst du alle Daten, sodass jeder von dort immer die aktuellsten Daten bekommt.

in deine Android APP machst du eine SQLite Datenbank. Diese Datenbank ist nur für deine Android App und jeweils immer nur für den jeweiligen App Nutzer Individuell.
Du musst deine App so schreiben, dass sie ihre lokale SQLite Datenbank mit der Zentralen MySQL Datenbank auf deinem Server synchronisiert.
Also sobald sie gestartet wird, guckt sie erstens ob eine Internetverbindung vorhanden ist und dann guckt sie ob es etwas neues in der Zentralen MySQL Datenbank auf dem Server gibt. Wenn ja, dann kopiert sie die neuen Sachen in die lokale SQLite Datenbank in der App.

SQLite in der App, weil Android das mitliefert und es recht einfach ist.

MySQL auf dem Zentralen Server, weil mehrere Personen dann gleichzeitig die Daten von dort Abrufen bzw. bearbeiten können.

Hey Wrigley,

du musst dir den Server und die App losgelöst voneinander vor Augen halten.

Wie viele Leute nutzen deine App? Sicherlich mindestens 28.000.000. Das will doch jeder erreichen.
Doch: wie viele Leute nutzen deine App je Gerät?
Bei dem Spreadsheet ist das schwer zu sagen, aber da alle Browser vermutlich auf ein und dasselbe Dokument zugreifen werden rechnen wir mal ganz optimistisch geschätzt mit 28.000.000 Nutzern, die gleichzeitig auf das Dokument zugreifen.
(Sollte das passieren, plane lieber ein paar Tausend Euro mehr für das Datenbankhosting ein. +scnr+)

Natürlich haben alle 28.000.000 Nutzer auch eine App für iPhone oder Android.
Und hier ist dann der Knackpunkt. Wie viele Nutzer hast du pro iPhone/Android? Exakt: 1 Nutzer. Ein Einziger. In Worten: eins.

Auf dem Server mit 28.000.000 Nutzern fliegt dir die SQLite Datenbank im Idealfall jede Nanosekunde drei mal um die Ohren. Auf den Geräten mit einem Nutzer im Idealfall nie (Man muss es natürlich richtig implementieren, damit nix abschmiert. Ich hätte mich bei Android früher mit den Content Providern auseinandersetzen sollen. +husthust+)

Deshalb hast du auf dem Server eben eine vernünftige Multiuser-Datenbank laufen.
Wie du DIE jetzt einstellst, DAS wird spannend für die Zukunft. Du könntest alles mit einem User machen. Das würde ich nicht tun. Denn ein User kann maximal 1x pro Tabelle agieren, der Gewinn ist nicht viel höher als bei SQLite.
Du könntest für jeden Nutzer einen Datenbankuser anlegen. Dann hast du einen ungeheuren Verwaltungsaufwand aber unglaublich gut granulierte Zugriffs- und Sicherheitsoptionen und jeder könnte prima in deiner Datenbank agieren. Gut, beim Schreiben von Daten kann es unter Umständen zu Problemen kommen, doch die dürften unglaublich selten auftreten.

Der Mittelweg wäre ein User je Gruppe. Wir hatten jetzt drei Gruppen definiert. Webuser, iPhone User und Android User. Nun hast du deine 28.000.000 Nutzer in drei Gruppen geteilt: Web mit 28.000.000, Android mit 21.000.000 und iOS mit 7.000.000 Nutzern.

Puh, das war harte Arbeit.
Und wir haben ein Problem...
Wir haben eine MySQL Datenbank im Netz, auf die dein SpreadSheet zugreift.
Und wir haben 28.000.000 Datenbanken auf mobilen Endgeräten, auf die je eine installierte App zugreift.
Wie kommen jetzt die Daten vom Einen zum Andern?

Dafür ist es zunächst wichtig zu wissen, was genau wie und wo bearbeitet werden soll.
Sind die Smartphone Apps nur für den lesenden Zugriff gemacht und im SpreadSheet wird eingetragen, dann ist es weniger eine Synchronisation als viel mehr ein Datendownload. Der von [matthias] und [Funtik] umrissene Ansatz funktioniert da schon sehr gut.
Eventuell gehst du sogar noch einen Schritt weiter und lässt zu festen Zeiten einfach die Daten vom Server exportieren, so dass die Geräte gar nicht an die Informationen in der Datenbank ran müssen.
(Meinetwegen ein Veranstaltungskalender. Der muss ja nicht minütlich aktualisiert werden. Vor Allem, wenn Änderungen anderweitig zur Verfügung gestellt werden reicht auch einmal täglich. Oder finale Spielauswertungen sind nur nach dem Spiel sinnvoll, müssen also nur ein einziges Mal bereit gestellt werden. Je nach Anwendungsfall)

Vermutlich möchtest du aber, dass auch die Apps in die Datenbank auf dem Server schreiben können.
Hier kommt dann Musik ins Spiel, denn das wird alles Andere als trivial.

Erstens ist JSON, SOAP, REST, XML und keine Ahnung was noch alles ein relativ großer Datenhaufen. Für (nahezu) Echtzeitsynchronisation wird das extremer Overhead.
Zweitens wirst du bei 28.000.000 Usern 19 Stunden am Tag kaum was bekommen und an 5 Stunden überschlagen sie sich fast gleichzeitig mit Einträgen.
Du musst also nicht nur dafür sorgen, dass diese Eintragungen allesamt fehlerfrei durchgehen (Transactions!!!) sondern musst dir auch überlegen in welchem Intervall die Daten auf den Endgeräten aktualisiert werden sollen. Vielleicht wenn eine Minute lang keine Einträge mehr kamen und mindestens 10 Änderungen einflossen eine Push Notification senden oder sowas...
Sagte ich schon, dass Echtzeitsynchronisation alles Andere als trivial ist?

Wie dem auch sei, fang einfach mal an. Datenbank erstellen, Ansteuerungsskript(e) erstellen und mal ein bisschen herumspielen.
Die Komplexität und Probleme kommen dann später von ganz allein. Ich hoffe, ich konnte dir ein bis drei kleine Stolpersteine aufzeigen, auf dass du sie nachher identifizieren kannst, wenn du über sie gefallen bist.

Hoi,

sorry, wenn ich dich etwas erschlagen hab mit PHP-Scripten etc mir fällt es leicht und ich find es bis dato gut gelöst, deshalb hab ichs dir mal vorgeschlagen.

Zum Anderen:

Zitat von Wrigley

Besser wäre es natürlich wenn der App Bescheid gegeben würde, wenn Datensätze in der Datenbank geändert wurden.

Könnte man jetzt am Ende des Scripts oder des Mechanismus, mit dem du da neue Daten rein schreibst eine Push-Notification senden. Die schlägt auf deinem Receiver auf, du zeigst keine Notification an sondern pullst dir daraufhin neue Daten. Also Server sendet "hol dir updates" und die Clients gehorchen
Wär dann C2DM, ist was für später mal, wenn dein erstes Test-Szenario steht. Ich hab mich mit Push-Notifications etwas schwer getan und seit einem Jahr nicht mehr berührt ... vll. hat sich das schon etwas gebessert.

Gruß,
matze