New answers tagged storage
I think you're actually bikeshedding here. Whatever it is that you are doing, in all likelihood this question is way beside the point. As you've said yourself, the storage will have an HTTP based API. Define that first. Use the most simple implementation you could (e.g. on top of redis). If this takes longer than an hour, you're doing it wrong. Write the ...
On Linux and Posix systems I would recommend using the dbm API or the GNU gdbm library (implementing a superset of dbm) That key-value storage API is pretty common and exists since the previous century. It is in POSIX (using <ndbm.h>). The implementations are quite good and able to deal with both small and huge data.
There are certainly various strategies to solve this problem. One possible way is to do it client-server. Use case model: The front-end app will be desktop app installed on user's device without its own database. When front-end user needs to select from menuitems it will invoke GetMenuItems method on the server and will receive all the menu items ...
So let's start with the simple approach to calculate the bare minimum and find additional means to reduce the size required. A 5x5 magic square contains the values from 1 - 25. Said another way, we have 25 potential numbers to store. There are 25 cells within the grid, and 5 rows. 1st approach The simplest approach is to use 1 Byte per cell. So that's 25 ...
25 cells each of a number < 255, means each occupies 25 bytes. 25 * 275305224 is 6,563Mb or 6.4Gb. That's uncompressed. Compressed - it depends on the compression algorithm but you're probably looking at a couple of gig no matter what.
Top 50 recent answers are included