Advice or opinion on database planning for Angular using MongoDB and perhaps a 2nd technology.
-
So I started my quest to learn Angular V6, and I have about a year into it now and doing quite well with it. I've made the move to Angular V7 and will go V8 pretty soon. I choose MongoDB for the database and I really like it, but have yet to do anything advanced with it. Well I just don't know the limitations of MongoDb since it's a NoSQL or document based database. I'm going to add a store to my project so I can sell things. I've read the right way to do it is to use SQL Server for storing transactions because it's faster. Like run MongoDb to store product information and images, perhaps the cart; and use SQL Server to store the purchase transaction. But then their is FireBase and CosmoDB out there as well. I don't expect to sell much the first year, and I'm considering going Mongo all the way. Just looking for opinions, help, guidance on this. I really don't want to go back to SQL Server again.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
So I started my quest to learn Angular V6, and I have about a year into it now and doing quite well with it. I've made the move to Angular V7 and will go V8 pretty soon. I choose MongoDB for the database and I really like it, but have yet to do anything advanced with it. Well I just don't know the limitations of MongoDb since it's a NoSQL or document based database. I'm going to add a store to my project so I can sell things. I've read the right way to do it is to use SQL Server for storing transactions because it's faster. Like run MongoDb to store product information and images, perhaps the cart; and use SQL Server to store the purchase transaction. But then their is FireBase and CosmoDB out there as well. I don't expect to sell much the first year, and I'm considering going Mongo all the way. Just looking for opinions, help, guidance on this. I really don't want to go back to SQL Server again.
If it ain't broke don't fix it Discover my world at jkirkerx.com
Quote:
Well I just don't know the limitations of MongoDb since it's a NoSQL or document based database.
Yep, that's true, being NoSQL it provides a great amount of flexibility. But most of the flexibility is lost when you take it out of a JavaScript-based environment, such as Node.js. So, consider using it with Node.js web app and then see for yourself.
Quote:
I've read the right way to do it is to use SQL Server for storing transactions because it's faster.
Faster in which case? Add a bunch of
JOINstatements and heavy on indexINSERT INTOqueries and you will easily see how MongoDb performs better in most cases, and SQL Server slows down due to housekeeping. The answer depends entirely on how you want to store the data, do you want to store the transactions as records and then pull out all from the tables one by one? Or do you want to have a single document of everything that a user has done in the system and be returned in a single go? I'll let you answer this. With SQL Server—or any other relational database—your content is stored as a record, and you have to query the data using severalJOINclauses to prepare a single report. If you do not do this, then you are not following normalization techniques and are wasting money paid for relational features. In NoSQL—especially MongoDb, or other databases or same dialect—you store the data in a fashion that makes it easier to access, yes a bit slower on insert, but querying is better (this statement again of course can be debated upon).Quote:
FireBase and CosmoDB
Oh boy, don't read everything on the internet if you have to develop a product. Pick one and go with it! Read here how Pinterest used old school MySQL and scaled their hyperactive Pinterest service on the internet; [https://medium.com/pinterest-engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f\](https://medium.com/pinterest-engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f). There did not break a sweat for SQL Server or MongoDb, or Neo4j or Apache Cassandra (food for thought! :-\ ), all they did was use the infrastructure they have, better optimize it and done.
Quote:
I really don't want to go back to SQL Server again.
Okay, how about Apache
-
Quote:
Well I just don't know the limitations of MongoDb since it's a NoSQL or document based database.
Yep, that's true, being NoSQL it provides a great amount of flexibility. But most of the flexibility is lost when you take it out of a JavaScript-based environment, such as Node.js. So, consider using it with Node.js web app and then see for yourself.
Quote:
I've read the right way to do it is to use SQL Server for storing transactions because it's faster.
Faster in which case? Add a bunch of
JOINstatements and heavy on indexINSERT INTOqueries and you will easily see how MongoDb performs better in most cases, and SQL Server slows down due to housekeeping. The answer depends entirely on how you want to store the data, do you want to store the transactions as records and then pull out all from the tables one by one? Or do you want to have a single document of everything that a user has done in the system and be returned in a single go? I'll let you answer this. With SQL Server—or any other relational database—your content is stored as a record, and you have to query the data using severalJOINclauses to prepare a single report. If you do not do this, then you are not following normalization techniques and are wasting money paid for relational features. In NoSQL—especially MongoDb, or other databases or same dialect—you store the data in a fashion that makes it easier to access, yes a bit slower on insert, but querying is better (this statement again of course can be debated upon).Quote:
FireBase and CosmoDB
Oh boy, don't read everything on the internet if you have to develop a product. Pick one and go with it! Read here how Pinterest used old school MySQL and scaled their hyperactive Pinterest service on the internet; [https://medium.com/pinterest-engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f\](https://medium.com/pinterest-engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f). There did not break a sweat for SQL Server or MongoDb, or Neo4j or Apache Cassandra (food for thought! :-\ ), all they did was use the infrastructure they have, better optimize it and done.
Quote:
I really don't want to go back to SQL Server again.
Okay, how about Apache
You got me thinking now. I'll continue using Mongo and try to come up with a solid compact design. Thanks!
If it ain't broke don't fix it Discover my world at jkirkerx.com