Je cherche à réécrire une application VB basée sur site (installée localement) (facturation + inventaire) en tant qu'application Web Clojure pour les petites entreprises. Je prévois que cela soit offert en tant qu'application SaaS pour les clients dans un commerce similaire.
Je cherchais des options de base de données: Mon choix était un SGBDR: Postgresql / MySQL. Je pourrais faire évoluer jusqu'à 400 utilisateurs la première année, avec généralement 20 à 40 pages vues / par jour et par utilisateur - principalement pour les transactions et non les vues statiques. Chaque vue impliquera la récupération de données et la mise à jour de données. La conformité à l'ACID est nécessaire (ou du moins je pense). Le volume de transactions n'est donc pas énorme.
Cela aurait été une évidence de choisir l'une ou l'autre de celles-ci en fonction de mes préférences, mais pour cette seule exigence, qui je pense est typique d'une application SaaS: le schéma changera à mesure que j'ajouterai d'autres clients / utilisateurs et pour chaque client. l'évolution des besoins de l'entreprise (je n'offrirai une flexibilité limitée que pour commencer). Comme je ne suis pas un expert DB, sur la base de ce que je peux penser et lire, je peux gérer cela de plusieurs manières:
- Avoir une conception de schéma RDBMS traditionnelle dans MySQl / Postgresql avec une seule base de données hébergeant plusieurs locataires. Et ajoutez suffisamment de colonnes "flottantes" dans chaque table pour permettre des modifications futures à mesure que j'ajoute des clients ou des modifications pour un client existant. Cela peut avoir un inconvénient de propager les modifications apportées à la base de données chaque fois qu'une petite modification est apportée au schéma. Je me souviens d'avoir lu que dans Postgresql, les mises à jour du schéma peuvent être effectuées en temps réel sans verrouillage. Mais je ne sais pas à quel point c'est douloureux ou pratique dans ce cas d'utilisation. Et aussi, car les modifications de schéma peuvent également introduire des modifications SQL nouvelles / mineures.
- Avoir un SGBDR, mais concevoir le schéma de base de données de manière flexible: avec une valeur d'attribut d'entité proche ou simplement comme un magasin de valeurs-clés. (Workday, FriendFeed par exemple)
- Ayez le tout en mémoire en tant qu'objets et stockez-les périodiquement dans des fichiers journaux (par exemple, edval, lmax)
- Optez pour une base de données NoSQL comme MongoDB ou Redis. Mais d'après ce que je peux comprendre, ils ne conviennent pas à ce cas d'utilisation et ne sont pas entièrement conformes à ACID.
- Optez pour des DBS NewSQL comme VoltDb ou JustoneDb (basé sur le cloud) qui conservent le comportement conforme à SQL et ACID et sont des SGBDR "nouvelle génération".
- J'ai regardé neo4j (graphdb), mais je ne sais pas si cela conviendra à ce cas d'utilisation
Dans mon cas d'utilisation, au-delà de l'évolutivité ou de l'informatique distribuée, je cherche une meilleure façon d'obtenir une "flexibilité dans le schéma + ACID + des performances raisonnables". La plupart des articles que j'ai pu trouver sur le net parlent de flexibilité dans le schéma comme une cause conduisant à la performance (dans le cas des bases de données NoSQL) et à l'évolutivité tout en omettant le côté ACID / Transactions.
S'agit-il d'un cas «soit ou» de transactions «flexibilité du schéma vs ACID» ou existe-t-il une meilleure solution?