Discussion :

[Fooshi]

Bonjour,
J'ai un projet de développement d'une application mobile, c'est un projet personnel, le business plan est fait et j'attend beaucoup de cette application.
Elle sera développée sur IOS et Android en natif (Swift / Kotlin).
J'attend à ce qu'il y ait beaucoup d'utilisateurs, car je souhaite la déployer dans plusieurs pays et disponible en plusieurs langues. Il faudra donc que mon choix soit scalable.

Maintenant il me reste le choix de la base de donnée :

3 choix s'offrent à moi :

- MySQL
- Firebase Realtime Database
- Cloud Firestore

Je n'arrive pas à me decider car :

- MySQL :
* Avantages :
- Je connais très très bien, le développement se ferais en PHP que je connais très bien aussi
- Je suis à l'aise avec les structures relationnelles
* Inconvénients :
- Je ne peux que m'offrir un hébergement mutualisé qui ne sera pas potentiellement adapté à des montée en charge importante
- Je suis tout d'abord développeur donc le coté infra je ne maitrise pas trop
- Il faut développer tous les Webservices, le cout de développement serais donc plus long et la maintenabilité très importante

- Firebase Realtime Database :
* Avantages :
- Efficace
- Produit mature
- Pas de Webservices à développer
- Moins de maintenabilité / Pas de serveur
* Inconvénients :
- Scalabitilé pas forcément automatique
- En cas de migration de structure NoSQL me parait compliqué
- Cloud Firestore :
* Avantages :
- Apporte plus de fonctionnalité que Firebase
- Me semble plus simple à mettre ne place que Firebase
- Semble meilleur sur le papier que Firebase
- Pas de Webservices à développer
- Moins de maintenabilité / Pas de serveur
* Inconvénients :
- Version beta !
- Moins rapide ?
- En cas de migration de structure NoSQL me parait compliqué

Je vous met le lien du comparatif Google entre RTDB et Firestore :
https://firebase.google.com/docs/dat...b-vs-firestore

Qu'en pensez-vous ? Quel serait votre choix ?
En vous remerciant

[SQLpro]

Si vous voulez réellement qu'elle soit internationale et donc en plusieurs langues il vous faut un support efficace des collations. Aucun des SGBD que vous présentez ne les supportent correctement.
Le seul SGBDR qui supporte correctement les collations pour le multilingue est SQL Server.

A +

[Fooshi]

Concernant le multilingue, je ne souhaite pas le porter par la BDD, car je n'en aurais pas l'utilité à ce niveau la.
Si utilisation de firebase, je pensais utiliser le stockage firebase pour porter un json.

[StringBuilder]

Pour l'exécution demain, vous préférez :
- Être écartelé ?
- Être écorché vif ?
- Être roué de coup ?

Pour la partie embarquée, choisissez le seul SGBD qui tourne "vraiment partout", à savoir SQLite.
Pour la partie serveur, SQL Server est certainement le meilleur choix. A défaut, PostgreSQL pourrait tirer son épingle du jeu, cependant avec d'immenses limitations comparé à SQL Server.
Si vous comptez y passer le budget de votre famille et de vos descendants sur les 50 prochaines générations, vous pouvez aussi tenter l'aventure Oracle.

[Fooshi]

Ca fais quand meme mal 384 € par mois pour un serveur SQL Server sur OVH :
https://www.ovh.com/fr/serveurs_dedi...sql_server.xml

[StringBuilder]

Pourquoi partir d'emblée vers :
- Une solution externalisée ?
- Une version standard là où une Web ou même Express peut éventuellement faire l'affaire dans un premier temps ? https://www.microsoft.com/en-us/sql-...-2017-editions
- Quitte à prendre une version Standard, pourquoi partir sur de la location quand un achat coûte moins de 10 mois ? https://www.microsoft.com/fr-fr/sql-...r-2017-pricing
- Quitte à externaliser quand la base va prendre de l'ampleur, pourquoi pas vers Azure qui revient rapidement moins cher ? (pour à prine plus cher on a 8 cœurs et 44 Go de RAM par exemple) https://azure.microsoft.com/en-us/pr...abase/managed/

Bref, avec SQL Server qui tourne maintenant sous Linux, on peut héberger une base SQL Server 100% gratuitement maintenant…