In the 1990s there were several software packages and languages that were used to build simple (and complex) relational database systems for Personal and Small Business use.

Microsoft Visual Basic was a very common language/platform for building small business systems

Microsoft Access offered a full solution although the form builder and screen builder was very limited.

Foxpro was another System used for the same purposes

DB IV was a common tool for building Accounting Applications

This was pre-internet programming craze. It was not uncommon for a small business or college graduate to build a small system for their own needs. There were many books and tools to enable such a project.

In the early 2000's there was a push towards "Software as a Service" . Instead of building your own local software solution or buying a downloadable solution from a trusted vendor, there was a shift towards using databases in the cloud that used websites via web browsers to present forms and reports. What started out looking great for many business people on both sides of the fence turned rancid over the following decade. As time went by, creative and intellegent people lost interest in devleoping their own database systems and they relied more on these SaaS vendors, and the SaaS vendors gained huge power and control over businesses that were previously digitally autonomous. As a user, finding a happy balance using SaaS Software is actually quite challenging and the hidden problems with using them long term can be detailed in case study after case study.

The idea of going back to downloadable software is not attractive. There are some web based systems for individuals that can be customized, but truthfully, they are very complex with too many moving parts for 95% of the population.

A new platform for developing small, custom database applications for individual business that was free from the Saas Companies and their data Silos was needed.

The folks at the 220 Club came up with a solution they dubbed, DIY Software

Since the 1990s, talented people have been using Spreadsheet as Databases. It's not common knowledge because it hasn't been promoted in schools.

In 2016 there was an update to Google Sheets that made it a prime platform for Spreadsheet Database System building with many of the benefits of cloud computing that were not there with stand alone spreadsheets.

1. Since 2016 , folks at the 220 Club prototyped about 15 to 20 different small business database systems to show folks what can be done.

2. After building the systems, they went back and standardized them. Then they wrote up specs for "Best Practices" for building systems for yourself and others.

3. They took one concept related to Bookkeeping and Accounting Software and built it out into a very robust Double Entry Accounting Solution with all the documents you might expect to find for a big company and they published it all for free.

4. Via this website we will be introducing some of the existing templates and pointing to resources to help you get going. We may also be offering videos for further education and support.

The basic components of a Database System can be oversimplified to:

Forms > Scripts(1) > Data Tables > Scripts(2) > Reports

This Expands out to:

Forms

Scripts (to process transfer form Data to Data tables) >

Data Tables

Scripts (to request data from Data Tables to Create Reports

Reports

=======================================

Forms - Anything that has a text box you type into or a check mark to provide information or comparable is a "form element" and it's part of a digital form.

Scripts(1) - When you hit a "submit button", a script runs that processing the data you entered in the form. It often times has a coponent that looks at data integrity to make sure the data you provided is as expected, after which it uses some comples "drivers" to connect to a data table system for passing your data along to that system for storage. NOTE: In modern systems forms often fire Script(1) scripts when you exit a text box or do some action othre than a specific button push. This is all still just form processing, it's just got fancier means for saying "go".

Data Tables - Data tables are best thought of as grids of data, most commonly seen like in a spreadsheet filled with tabular looking data. The table view concept if a visual representation of data that is stored as 1's and 0's on a hard drive somewhere.

Scripts(2) - Scripts that are triggered to get data from data tables and present it as a "report" to the user.

Reports - Reports provide logical, organized views of data that is stored in a data table. When you want to look at data that is stored in a data table, you don't typically look at the raw data as it would not be in an order and format you might want. "Reports are created to provide that information to you in a meaningful way.

=======================================

There is a good chance this simple model may become helpful with understanding hydro-gel and graphene oxide as it's found in the vaccines, but we'll leave that out for now.

Relational Databases are a collection of data tables that are related to each other. A data table is data organized in a grid.

An example makes this easy.

Data table 1 is called "People". There is a record (a separate row of data) for you and four of your friends in it. Each record has an ID associated with it.

Data table 2 is called "Residences". In this table , there is a list of each residence that you and each of your friends lived at your entire lives. Your records would start out with a 1 if you were the first record in People. and the next cell would be ' Street address" followed by "City", "State" and "Zip".

Data table 3 is called "Residence Mates". In this table the first cell is a number (a unique ID) that is tied to a residence, and there is the name of one person that lived at that residence with the person when they were there (if applicable). If there were multiple people, there would be a row for each person.

This concept of cascading data where each record in a "parent table" can have multiple records in a "child table" is referred to as a "parent - child " relationship. The foundation of "relational databases" is built on this idea of building cascading data tables with "unique ID's" that link parent records to child records.

In a database system, there is a digital infrastructure that handles the creation and assignment of unique id s and table creation.

In a spreadsheet used as a database, you will have to create the IDs yourself and you manually create the data tables from different sheets in a workbook. When the worksheets (data tables) in one workbook are referenced from other workbooks "Modular Software" can be created. More on that in the next section.

The benefits to doing this in a spreadsheet is flexibility and cost. It is exceptional for small private applications only. This is not ideal for offering website style database systems.

Typically multiple database tables make up a "module".

Above we described a database module related to someone's residential history.

What if the application we were building was a "credit score" application.

We would want another module for each person's "vehicle ownership history", starting with cars and then insurance policies that went with each car and then the payment history for each policy. .

We might want another module for each person's "bank account history", starting with all the bank accounts they ever had, along with any late payments they had etc.

We could build each of these in a separate worksheet that shares the basic People Worksheet and link all the files together to build a "Modular Software Solution".

Modular Software is how the biggest companies on the planet put together their business system in a manageable manner. .

With this new platform you to can gain all those benefits with low or no cost for life while gaining privacy and flexibility that is very difficult to find and hang on to with Saas Software vendors.