4 ms·
Are we using the term "database" loosely here to mean some limited subset of data? Because I think of the term as referring to an app's primary datastore, and
by unclebucknasty 5y ago
Are we using the term "database" loosely here to mean some limited subset of data? Because I think of the term as referring to an app's primary datastore, and I can't recall a single meaningful modern app I've seen for which the database is anywhere close to that small.
- tgsovlerkhgsel 5y agoThink of small, in-house applications managing an inventory of a couple hundred to a couple thousand items. "Hard discount" stores like Aldi are supposed to have <1500 SKUs, for example.
- unclebucknasty 5y agoGot it. Thanks for clarifying. Thought there might be some kind of clever sharding or tooling I was missing.
- tgsovlerkhgsel 5y agoNo really clever tooling. But even where the database gets too big, you can still stay in a similar operating mode. For example, when the user requests the first page of items or performs a search (that you have to do server side due to the size of the whole data set) - why not send the first 100 actual items instead of just the visible data from the 10 rows forming the first page? Or send the first 10 immediately followed by prefetching the next 90? Now the user will immediately get to see the full item and will be able to page through the results much more quickly. I've definitely had cases where I had to process the data before sending it to the client, but I've also sent absurd amounts of data and rendered it client side. In fact, I think sending data embedded in HTML to the client is rarely a good idea, and once you've adopted that mindset, apps can look very different.