How to choose between small file size and simpler code?

Creating desktop or client-server database solutions?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
MichaelBluejay
Posts: 222
Joined: Thu Jul 01, 2010 11:50 am

How to choose between small file size and simpler code?

Post by MichaelBluejay » Fri Oct 11, 2019 11:26 pm

How do you choose between minimizing the disk space for data files, versus making the code much simpler?

I'm writing an accounting app, and thought I'd store ID's for the accounts rather than account names, because "27" is shorter than "Chase Checking". (Of course, there's another table that ties the account numbers to account names.) Using ID's instead of account names saves only a few extra bytes for one entry, but multiplied by at least three entries per transaction, and thousands of transactions, it adds up. But does it add up "too much"?

Here's a sample line of data with account numbers:

Code: Select all

10/21/19   1199199600   356.20   05   16   SomeHost: Registration & webhosting, 2 years
And here it is with account names:

Code: Select all

10/21/19   1199199600   356.20   Chase Checking   Office Expense  SomeHost: Registration & webhosting, 2 years
For 3000 transactions, which each transaction saved into an SQLite database 3 times (trust me on that one), and assuming perfect efficiency of the SQLite storage mechanism (because I don't know how to calculate SQLite's overhead), that's 765k for storing with IDs, versus 976 Kb for storing the names. In percentage terms, account names takes quite a bit more space (28%), but in raw terms, an extra 211 Kb just isn't that much. So, I'm strongly considering ditching account numbers and just using account names.

It's not a problem if someone changes an account name, that's a simple change to the database to update the affected records.

I'm not worried about the data file growing ever larger year after year, because different years can be stored in different files. In fact, that's one reason I'm writing this software: the commercial app I was using insisted on keeping all years in a single file, and since that single file recently got corrupted, I'm stuck with having to re-enter thousands of transactions for six years' worth of data.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: How to choose between small file size and simpler code?

Post by FourthWorld » Sat Oct 12, 2019 2:28 am

In 20 years with LC I've never worried too much about script size. And that includes a great many stacks delivered to the app dynamically over HTTP at runtime.

Even fat code is lean compared to a single image file.

If you're delivering a standalone, the engine is ~16MB by itself, so once it's bound to your stack to produce your app any difference between "fld id 101" or "fld SomeMemorableName" will be unnoticeable to the user.

But you'll notice the difference, every time you open a script editor to refine and enhance your code.

Code for clarity, and the benefits for maintainability will more than offset any savings of a k or two in size.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

MichaelBluejay
Posts: 222
Joined: Thu Jul 01, 2010 11:50 am

Re: How to choose between small file size and simpler code?

Post by MichaelBluejay » Sat Oct 12, 2019 9:27 am

Thank you, fourthworld.

To be clear, I'm not asking about the size of the *code*, I'm asking about the size of the *data* in a SQLite database (or rather, multiple databases, one for each year). It seems like you'd still go with biggerfile size / descriptive account identifiers in that case too, though.

Post Reply

Return to “Databases”