How much data can a TinyDB store on a device?

This type of data is very small compare to the room inside a phone.
Let's say a store entry is 100 bytes.
Let's say you have 10 stores.
Let's say you do one entry per store per day.
So over a year that's 365 * 10 * 100 = 365,000 bytes.
That's less than a megabyte for a year.
And if that's too much for you, you can go back and empty out those old namespaces, because you know how to generate all those yyymmdd values one by one for your cleanup.

So you have a big margin of safety.

This discussion by the developers discusses part of your question Mukesh.
https://groups.google.com/forum/#!msg/mitappinventortest/AX1gPrAcuvY/d152ciI2n-kJ;context-place=category-topic/mitappinventortest/jkNvJtZIRdw . Ultimately, the storage memory available on any particular device is a factor that affects how much data you can store internally on any particular Android device. What you can do regarding the size of your TinyDB is dependent on how much data your device has memory for.

In Lyn's experiments, he experienced a crash at 8,388,608 characters stored. That red line is probably partly limited by his device's cpu/memory etc. There certainly is a practical limit...the larger the database, the more slowly the app will retrieve information.

This article indicates a maximum size of about 5 Mb due to once upon a time Project sizes with AI https://stackoverflow.com/questions/31027981/maximum-size-limit-restriction-of-mit-app-inventor-project is possible. That estimated 'maximum' might now be as much as 10 or 30 Mb or more. Other articles indicate very large TinyDB databases are unwieldy and SLOW.

But since you are only saving one day's data per TinyDB Namespace XML file, you will never get any single TinyDB file that large.

@ABG 'very large TinyDB databases are unwieldly and SLOW' . Yes very large TinyDB databases are unwieldly and will be slow depending on the Android hardware the app funs on. Will Mukesh's database ever get that large so that it slows or is awkward? What happens depends on what he puts in it and how long it is used on his device and the processor in his Android. :slight_smile:

(Because Mukesh said he is in the 8th grade, I am not worried about his data volume.
This is a class project, right?)

No sir this is a project for my father's buisness

Sir i also tried that app and here is the Result the number counting stopped for me at "33554432" after which it showed an error "runtime error failed to allocate a 75497480 byte allocation with 25165824 free bytes and 25MB until OOM. max allowed footprint 266360584 growth limit 268435456" what is the meaning of this sir .

It means your device ran out of memory after posting 33.6 MB to your TinyDB.

So sir cant i store this Value for 40 to 50 times using tiny db in one name space

The example you displayed is for adding data to a CloudDB.
You should be able to do that by adding data to a TinyDB tag. The next time you post an image, just drag the *.jpg file into this space.

It is awkward for users (and not secure) to access your GoogleDrive.

Yes, you probably can add that amount of data easily; it is probably only a few kb of data as a guess. You may want to experiment using dummy information posted to your TinyDB. See what happens?

Sir i tested as you said and i can save more than 100 data's like that

:wink: and that is what you want to do.

Now i should try updating and deleting those data

Yah you are correct :+1:

I generally categorize the posters on this board into categories:

  1. hobbyists
  2. students doing class projects
  3. inventors with vision and resources
  4. lambs to the slaughter, blindly about to make a really bad business decision

From what I have seen so far, you are in category 4.

Using the wrong storage for business data can wreck that business when it stops working. In my small congregation, there was a loan broker who kept his records in the Microsoft Access desktop database. All went well until one day his data base was corrupted and he lost track of his loans, unable to recover the database file. He didn't have paper backups.
He was unable to defend himself in court, and ended up losing his business and his family.
They all moved out of the neighborhood.

My advice to you is:

  • Complete a course on Junior Bookkeeper
  • Learn to use spreadsheets
  • Learn how to represent your business's data in spreadsheets, current and historical
  • develop a backup plan

Only after all those, revisit AI2.

1 Like

So is spreadsheets better than tiny db in safety?

I also saw many tutorials in youtube for only till saving the data i understand but after that like updating,and deleting they all write the codes in app scripte and I can't understand even 1 line in that . If they write the codes for storing 11datas i can copy the codes and paste it in mine but the show it for only 1 or 2 datas i don't know what to do to store data.

Are spreadsheets better than a TinyDB in safety? Maybe. Storing data in a TinyDB, on a spreadsheet hosted on Google Drive and using a Firebase are all useful ways to maintain records. None of these data solutions is perfect.

Creating a database to store financial or other data your user can not afford to lose is a challenge for even advanced programmers. A program to store financial information should have a way to back up the data. If you lose your Android, you lose all your data stored on your TinyDB. If you make a mistake in programming, you might corrupt your database. If you store your data in a spreadsheet and lose your Android you can buy a new device, then load a copy of your access app and continue working with the spreadsheet (or you can access the spreadsheet from your Google Drive using your PC). Nothing is entirely safe.

Can you build the app you want Mukesh? Certainly, if you acquire advanced coding skills and learn to code rather than copy code.

1 Like

5 posts were split to a new topic: How can I build a secure Spreadsheet/Google Drive database?

Split because the original topic question has been answered and this is now a discussion of how to use a Spreadsheet data base for accounting a small business.