Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Every time a certain form in a site dashboard loads, I generate a unique ID and store it into the database, when the form is submitted I mark the ID as "used" and don't allow to submit forms which are already used.
Question: Is it worth to store date/time of form load and remove unique IDs say two weeks old?
Or to keep this data in MySQL forever?
I think saving timestamp and clearing out old dara is an excellent idea.
Without that, your web site is not scalable. In fact it could be attacked by repeatedly loading the page and filling your database's disk to capacity, effectively killing your site.
Wether it is worth to store the date-time of the form in the database is up to your decision and your business needs, but, you should not keep any data stored, in the on-line database, which is not needed any longer.
If you need to keep such data for historic report purposes then create an off-line/report database and transfer the data, periodically, from the on-line to "report" DB.
The less amount of data you have in your db the faster your RDBMS will be to retrieve/manipulate it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Why do NoSQL databases want the data to be as flat as possible? Especially in the case of firebase. Can anyone provide read or write calculations to show the differences in I/O between relatively flat databases and relatively deep, multi-level, databases?
I what comes to Firebase Realtime Database, it's much more than performance, it's about information retrieval strategy.
You are free to save the ids of every liker of a specific post nested in the post structure, but if you feel you don't need to retrieve all this information every time you get a post (let's suppose you query a list of posts only to show as a summary cards), then you won't want to have it nested, but flat under a "post_likes/{postId}" node for example.
Remember that in the Firebase Realtime Database you can't filter out the nodes you don't want to receive. At the moment you retrieve a node, you get it all the way deep down the structure.
Think about the same example now, but for comments. The same thing apply, so we could structure our comments under a "post_comments/{postId}" node and only retrieve it when we are willing to show the comments.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm building an app, that will need to store approx 100-200GB of JSON data per month with ~20.000 write operations per minute.
Is there any service that won't require millions of dollars to store this data?
One option is to use Azure's HDInsight. You'd pay for the HDInsight servers in addition to the storage of the data. Of course your costs will keep climbing as you add more and more data, so some form of archive would make sense. How long do you have to keep data easily available?
HDInsight Pricing
Storage Pricing
I think you may be overestimating your data growth. I would start with either AWS or Azure and build my own datacenter if volume goes near the level you are talking about. Yes this involves some migration later on but its always good to grow by observation.
Thanks everybody. After all, I decided to go with Azure Table Storage.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Basically my application needs to dump data daily into a database. But for any data written down, there is no need to update.
Hence, is appending to csv or json file sufficient for the purpose. Or it will be more computationally efficient to write in standard SQL?
Edit
Use-Case Update
I am expecting to store one entry of for each particular activity count daily. There are about 6-8 activities.
It is exactly like a log in some sense. I would like to perform some analysis with the trend of activities for example. There is no relations between different activities though.
If say in some cases there might be a need for update, would that imply a proper database will be more suitable rather than text file?
It depends on the nature of the data, but there may be another style of database other than an SQL one which could be suitable, like MongoDB which essentially stores JSON objects.
SQL is great when you need entities to have relationships to each other, or if you can take advantage of the type of select queries it can provide you with.
Database systems do have some overhead and could have some gotchas you might not expect, like loading up a heap of crap into memory so it's ready to be searched.
But storing text files can have drawbacks, like it might become difficult to manage your data in the future.
It basically sounds like your use-case is similar to logging, in which case dumping it into a file is fine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I currently have a ColdFusion shopping cart script I have written which stores all of the users items in a session variable. Looking through it, I'm wondering what if there is a more robust solution for shopping cart data? Is it better to temporarily store cart data into a db table or to store the cart data in the users session?
My cart currently houses several hundred array items as the site I have is quite big. So I guess I'm wondering what is the better solution, DB or session ?
I would make the cart data persistent in the database.
This has 2 main advantages: it adds business value and reporting capabilities, allowing you to (for e.g.) analyze which carts are abandoned. The second advantage is that you can cluster your application more easily, over different clients, and your application will need less operative memory to run, allowing the application's memory behaviour to be more predictable.
Both options are OK, the choice depends on your priorities.
Database would be interesting if you intend to keep the carts longer than one session.
You can also consider using something like Redis to persist user sessions (across several CF servers).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I realise that cookies are stored on the client side, but what I’m thinking about doing is; instead of storing the actual data in the cookie I just store an ID which matches some id in a ServerSideCookie table in my database(Kinda the same way as sessions)
I wondering pros and cons of doing this.
One obvious pro is that this solution is not limited to 4k of data.
Another pro will be that storing data on the server will be less vulnerable than storing it on the client side.
Third pro is that I do not have to worry about cross browser issues.
Con might be that it is slower, although I have not benchmarked this.
I would greatly appreciate some input.
Thanks in advance, Sigurd.
In my opinion, both are valuable depending on context.
On the server
Advantage: no limit on data
Minus: size matters when you have a lot of users. for example 1M user x 2k data = 2G data that is sent back and forth over the wire
Minus: you cannot store info in case you have not an authenticated user
On the client
Advantage: no need to make a trip to the server, you have it locally. it worths for example when you store something related to UI preference of the user (current language, type of view: grid or gallery, etc)
Minus: you cannot store user sensitive data (e.g. card numbers)