Below are notes originally made to start the below-described project in Python v 3.n.
I now intend to start this project using compiled Go (aka Golang, sometimes aka Gopl)
rather than Python language. Golang is just as easy to code in, but compiled and thus faster in performance than Python. Accordingly I see using modern Go as more practical. However in fact, I am doing this to please myself, and not in expectation that the resulting codebase w/b particularly valuable to app developers in the future.
To work in Golang, I made a local directory on my PC:
C:\Users\DCarew\Documents\dev\FBase-DB-Prj\FBase_in_Golang
In fact, I now believe that "release to public domain" w/b probably not be outstandingly useful, because of powerful open source DBMS systems such as MySQL, MariaDB, Couchbase et al have rendered or will render FBase obsolete. I intend to use this as a "vanity project" --a way of taking a break from writing projects. Back in the day when I was employed as an appdev coder, we ended up basing all our applications around a set of file manager tools that were similar in design to FBase. FBase project might be useful in a nonfiction book showing how from-scratch, non-DBMS-based applications were built, from the sixties until sometime in the "aughts" when MYSQL and other free and open source database management systems became ubiquitous.
I choose to concentrate on the file primitives first. Especially if I publish a "how-to" book about this, which I might do as a "virtual apprenticeship"-slash tutorial in 3GL appdev coding, the "useful" file management primitives would naturally come first. This approach allows full freedom to add "screens friendliness " in later. However, if I ever got (get to) that point in this project, "screens friendliness" would be an exercise left to the student/reader, in that case.
*-----------------------------------------------------------------------------*
*
* Design Outline-- Programs to build... HOWEVER I need to think about
* what value these add in today's world. --
*-----------------------------------------------------------------------------*
List of programs:
FBUPDATE.go
FBSUBUP.go
FBKEYCHANGE.go
FBINDEX.go [[?? research pt: FBINDEX would use WIN cmd line "native
sort"-whereas FBSORT.go uses sort written in Golang ??]]
FBSORT.go
FBSELECT.go
FBLABEL.go
FBPRINT.go
FBSTATS.go
FBTABLE.go
FBCODES.go
FBPOSTDETL.go (FBPSTRING)
FBEXPAND.go
FBRENAME.go
FBCLEAR.go
FB stands for "File Base" to emphasize that the system is not a "real" data-
base, but rather a file handling system.
Together these programs make a comprehensive set of generic file management tools that constitute a set of file handling primitives that can be the basis for any sort of commercial application system, such as Customer Database, or General Ledger or Accounts Receivable systems. These programs are designed to be a set of basic primitives, that are needed in "all" Commercial Off the Shelf "COTS" application systems. Note that long ago in appdev history, such file primitive functions were replaced with more powerful, flexible, and generally useful DBMS and Relational DB utilities. The point of this "re-development of ancient history" is more to document details of 3GL appdev issues and engineered solutions. Publishing a set of such "old-fashioned" file handling routines, might constitute a useful illumination of "historical", pre-DBMS application development heuristics.
These programs store data as un-encrypted, clear text, "long strings" wherein each long string is a relevant subset of a single application record or unit of operation. For example, each "long string" might store all the data for one customer in a "Customer FB" system. That stored data is kept on disk in as a table of records, grouped in a disk file in a given disk and directory on a disk (e.g., on the C drive in C:\FH_CDB\*). That single table of records
could be (and is) designed so as to contain "pointer keys" to other long strings in other tables of records (files), containing for example sets of particular Accounts Receivable credits and debits relevant to specific customers in the "Customer FB" table/file.
Both "Customer FB" and "Accounts Receivables" (sub-)systems of defined files and "records-within-files" could be served by these FB* file handling primitives (enumerated above). To make a complete application, these primitives would be (could be) modified and enhanced to execute application-specific functionality particular to some specific small-business application, such as printing out monthly bills to customers whose records are kept in the Accounts Receivable File Base. In this way it is "easy" to form a small business or personal business application, concentrating on application-specific functions and operations, without having to reinvent all the common file-handling primitive code, or to make interface code that allows the database/file handling to be done by (for example) MySQL.
I intend to set forth the file handling primitives in a menu-driven system and release this FB generic system into the public domain as open source, when the primitive programs are "ready"... AND AFTER they are explained and justified in an explanatory text (probably a short book length text).
Back in the business programming day, it was useful and even important to have a *complete* and standardized set of "known good" file handling primitives that an contained an "80/20" rule of application file functionality. Eighty percent of ordinary, "last mile" data handling and screen handling "CRUD code" (Create Read, Update, Delete), along with some also fundamental printout/report functionality is in this FB system, already available for extension to provide some live customer-specific application, such as the fund-raising mailing list for nonprofit organizations, or what have you. You can build an entire new application by adding approximately 20 percent more application-specific functionality.
ALSO NOTE: in the FB idiom, CRUD becomes ACDL (Add/Change/Delete/List)
ALSO, there is a concept of "small batch transaction module" in FB. That is, a set of records (known as a transaction module) which is intended to be validated and posted to some "master" FB file, can be created and and validated as regards numeric accuracy and "where-posted" correctness, before being applied to some master FB file. The transaction module is entered and listed, displaying numeric totals and hash totals, which validate the numeric postings, and then, once "known good" and balanced with (for example) adding machine or cash register totals or the like, can then be applied to the master file as known-good transaction data, with a small batch "posting" run, often using the pre-written functionality in the FBPOSTDETL.go program.
---------------------------------------------------
FOR ME: I need to decide what the most important primitives are, and attempt to code those and then immediately re-factor those into modules that might be re-used, in other FBxxxxx programs... Perhaps FBTABLE.go and FBUPDATE.go are naturally the first needed, but (perhaps) FBSORT to drive Windows sort primitive would better establish "long strings==records" primitive design details and also needs t/b "done early, so as to have a tool to help build the rest of the system.
ALSO: Much detailed design should be written up. And I wish to write that first, even though I know it will change (perhaps drastically) as FB is coded.
EXAMPLE DESIGN QUESTION: Should I store meta-data as a group of special records (defined by FBTABLE.go) at the head of each X.DT main app data file (master file) that w/b opened and maintained by FBUPDATE? OR would it be better to have that as a separate file with some FB-system-standard file extension, such as X.TBL or X.META?
(Note X.DAT name convention is avoided in favor of X.DT because .DAT is used as convention in so many other DOS/Windows application contexts)
Note: this is an enormous amount of 3gl code to complete the entire system. I will need to do clever design work to useful common routines-- NOTA BENE: I have already decided to skip "cursor control friendliness" and replace that with pure linear text prompt and response for user input and user controls-- emphasize the file primitives first.
ALSO-- I need t/do priorities: 1st things first -- should I start with FBTABLE.go or FBUPDATE.go?
One design symmetry for sure: All data is stored in nnnnnn.DT (aka <>.DT) files: VNOR's (Note: VNOR stands for "variable number of records" and designates a "natural" sub-file of detail records "owned" by a "master" application data record (a particular record "key" in the 'master' file). For example: credits and debits detail line items relevant to a particular ACCOUNTS RECEIVABLE master customer record are VNOR in relation to some master customer key.
Sort file specifications, will also be in self-supported metadata files (But how in detail? -- Candidate answer: Actually c/b in X.DT-structured files, with extensions per "FB file type"-- e.g., X.IDXnn for index (sorted) file, where nn is 01, 02... nn for as many indices as needed.
Other design decisions: What about code-to-string translations for numeric
code fields? Answer: in X.DT-structured files named X.Cnn where nn is the FB field number. Heuristic assumption is that all these files c/b "slurped" by FBXXXXXX.go programs when needed. ON SECOND THOUGHT specifically for numeric codes feature: numeric codes in applications were (back in the day) mostly to save memory and disk space by saving short numbers and later supplying string translations for numeric codes at app-display time. With both disk and memory SO incredibly cheap this is NOT NEEDED any longer. Accordingly, we skip this design wrinkle, adding it later or not at all.
FB supports (by default) 60 fields, approximately 40 of which display on one screen at any given time. The 2nd column of data fields (21-40 or 41-60) and their labels and data are switched in/out of view by some command at the ACDL/CRUD prompt of FBUPDATE.go et al as needed.
---------------------------------------------------
Some data & file naming conventions:
A particular FB-NAME-STR string is chosen (Note- restrictions are same as Win7/
Win10 disk file name string rules. However, it is recommended that short,
concise FB-NAME-STR be chosen, for each FB-supported application. Maximum of 14 to 20 characters is good heuristic to use for FB-NAME string length.
<FB-NAME-STR>.TB => FB table meta data storage file
<FB-NAME-STR>.DT => FB actual row/col (record data) is stored in .DT
file. Heuristics: Record is long string, fixed length. Ea. field in
each record is also fixed length, with maximum size embedded in
<FB-NAME-STR>.TB metadata for each field. Data types are simple primitives: String / Numeric / "Pointer" -- Metadata may contain references to particular data validation routines that may be application-specific. For example, "date" type c/b yyyymmdd numeric, with <>.TB meta-codes for display specifics and validations.
[[design intent: keep code library of callable routines for application-specific
[[data validation, use <>.TB metadata to call out those routines,
[[for particular data fields (columns) in <>.DT
[[ Pointer data type denotes multiple sub-records that are key-linked sub-records
[["owned by" particular <>.DT master record instance.
[[Design possibility: Pointer type particularization *PERHAPS* could
[[designate/point to serial data and/or variable-length data. If this is
[[done, do it 'later' (allow 'design space' in <>.TB file, etc.) ]]
<FB-NAME-STR>.SBnn =>
FB file name convention for sub/detail record data for FB master record field number nn (2-60) "SB" mnemonic for sub-file NN for field number 1
NOTE: <master-rec-key>+<master-rec-fld-no> is file key for <>.SBnn, then append <SB-nn-'key'> forms unique sub-record for a particular SBnn record.
-------------------------------------------------------------------------------
Part 1 design decisions and "doing-the-project" notes
-------------------------------------------------------------------------------
* <FB-NAME-STR>.TB creator code is to be done first. That is, FBTABLE.go
(At least for now, FB program filenames w/b all u-case with <>.go extension for
Golang versions; <>.py for Python and so forth).
* FBUPDATE.go (simple linear prompt/response data record creator/updater) w/b
next.
* For start, think of a small, address list Fbase app as a candidate target application,
such as a family might keep for Christmas cards.
* For ease and testing, FBLABEL.go might come next after-- i.e., FBLABEL.go is a report program that prints address labels.
Some heuristics: <>.DT data is all ASCII character text-- keys are always numeric characters, zero-filled to 6 places-- representing position in a master file 1-999999. Logical (application-defined) keys are called Lkeys pronounced "ell-keys'. Pkeys (pron. pee-keys or poskeys) are positional per file position, and always displayed when records are displayed. Pkeys are stored as ASCII numeric-characters data.
<>.TB data will be in <>.DT compatible format-- viewable and editable using FBUPDATE.go or (perhaps) a slight modified FBUPD-META.go which is aware of <>.TB file structure and