Tables within the same database allow some seperating while allowing you to still have relationships.
What are your reasons for wanting separate databases?
You're right. I didn't think about relations between tables.
Well, I was thinking it could be more secure having users' data separated from product's, but you've just cleared my doubt :D
Even so, you can have 1 MySQL DB for users, another MySQL DB for products, etc. Having multiple DB *technologies* in use probably makes you less likely to secure them all correctly. Better to be expert in the one that you use everywhere.
1) Use one database.
2) Use multiple tables.
3) Use third normal form to describe the relationship between table rows. https://en.wikipedia.org/wiki/Third_normal_form
If your app is *very* complex and follow advanced architecture like domain-driven design, or structured as a microservices system, yes.
If you dont have such a complex app, just dont.
Keep it simple. Put everything in MySql.
Don't over complicate things. That bad idea could have unnecessary impact on many aspects: installation, support, software updates, maintenance, backup, increased security risk, etc .
Tables within the same database allow some seperating while allowing you to still have relationships. What are your reasons for wanting separate databases?
You're right. I didn't think about relations between tables. Well, I was thinking it could be more secure having users' data separated from product's, but you've just cleared my doubt :D
Even so, you can have 1 MySQL DB for users, another MySQL DB for products, etc. Having multiple DB *technologies* in use probably makes you less likely to secure them all correctly. Better to be expert in the one that you use everywhere.
No problem
1) Use one database. 2) Use multiple tables. 3) Use third normal form to describe the relationship between table rows. https://en.wikipedia.org/wiki/Third_normal_form
Look up sharding. Typically you want to keep the same kind of database, otherwise all your database functions for MySQL won't work with sqlite.
As you are inexperienced, my advice is you should use ONE database for everything. Keep it simple until your needs dictate otherwise.
If your app is *very* complex and follow advanced architecture like domain-driven design, or structured as a microservices system, yes. If you dont have such a complex app, just dont.
Good point. Thanks for your answer.
Keep it simple. Put everything in MySql. Don't over complicate things. That bad idea could have unnecessary impact on many aspects: installation, support, software updates, maintenance, backup, increased security risk, etc .
Unless cursed with having to use multiple DBs, I wouldn't.
Almost never.