One Big File vs Multiple Small Files?

Solar2D General Questions/Discussion
#1

Hi All,

I am developing a game app that stores user data such as account data, preferences, and game level details in a file to be recalled later.

My question is, is it better to have one large file that contains all data, or several smaller files for Cororna apps from the following standpoints?:
A) Coding practice
B) Actual app performance

Or does it really not matter at all and is more an issue of personal preference?

Please excuse me for the rather vague/abstract question.

I tried googling this, but didn’t come up with any answers…

Thanks in advance  :D 

KC

#2

I typically use a single file for settings, etc.

If however, I’m storing lots of data (like levels; or saved progress for a level) I’ll use individual files for the levels.

The questions to ask yourself are:

  1. Are my data needs simple?

Yes - Probably save in a single file.

No - Consider multiple files.

  1. Is this data related?

Yes - Store it in the same file.

No - Separate files.

  1. Will I be reading and writing this  file frequently?

Yes - Keep the file/table  small or you’ll run into performance issues.  This is very relative to access frequency and file size.

No - Bigger files/more data per file is fine.

#3

Adding on to Ed’s Excellent Answer (Ed you should trademark that…)

We recently added preference storage features to Corona and it’s in the latest public build.  See:

https://coronalabs.com/blog/2016/09/21/introducing-new-preference-storage-features/

These are cross-platform API calls that gets you out of the file management business with regards to app settings. Let the OS do the work for you. You won’t use this for large amounts of data, but for settings and such it’s the way to go.

Rob

#4

Thank you both for your answers! It helps me a great deal!

@roamminggamer
So I have 2 major categories for my data.

A) A dataset for storing app preferences (READ-AND-WRITE)
B) A dataset for storing game-level details, such as map configuration, enemy positions and moves, etc. (READ-ONLY)

and obviously the above two are completely unrelated.

So I think based on what you said, I will use separate files.

@Rob Miracle

Adding on to Ed’s Excellent Answer (Ed you should trademark that…)

Who’s Ed???  Do you mean roaminggamer?

In any case, the preference API looks really tight, and I think I will implement it in my app for user preferences right away!

The code looks really simple and easy-to-use, unlike the messy traditional file reading and writing.

Unlike preferences, which can basically be represented in a set of key-value pairs, game level details, such as map configurations, are more complicated and are hard to represent using key-value pairs only, so I think I will stick to the traditional files approach.

KC

#5

Yes - Ed = @roaminggamer

#6

I typically use a single file for settings, etc.

If however, I’m storing lots of data (like levels; or saved progress for a level) I’ll use individual files for the levels.

The questions to ask yourself are:

  1. Are my data needs simple?

Yes - Probably save in a single file.

No - Consider multiple files.

  1. Is this data related?

Yes - Store it in the same file.

No - Separate files.

  1. Will I be reading and writing this  file frequently?

Yes - Keep the file/table  small or you’ll run into performance issues.  This is very relative to access frequency and file size.

No - Bigger files/more data per file is fine.

#7

Adding on to Ed’s Excellent Answer (Ed you should trademark that…)

We recently added preference storage features to Corona and it’s in the latest public build.  See:

https://coronalabs.com/blog/2016/09/21/introducing-new-preference-storage-features/

These are cross-platform API calls that gets you out of the file management business with regards to app settings. Let the OS do the work for you. You won’t use this for large amounts of data, but for settings and such it’s the way to go.

Rob

#8

Thank you both for your answers! It helps me a great deal!

@roamminggamer
So I have 2 major categories for my data.

A) A dataset for storing app preferences (READ-AND-WRITE)
B) A dataset for storing game-level details, such as map configuration, enemy positions and moves, etc. (READ-ONLY)

and obviously the above two are completely unrelated.

So I think based on what you said, I will use separate files.

@Rob Miracle

Adding on to Ed’s Excellent Answer (Ed you should trademark that…)

Who’s Ed???  Do you mean roaminggamer?

In any case, the preference API looks really tight, and I think I will implement it in my app for user preferences right away!

The code looks really simple and easy-to-use, unlike the messy traditional file reading and writing.

Unlike preferences, which can basically be represented in a set of key-value pairs, game level details, such as map configurations, are more complicated and are hard to represent using key-value pairs only, so I think I will stick to the traditional files approach.

KC

#9

Yes - Ed = @roaminggamer