To make software easier to understand, think of it like a machine that functions by coordinating the movements of several different pieces. For the machine to function effectively and to be maintained or scaled without affecting its current operation, it is occasionally possible for numerous engines to power each component. The Tally filesystem, or Tally database engine, is one such engine that powers Tally. To give you an idea of what goes on when you dig down to a specific business report in Tally, we would like to talk about some of the internal workings of this database engine.

Hold on, hold on! Did you say? An operating system or application can have its file system by using a tally file system. For this reason, I referred to it as a database engine or filesystem. Let's not worry too much about the jargon; after this piece, refer to it however you see fit.

Tally Database Engine: What is it? 

What distinguishes this filesystem from the filesystem of the operating system?

 

The storage story before the main narrative

An excessive number of STOs! Hey, save me the time! Come with me inside.

Since the early days of computers, data storage has been a necessary component of computing. In the industry, new filesystems or databases have always been required. What use does it serve to have a wide range of databases when data storage is a very basic and long-standing computer requirement?

The functionality for organizing discs (C: drive, D: drive), folders within drives, files within directories, and data blocks inside files is provided by the operating system's filesystem. The OS filesystem does not have a quantum understanding of the type of data being kept; instead, it functions at a high level of data organization. Windows uses the NTFS file system, which functions with drives, folders, files, and blocks, as its operating system.

Is the operating system aware of the contents of the files? a perfect tidy No, NTFS is aware that a file with the name "something.txt" is a text file; similarly, it is aware that a file with the name "something.xlsx" is an Excel file. NTFS is aware of the file's size, its most recent update, and whether it is hidden or not. sharing the file/folder's permissions and many other details required to function at the file or folder level.

Similar to this, data in files with the ".900" and ".1800" extensions found in your tally company folder is not understood by the operating system.

When you transmit a voucher through Tally for business use, it is kept in the company folder's ".1800" files along with its company number. One of these vouchers is created and stored on the disc as a record. as many records at times, or as a single record at times. A record is a simple variable-length data block that holds the information that a business user requests to access when needed, such as when they wish to view their reports or drill down to a voucher or master.

If the OS filesystem can be thought of as a manager with an eagle's view of the data, then the tally filesystem can be thought of as a manager with both an eagle's and an ant's view of the data, depending on how the product is used. It can navigate the perplexing Ant Hill's trails to retrieve or save the requested data most effectively. The tally filesystem operates according to the needs of business users and is the master of the tally company folder and its contents.

"The tally filesystem is aware of the type of data it contains when it is needed, and how it is needed."

A record will include the following factors or modifications:

The patterns of data access determine which record is accessed.

the record's lifespan in RAM or memory.

the section of data that will all be accessed simultaneously.

 

The product Tally has the unique ability to choose the design and implementation of different sorts of records based on the aforementioned considerations/variations because it has its proprietary filesystem.

One of the many phoenixes of the tally product, the tally DB constantly reinvents itself to meet the ever-increasing demands of the ever-emerging tally product and streamline the way you manage your enterprises.

The "remaining part is a cakewalk," as they say if we have understood this far.

Refocus your attention, and let's examine each data access pattern and associated data structure that is now operational in your Tally.

 

Indexing embedded

To maintain perspective Starting where we left off: A voucher contains data in the form of numbers, such as the amount, multiple masters, and stock items, and is stored by the Tally file system when it is passed. Depending on its type, a voucher may be stored as one record or multiple records. Vouchers may be required individually for changes, or they may be required as a single line entry in a list or collection of vouchers to be displayed on a specific day, month, or range of dates in the day book.

We will continue to create, edit, delete, and cancel vouchers as part of our daily operations. The disc will need to be updated for each of these operations.

Vouchers that are erased will leave empty spots on the disc where the data was removed.

A voucher record may get smaller or larger as a result of changes we make to it. The place where the updated voucher was kept may not be sufficient going forward if it has more line entries or stock item entries, making a new location for storage necessary. The location where the revised voucher resided will have space if stock item or line entry entries are eliminated, making the altered voucher smaller. If this is not reused appropriately, this will unnecessarily raise the file size.

Vouchers are arranged based on disc space availability rather than necessarily being located in the order in which they were created to maximise disc space use. The more records we change, the more random the order of the records according to their creation date becomes. To ensure that business users don't have to wait too long to check their daybooks, we need to figure out the fastest way to display the voucher(s) for a specific day or set of days.

To help us comprehend the solution, let's use the following analogy:

Consider your data records as houses inside a city or community. When a wedding occurs, the family of the bride and groom makes sure that friends, family of friends, and relatives of relatives all attend. Don't get me wrong, the hosting family wants to receive as many blessings for the newlyweds as they can.

The members of the hosting family therefore personally invite each of their acquaintances by visiting their homes during the invitation procedure. The hosting family may not be aware of the whereabouts of their acquaintances, even though they are well acquainted with them from their daily commutes, sports groups, and workplaces. However, the majority of these connections will be made in such a way that the hosting family is familiar with one of their homes, and some of these connections will know some of their properties that are close to one another. In reality, however, this works like this: a member of the hosting family goes to the home of a known relative, who then drives the member to the home of another relative, and so on. Once the person has invited every acquaintance they wish to, they will do so. A similar thing occurs with friends as well: a member of the hosting family goes to a friend's house that they know, and that friend takes them to another friend's house, which that friend has to visit on Saturdays, and so on.

You may be asking yourself why I opened the link when I was tired and why I started reading this in the first place. I ought to have clicked on another article link that would have put me to sleep.

Here, the key idea is to emphasise that, if we can locate the links leading to a certain area, we may utilize them to access several distinct locations of interest without having to go in a straight line. As it comes to voucher records, these links are purposefully created according to the date of creation or modification so that they can be utilized in that sequence as necessary. It should be emphasized that these links are preserved on the disc rather than in the cache, utilising a self-balancing binary tree. In this manner, the quantity of reads from the disc is likewise optimized to the extent required by the business user.

Embedded indexing is the term for this type of link maintenance that has been tailored to meet the unique needs of Tally's data patterns. In use cases such as the Day Book of Tally, this customised indexing strategy allows tally to perform as few input/output operations from the disc as possible, resulting in the maximum performance possible.

You have grasped what you have read if you have more questions now than when you first started reading this.

We'll be back with another enlightening nugget of a "nut and bolt" or data structure that operates within your Tally software to provide you with the fastest and most dependable experience while seeing your preferred business reports.

Until then, I hope you have a great time studying, and cheers.

 

Updated on: April 26 , 2024