3 ms·
"if you want to avoid issues with table creation and migration, your choice should be NoSQL" Wow.
by henry2023 4y ago
"if you want to avoid issues with table creation and migration, your choice should be NoSQL"
Wow.
- prng2021 4y agoYea this stuck out to me too. Like.. what?
- TedDoesntTalk 4y agoBecause you can add arbitrary keys in a new release and there is no migration SQL needed like you would need to do if adding new database columns (or tables). The thing he missed is that you can implement arbitrary key/value pairs in a RDBMS table; you don’t need a NoSQL database necessarily: CREATE TABLE NAME_VALUE ID INT, NAME VARCHAR(32), VALUE VARCHAR(512); Querying on WHERE clauses with multiple keys/names can be tedious but works fine as long as performance is not your first priority.
- ramraj07 4y agoI still don’t understand it. You can add new columns in a new release and it should still work even with SQLite?
- TedDoesntTalk 4y agoPerhaps adding a column was not a good example, sorry.
- thealchemistdev 4y agoI have a json column specifically for things that are bound to change often like configs. If I need to add a config key, I just update the json.
- ramraj07 4y agoPoint likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.
- Timon3 4y agoThat's the part of NoSQL I've never understood. With a "normal" SQL DB my app has to be able to migrate between versions of data, but the code ever only supports the current version. With NoSQL, you will either have to support every possible version (which might be unique per entry), or implement migrations yourself. How is that not strictly worse?
- duxup 4y agoI think I know what he was saying, but it came out awkwardly.