3 ms·
I'd think the correct solution is better project/product management, but as I know that isn't always an option... Overall, given the information I am not sure
by davismwfl 8y ago
I'd think the correct solution is better project/product management, but as I know that isn't always an option...
Overall, given the information I am not sure NoSQL is the right path, but there are some inherit flexibilities it gives you with a constantly evolving data model. But that doesn't come for free, and your coding has to evolve to support a dynamic data model which can be challenging on its own.
Simply based on your limited description, I'd avoid Cassandra, not because it isn't awesome, but your use case doesn't seem to fit. Plus with mostly newbies and skeptics it would most likely fail in implementation. Cassandra requires a lot of design planning up front in general to get it right, it is not the most flexible of the NoSQL alternatives in terms of dynamic data model and querying, but it provides other trade offs that make it a great tool.
You can stick with SQL and just use a data migration toolset to help you manage field updates etc. Set a policy for allowing additions but restrict column removals etc. It has been done for years as this isn't a new problem, just means you have lots more to manage and data migrations become a key aspect, so data access code also needs to be isolated and flexible.
Alternatively you could still use something like Postgres or MySQL and properly use JSON storage and index it which would let you have some benefits of NoSQL without moving the entire app. For those tables you can define well, do so in proper sql, those you can't do so in JSON storage.
And of course you could move more to a full NoSQL solution using something like Mongo. Mongo is solid if used properly, but again comes with some trade offs, so you'd have to evaluate those.
Personally, depending on how much data exists already and how complex the app is at this stage, I'd opt for pushing back on project management some and/or moving to a more toolset driven SQL solution with planned data migrations as part of your sprints. That plus make sure you add a flexible data access layer to isolate the changes to the application as best as possible. If you or someone on the team had more NoSQL experience or even a different team makeup my recommendations might differ.