Great tutorial, you're very knowledgeable! Love the integration that's almost as easy as tapping into SQLite. Do you have a series on Python with Postgres too?
You didn't say anything negative about non sql databases. If you are dealing with small lists then it doesn't matter. You can use text files, but if you end up with hundreds of thousands of items or millions then performance can become a problem. You say non sql is more scaleable. Could you explain that. I can't imagine a database that has no relational data in different lists. If you have a list of users and care about information that is common to them like their career or music genres they like then you have relational data, unless you do not care about searching for users that like dance music and have headaches on Sundays. Maybe I am not explaining well. The thing about sql that is great is performance searching lots of data. If you have hundreds of billions of records then there are other special data managing systems that google uses, but that's out of my understanding. MySQL has a free version that allows lots of stuff. I am curious why you would not use a relational database and if yours can handle lists that have connections. For example if you ended up.with 10 million users on your site and wanted to get a list of the ones into dance music, can you do that instantly?. If not and you don't care then the database you use doesn't matter as long as it doesn't get corrupt and allows reliable backups. Reliable Backups is the most important thing in a database system.
Hi Perry! You've got 3 main points here and I can address them all. Your "10 million users, find the ones that like dance music" query would not be difficult at all. I'm not sure why you think that data would be separated from the user data, and require any kind of relational stuff. It is the user's information, so that information fits into the user's document. The query could be as simple as db.Users.find({'liked_genres': {'dance': True}}) . WIth proper indexing you'd have your answer in a heartbeat. Backups are important, and so is scaling. MongoDB specifically is designed with both of these things in mind. I run all of my operations on 3 cheap VPSes! The Databases for AppKaiju and discchord are massive, so just getting a SQL server that can fit them would be expensive. The backup solution would be another expense. And none of that expense would factor in redundancy. With my MongoDB replica set I get performance, and 2x redundancy/backups. It is also reasonably efficient to backup to another site all together. My backup solution is a whole separate deal, because I also have non-database data like images. It is housed 1,000 km away from the main cluster in case of a natural disaster of aliens taking out the East Coast. Doing a MongoDB Dump to the backup server is very fast and effecient!
Tim Webb aliens have the best servers and data is light years away from the backups. Seriously, your database sounds very cool and takes care of everything you need it to. I feel that you did the research and I don't have to worry about you. Cudos for learning this stuff mostly on your own. I learned programming on my own many years ago and loved it for the first years, but lost heart and ended up being a sql server guy until retiring. There was more money out there for good database people who cared, and I cared. I have respect for you for your energy and openness. The trick is to never have all eggs in one basket in case one of the baskets break and leak. We always need at least one big plan B. Have fun and keep up the good energy.
We have persistence!!
Great tutorial, you're very knowledgeable! Love the integration that's almost as easy as tapping into SQLite. Do you have a series on Python with Postgres too?
Thanks, azurewill! I haven't done a SQL video yet, but I've thought about it. I'm going to take your comment as a suggestion to do so!
You didn't say anything negative about non sql databases. If you are dealing with small lists then it doesn't matter. You can use text files, but if you end up with hundreds of thousands of items or millions then performance can become a problem. You say non sql is more scaleable. Could you explain that. I can't imagine a database that has no relational data in different lists. If you have a list of users and care about information that is common to them like their career or music genres they like then you have relational data, unless you do not care about searching for users that like dance music and have headaches on Sundays. Maybe I am not explaining well. The thing about sql that is great is performance searching lots of data. If you have hundreds of billions of records then there are other special data managing systems that google uses, but that's out of my understanding. MySQL has a free version that allows lots of stuff. I am curious why you would not use a relational database and if yours can handle lists that have connections. For example if you ended up.with 10 million users on your site and wanted to get a list of the ones into dance music, can you do that instantly?. If not and you don't care then the database you use doesn't matter as long as it doesn't get corrupt and allows reliable backups. Reliable Backups is the most important thing in a database system.
Hi Perry! You've got 3 main points here and I can address them all. Your "10 million users, find the ones that like dance music" query would not be difficult at all. I'm not sure why you think that data would be separated from the user data, and require any kind of relational stuff. It is the user's information, so that information fits into the user's document. The query could be as simple as db.Users.find({'liked_genres': {'dance': True}}) . WIth proper indexing you'd have your answer in a heartbeat. Backups are important, and so is scaling. MongoDB specifically is designed with both of these things in mind. I run all of my operations on 3 cheap VPSes! The Databases for AppKaiju and discchord are massive, so just getting a SQL server that can fit them would be expensive. The backup solution would be another expense. And none of that expense would factor in redundancy. With my MongoDB replica set I get performance, and 2x redundancy/backups. It is also reasonably efficient to backup to another site all together. My backup solution is a whole separate deal, because I also have non-database data like images. It is housed 1,000 km away from the main cluster in case of a natural disaster of aliens taking out the East Coast. Doing a MongoDB Dump to the backup server is very fast and effecient!
Tim Webb aliens have the best servers and data is light years away from the backups. Seriously, your database sounds very cool and takes care of everything you need it to. I feel that you did the research and I don't have to worry about you. Cudos for learning this stuff mostly on your own. I learned programming on my own many years ago and loved it for the first years, but lost heart and ended up being a sql server guy until retiring. There was more money out there for good database people who cared, and I cared. I have respect for you for your energy and openness. The trick is to never have all eggs in one basket in case one of the baskets break and leak. We always need at least one big plan B. Have fun and keep up the good energy.
@@perrypelican9476 Yes, I was fortunate enough to learn very early on in my adult life that you always need a solid Plan B!