I think that database cost is quite cheaper than developer cost. Have you considered having multiple databases? Maybe you can have a lot of queries with big data, but you could optimize it by pre processing useful data.
Suppose that you can do some sort of search, trying to find most used queries. Then you can find out what are the bottlenecks, like: structure A is quite slow with query type X, but is quite fast for query type Y. Then you think about a structure B that is quite fast for query type X, but slow for query type Y. Why not using two databases?
If storage is not a problem, you can have multiple structures, each focused on a specific type of query that occurs more. The remaining ones does not occurs much, so you total complexity wont be affected too much.
Imagine something like spotify. You can have a tree where the key is artist name. If you want to query a song and you don't know the artist, it is going to be quite costly. But if you have another structure that can answer what is the artist of the song, then it becomes much faster :D
Just create a good back-end that can talk with all databases and check their sync from time to time, like on weekends, when there is not much usage.
Hey dude, long time no see! thanks for the reply, I guess the cheapest way is, indeed, to focus on the DB structures. And DB cost is way cheaper than developer cost, that's a valid point haha.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just my 2 cents here.
I think that database cost is quite cheaper than developer cost. Have you considered having multiple databases? Maybe you can have a lot of queries with big data, but you could optimize it by pre processing useful data.
Suppose that you can do some sort of search, trying to find most used queries. Then you can find out what are the bottlenecks, like: structure A is quite slow with query type X, but is quite fast for query type Y. Then you think about a structure B that is quite fast for query type X, but slow for query type Y. Why not using two databases?
If storage is not a problem, you can have multiple structures, each focused on a specific type of query that occurs more. The remaining ones does not occurs much, so you total complexity wont be affected too much.
Imagine something like spotify. You can have a tree where the key is artist name. If you want to query a song and you don't know the artist, it is going to be quite costly. But if you have another structure that can answer what is the artist of the song, then it becomes much faster :D
Just create a good back-end that can talk with all databases and check their sync from time to time, like on weekends, when there is not much usage.
Hey dude, long time no see! thanks for the reply, I guess the cheapest way is, indeed, to focus on the DB structures. And DB cost is way cheaper than developer cost, that's a valid point haha.