Imagine software products as machines, operating by coordinating numerous moving parts. Many engines operate each part, to ensure efficient function without impacting existing functionality or upgrades or maintenance requirements. One such engine that runs Tally is called the Tally filesystem or database engine – we would like to explore some of its details so we can better understand its performance when drilling down into reports for business within Tally. 

Tallysolution………..

Have you mentioned Tally filesystem before?, an OS or program capable of maintaining its own filesystem? I referred to it as a database engine; don’t stress too much over terms, since by the end of this article you may call it whatever name suits you best!

The story of the storage before the actual story

Lots of STO’s! Don’t waste my time! Let’s jump right in.

Storage has long been an essential requirement of computing. While there may be an occasional need for new databases or filesystems to store data in an industry, having so many would seem pointless; after all it has existed since day one.

Operating system file systems give operating systems the capability of organising drives [C D:, and C drives], folders within those drives, files within folders and blocks of data contained within files – while providing some generalised control over what types of files or types of data being stored – at an operational level. Windows uses NTFS as its file system which works across folders, drives and blocks – along with files!

Do operating systems understand what’s inside files? No way. NTFS knows a file title like’something.txt, but not that it’s text, while similarly being aware of something named’something.xlsx but not knowing its content either way. Additionally, it recognizes file sizes, last update dates, whether hidden/not hidden status as well as sharing permissions within folders/files as well as many more data points needed to function on these levels of folders/files effectively.

Operating systems do not recognize the information contained within files in tally folders with extensions ending ‘.900 or ‘1800.

When giving vouchers for business purposes in Tally, they are saved in the “.1800 file within your company folder with their unique company number and recorded in this file – sometimes just one record and sometimes multiple records containing user instructions and business-related data blocks that Tally uses at various points during use; such as viewing reports or looking into master/vouchers files.

Imagine OS files as being the administrator with an eagle’s view of data; Tally Filesystem acts more like the manager with both an eagle’s eye view of an application’s requirements as well as that of an ant. Tally can navigate down through an intricate network of ants in an efficient manner to locate or store what you need quickly and efficiently. Tally File System serves the corporate directory contents perfectly while meeting business users’ demands and fulfilling them efficiently.

Tally filesystem knows what is the data that it stores; what is inside the data; when is it needed; how is it needed;”

A record will have below considerations / variations:

• • The data Access patterns in which records will be accessed.

• • The lifecycle of the record in memory/RAM.

• • The chunk of data which will be accessed together.

Tally, having its own proprietary file system gives the product the unique freedom of deciding on the design and implementation of various types of records based on the above-mentioned considerations/Variations.

The tally DB is one of the multiple phoenixes of the tally product, that keeps rediscovering itself to keep pace with the rising requirements of the ever-emerging Tally product to simplify how you run your businesses.”

If we understood till here, as they say then ‘remaining part is a cake walk’.

Huddle up your focus again and now let’s see any one such data access pattern and its respective data structure running in your Tally.

Embedded indexing

Let’s begin where we left off: when using a voucher Tally file system records an item as either one record or multiple records according to its type, and this voucher may contain details in numbers such as quantity, masters, or stock items listed in line entries. Sometimes it needs to be altered individually or as one line of data in a list in order to display certain months or dates within your daybook.

On a daily basis, we create vouchers, alter them, delete them and cancel them, all of which must be documented into the database.

As soon as vouchers are deleted, empty disk spaces are created in which data has been erased from.

Changes to voucher records could result in their being either smaller or larger, depending on how we modify them. If we add entries for lines entries or stock items to make our new voucher larger, its original location may no longer suffice and additional space may need to be found for storage; on the other hand if our modified voucher has decreased because entries have been removed due to deletion, any vacant space in which it once resided could become part of an increasing file.

To maximise efficiency of disk space utilisation, vouchers do not have to be ordered chronologically according to when they were created; rather, they should be scattered according to available disk space. As more rearrangement occurs with files, their arrangement according to date of creation becomes more random. When we decide to show vouchers from one particular day or number of times at the same time, how can we do so with minimal delay so as not to put off accessing their daily calendars?

Let’s use an analogy to help us better understand this topic:

Imagine that your data are like houses in a town or society. When hosting a wedding, the bride’s family must ensure that all relatives, relatives of friends and so forth attend. No one needs to feel uncomfortable here: their goal is simply to bring as many blessings from all possible for newlyweds!

As part of their plan to welcome their guests, members of the family hosting them visit all their friends’ houses and extend personal invitations. Even though the host family may know their contacts in offices and sports clubs as well as their daily commute routes well, they might not understand where their home lies. However, most of their acquaintances are so well-established that they know about homes nearby their hosts’ and one or more members of their hosting families are connected with at least one of these other homes. What usually occurs is that one member of the hosting family visits one familiar member’s home and takes him/her back with them to another relative they know – until all acquaintances of their guest have been met and invited. Similar to friends, when hosting family, the person hosting usually visits one friend before moving onto another friend. Once this visit has taken place, then another friend will accompany the family member(s) to yet another house before coming back with you the following Saturday to visit yet another place and so forth.

Aren’t we the ones responsible for starting to read this? Clearly not; my responsibility lies solely with me! Perhaps when I was tired, instead of opening that link when it should have been more suitable as a sleep aid link?

At its core, this approach emphasises that by identifying all necessary links to get to any given destination, no contiguous travel is required; we can use hyperlinks instead to access various destinations of interest. When dealing with voucher records specifically, links based on creation or modification times are constructed so as to be used when required in a sequential fashion when needed. These self-balancing binary trees ensure links are stored directly on disk and not in cache – this ensures reads are optimised according to users in business needs.

This method of maintaining links is known as embedded indexing and can be tailored specifically to the demands of Tally’s data patterns. With this modified indexing technique, Tally can perform minimal input/output tasks from its disk, leading to maximum speed for use cases such as those contained within its Day Book of Tally.

If your questions about what was read have increased since starting to read it, that indicates you’ve understood what has been presented here.

At Tally Software, we’re always eager to bring you exciting information about different parts of our software that make up Tally that will enable you to experience fast and efficient business reports. Here is another piece of that information for your viewing pleasure: a data structure/nut and bolt that makes up our Tally system that helps facilitate faster reporting experience for our valued clients.

As for now, we wish you many cheers of happiness in learning something new!