Microsoft SQL Server

Please check the NewRelic, It has most of the capabilities that you were expecting with dashboards and alerts with SMS/Email notification options.

We have used the same stack for the same reason and It was pretty enough and scalable. If you set your databases in an efficient way and your APIs as well, everything will be fine.

Hey Karthikeyan,

I know it's been some time since you posted this question but I'm curious on which direction you ended up going in, what were the results and have you run into any of the scaling challenges you anticipated seeing?

I agree with the advice you have been given to stick with SQL Server. If you are on the latest SQL Server version you can query inside the JSON field. You should set up a test database with a JSON field and try some queries. Once you understand it and can demonstrate it, show it to the other developers that are suggesting MongoDB. Once they see it working with their own eyes they may drop their position of Mongo over SQL. I would only seriously consider MongoDB if there was no other SQL requirements. I wouldn't do both. I'd be all SQL or all Mongo.

I think the key thing to look for is what kind of queries you're expecting to do on that JSON and how stable that data is going to be. (And if you actually need to store the data as JSON; it's generally pretty inexpensive to generate a JSON object)

MongoDB gets rid of the relational aspect of data in favor of data being very fluid in structure.

So if your JSON is going to vary a lot/is unpredictable/will change over time and you need to run queries efficiently like 'records where the field x exists and its value is higher than 3', that's a great use case for MongoDB.

It's hard to solve this in a standard relational model: Indexing on a single column that has wildly different values is pretty much impossible to do efficiently; and pulling out the data in its own columns is hard because it's hard to predict how many columns you'd have or what their datatypes would be. If this sounds like your predicament, 100% go for MongoDB.

If this is always going to be more or less the same JSON and the fields are going to be predictably the same, then the fact that it's JSON doesn't particularly matter much. Your indexes are going to approach it similar to a long string.

If the queried fields are very predictable, you should probably consider storing the fields as separate columns to have better querying capabilities. Ie if you have {"x":1, "y":2}, {"x":5, "y":6}, {"x":9, "y":0} - just make a table with an x and y column and generate the JSON. The CPU hit is worth it compared to the querying capabilities.

You need to start using Datawarehouse (DWH) solution and then feed data to tableau. For that you need to setup data pipelines and then transform data in the DWH, move all the custom queries into the DWH. This process is called ELT. You need AWS Redshift or Google Bigquery, a serverless scalable solution, this is the bottle-neck on your current SQL, not meant for processing millions of rows of data. A team of Data engineers can help you to setup these solutions.

BI tools are only as good as the data they're connected to. If you're already experiencing performance issues, you might want to consider a cloud database like Snowflake.

In my experience, there isn't a whole lot of a difference in PBI vs Tableau, for the vast majority of analysis. Personally, I favor Tableau because you can make really fancy/pretty things, but most business don't require that level. Most of the time I've seen people choose PBI due to cost or their team is already familiar with the platform.

I also recommend checking out Sigma Computing (sigmacomputing.com), they are a BI tool built like a spreadsheet so it's easy for people to learn and understand, and they're specifically built to optimize Snowflake connections.

I'm not sure I can comfortably recommend either tool as i don't believe either is really suitable for the use case you describe. In fact, I would question the soundness of the use case in the first place. The whole idea behind RDBMs (like Microsoft SQL Server and MySQL) is to store data in a relational way. To have a table with 1700 columns sounds foreign to the RDBMs paradigm already but to have that number growing by one every week is a big design smell. As a rule of thumb, making database schema changes should be avoided if at all possible. Adding a column to a table is a schema change and you're talking about making a schema change on a weekly basis. Adding rows is fine. That's what RDBMs are good at.

Having said all this, SQL might well be perfectly suited for your needs but I would suggest you rethink the way you organise your data. There's a very good chance that you might be able to represent all the data you need by making use of a hand ful of normalised tables, as opposed to one enormous flat table such as you're describing.

When I looked at the graphing database solutions a few years ago, Neo4j won hands down. Plus, as a small company, I had access to it for free. Ask them about pricing, and it might actually end up being lowest cost. They now have a managed version called Neo4j Aura that I am very interested in so I don't have to manage the server. I haven't started using it. But a cursory investigation showed that Neo4j Aura was still probably the best alternative for my needs.

Hi, if you already knows ASP.NET you should consider nopCommerce, as it's an Open Source platform for e-commerce. It's easy to setup and customize, and you should learn a lot using it. Also, if you are familiar with C# you should use Xamarin to develop a mobile app.

Please take a look at our sql web application constructor. Thanks to the reduced stack, it significantly reduces the development time, and therefore reduces the cost. https://falconspace.site/docs/vvedenie-v-falcon-space--c-chego-nachat

If you are used to use JQuery, Vue.js more similar to Jquery because you only can import a CDN and start to work. Vue is really flexible and you can use it wherever you want.

In other hand, if you have time to learn and install a new framework as React, use it. React works with a standard and several conventions in his code, then is really easy integrate new libraries and plugins .

both are absolutely great choices. while you'll find more resources and a larger community with react, vuejs typically does some quality of life "magic" for you. its pure taste.

if your html markup comes from razor, I'd recommend globally registered Vue components though. I've successfully used this stack for 4 years. (content from sitecore cms rendered through razor, enriched with vuejs components)

in any case, you will want to try to remove jQuery, if you pick a frontend library, as you should not mix two ways to modify the DOM. it wont break but its unnecessary bloat.