Quote:Well I just don't know the limitations of MongoDb since it's a NoSQL or document based database.
Faster in which case? Add a bunch of
Quote:I've read the right way to do it is to use SQL Server for storing transactions because it's faster.
JOIN statements and heavy on index
INSERT INTO queries 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 several
JOIN clauses 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).
Oh boy, don't read everything on the internet if you have to develop a product. Pick one and go with it!
Quote:FireBase and CosmoDB
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. 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.
Okay, how about Apache Cassandra?
Quote:I really don't want to go back to SQL Server again.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~