what is binary save and load???

Question

what is it and when we use it?I have to do it for my homework(creating a Bank System) but I don't know for which part of that?

Answer 1

Binary saving and loading is a way of saving files. The other way is Text saving and loading. Text saving is what you might be familiar with - the files that you save are made up of letters and numbers (normal text). Binary saving and loading is storing data that is not human-readable like letters and numbers, but it's a more "native" representation of data like numbers (i.e. rather than saving "7" for the number 7, it might store 00000111, which is the binary representation of the number 7).

For your Bank System homework, you might want to use binary saving and loading for storing how much money someone has.

Answer 2

You're going to need to be a little more specific than that, but in general this means reading and writing values to a binary file. Depending on your homework problem, the actual format of the file may be defined or you may have to decide on the format yourself. This usually means a specific order of specific types. For instance, the file format might be:

• An integer, the number of accounts in this file
• An integer, the account number of the first account
• A long, the amount of money in the account (in cents)
• An integer, the number of characters in the account holder's name
• Several characters representing the account holder's name
• Repeat, starting at the account number of the second account
• etc

This is a bit oversimplified, of course.

In Java, a (relatively) simple way to get started with this would be the DataInputStream and DataOutputStream classes, which allow you to read and write from input and output streams (probably a file, in your case).

Answer 3

Since the "what" part has already been answered, I'll focus on the "when" of your question.

Binary formats are usually employed when you need efficient storage and faster data processing. They are more space-wise efficient because binary representation is inherently more compact. As binary formats usually have a structure, you can "navigate" inside their contents easily and fast.

Let's say you have an account holder named "John Doe", with account "123-45678-34567", client card "1234-5678-1234-5678", and two accounts: savings ($12,456.78) and checking ($1,234.56). If you have you database as a simple text file, you could save the data like this:

"John Doe" 123-45678-34567 1234-5678-1234-5678 12,456.78 1,234.56\n

All data is a textual line in the database file (the "\n" is the line breaking character). It's easy for a human to understand, and even modify without trouble. But for your program, you need to parse each line to make sense of it (e.g.: load how much money there is in the savings account), then do whatever operation you need (e.g.: update savings total), convert back to textual format and save again. Now imagine if you have thousands of accounts, and millions of daily operations. You'd clearly spend a lot of time parsing from text to binary (so that the computer can actually do something), and then converting back to text and saving to disk. Navigating in this file (searching for "John Doe"'s account) is also time-consuming.

For a binary file, you need a similar sense of structure, but you also need to plan a bit more. Not all clients will have the same name length or same amount of money, so you have to set some reasonable limits---after all, you don't want to waste space reserving many characters for the name (say, 256), where 32 characters would be usually enough. You also need to have a notion of range for numerical fields.

For the sake of simplicity, let's assume 64-bit integers (Java's long primitive type) are enough for all your numerical needs (see this link for more information on ranges). In this case, each record to store accounts in your homework bank has 5 fields:

1. Account holder's name, a fixed-length string of 30 characters.
2. Account number as a long integer type.
3. Debit card number as a long.
4. Savings account amount, as a long.
5. Checking account amount, also as a long.

In this case, each record has a fixed length of 32 + 4 * 8 = 64 bytes. For this example, it is almost the same as the single line above, but have in mind that this is a very simplistic scenario: a real bank will have much more detailed information, including history for the account and so on.

The point here is that you should be able to see that navigating in a binary file like this is much more simple: you simply load a raw record from a specific position in the file, and you're done---no text parsing required. If you keep the file sorted by account holder's name, you can search and retrieve a record in O(log(n)) time, instead of O(n) if unsorted or a textual file (unless you use fixed-length lines). After you're done updating a record, you simply save it back to disk.

As your binary format progresses, you may want to include summarized information at some specific place in the file, usually the very first byte of the file. Such special record is the header, and besides describing useful information (e.g.: how many accounts are there in the file), the header itself may contain information that allows you to recognize the file as being in the format you expect, usually by including an identification token in a (again) specific place.

Binary files are easier to deal with than this post might feel, so I suggest you look at some examples to understand how to do this in Java (in this other link, for instance). There are many others, of course.