a sequential file whose items point to other files?

[jarych]

I'm thinking of a program. I am planning to take user input to make a file; and then the items in that file will point to other files which will hold records. This must be messy to design. The thinking is difficult and guess is that this is not the best way to think.


Program may work with, for example, holder.dat.
User uses program and wants to give information for the program to know about file to be made.
User gives a couple of requested pieces of information which are needed to identify and name the file.
One input receives cinn and other input field recieves user input 11012020. From this, a new file
is created and is called cinn11012020.dat.
At a later time, or maybe during the same session, the user may give information for a new file to be kept.
At the appropriate new file info fields user gives grndpepp and 12252020, and so the name of this file becomes
grndpepp12252020.dat.

Now, the program has that holder.dat file which contains the two items, cinn11012020.dat and grndpepp12252020.dat
and in addition there ARE two files present which ARE cinn11012020.dat and grndpepp12252020.dat which may or may not yet have any information appended into them.


Either is this way of arranging a good idea, OR can this be handled better, maybe more easily?

[Rod]

There are lots of data base examples to seek out on the forum and at the files archive. There are many ways to hold information but individual files for each set is probably quite complex. Does the file exist, is it open, polling through all files etc etc.

This is why most data is handled either directly as an array() or halfway house as a RAF. Ultimately the data will be stored in a file but it is cumbersome to access files, easier to load a sequential file to an array() and easier to open the file as a RAF and skip about with put, get and seek.

The size and typical use of the data will better determine the storage structure. Can you just talk through what the database will hold and how generally the data will be used.

[jarych]

Let me try describing an example to represent how I am thinking, just for form.

Long and hopefully not a mess ----

A home resident uses a double edge razor for routine grooming to shave the beard. He would like to try some different product blade samples
and make some records of how each sample performed. He may go through from about 20 to 50 different blades samples; some are duplicate products
and some are not. He does not know how many uses he will get from each or any blade sample, but this is something he will count, and
keep a record. One reason for keeping these use records is because after so many blade samples and so many weeks or months, he would not
remember how any given blade was in use.

He may want a computer program dedicated to helping him keep track of the shaves he does for every blade sample he tries. Normally the way he
uses the program is to fill a form for a shave having been performed. Some of the essential information to input for a shave may be
date done, WHICH sample blade, level of irritation, and how many shaves now done on this current blade; and possibly some other data to be included.

One of the program's basic requirement is that the user must put in information so program will create a file for EACH blade sample.
Each shave record is dedicated to a specific blade sample. The record for shaves done with a particular blade will all go into one file, for
just that blade sample.

Each blade should be identified as productnameMMDDYYYY, where "productname" could be something like "schick superior platinum" but with the spaces
removed to be as "schicksuperiorplat" in which the abbreviation is also acceptable; and the MMDDYYYY according to user's choice is either
when the blade was received or when blade sample being first used. So this blade might be identified by schicksupplat01012022.

User needs to give the program information to create this blade sample's file before he is allowed to make any shave records for it.
He will choose to give the program the needed data, and program will create a records file and call it schicksupplat01012022.dat .

The user is ready for a different blade some days later. He is ready do some shaves with it. This sample blade could be Derby and it is
called, according to the package, or label, Derby Extra, and our user will do the first shave with this on February 14, 2022. He must
give the program the needed data for make a file for this blade's records and upon putting in this data, the program makes a file called
derbyex02142022.dat .

Can the tracking, records program keep a listing of each blade sample which been used since 'installing' the program on the user's computer?
Imagine later in February, the user wants to do one more shave with schicksupplat01012022. The program should be able to show a list of
ALL started blade samples. Upon starting to give his records for a shave, he needs to go through the program to make a choice from some listing
of all the added blade samples; which are: schicksupplat01012022.dat and derbyex02142022.dat. If he chooses the schick...022, then this
set of data goes into the file schicksupplat01012022.dat. If he chose the derby Extra, then this shave's records must go into
derbyex02142022.dat.

[Rod]

Ok, good start. When you think about data you should think about data entities, not files. So there is a person, there is a blade type or brand and there is a particular blade and there is the blade’s use, a shave.

Now there may be many people but let’s assume one for this exercise. This one person has many brands of blades, the brand has many blade types. Looking from the other end any particular blade has a type,brand and person. So for any blade you can know the type, brand and person, you just need to record that once.

A shave will use a particular blade and have performance information, you do need to record the unique performance information each shave but the blade’s info won’t change. So we just need date and performance data with a pointer to blade info.

So now we have two files, the blade file in which we record the type, brand and person of each blade in use. Secondly a performance file that contains the shaving performance and blade used info.

Now we have only two files not hundreds. To find out about a particular blade we simply run through the performance file summing only that particular blades performance. Then we could sum all of the same brand or even different brands of the same type.

So think more about the “entities” within your data and don’t equate data item with file. It’s more about records and relationships.

But first hunt down and explore examples posted.

[honkytonk]

This kind of data only requires a simple array or a simple file of type:
Brand Name N-blades N-razors Efficiency ..and-more ..and-more
With each new try, a line is added.
Then, with: "word$()" we can extract whatever we want, ex:
word$(x$,1); " ";word$(x$,2);" ";word$(x$,5)

We must find another example to justify the use of a multi-file method.

[Rod]

The first file contains all of the blades in use., it is kept in bladeNumber order
bladeNumber, brand, type, person

The second file contains all of the shaving info, it is kept in date order the status may flag that the blade has been discarded.
yyyymmdd, bladeNumber, irritation, smoothness, cuts, status

That’s really all the files you need for the task. There will be about twenty or fifty blades recorded and a few hundred shaves recorded.

Because the file is small you might consider creating one flat file for analysis. To create that file you would take every shave record and append to each record the blade info. That way you don’t need to go looking up the related data for the blade each time it will all be contained in one record. So now we are down to one file or array providing everything you need.

[Rod]

honkytonk you won’t learn database methods unless you discuss or review them. Starting flat file is not really the best way to think database. At some stage you may very well need relational. In any event it is thinking data entities and not files that is the first lesson. But yes flat file is perfectly good for this task.

[honkytonk]

Jul 17, 2022 12:55:09 GMT Rod said:

honkytonk you won’t learn database methods unless you discuss or review them. Starting flat file is not really the best way to think database. At some stage you may very well need relational. In any event it is thinking data entities and not files that is the first lesson. But yes flat file is perfectly good for this task.

I would like you to give me an example of relational that cannot be done with a flat file

[Rod]

Kinda misses the point. The point is that thinking relational allows the flat file to be structured and not just become a mess of disordered duplication.

[jarych]

Maybe what I want to be able to accomplish in regarding to application user results, is too complicated for my level of competency. On the other hand, the FILES command might be a possible part of how to achieve something. If I learn the right skills for FILES command, at least the 'holder file' can be avoided. I may need to just drop the idea for a while.

[jarych]

COMPETELY DIFFERENT VIEWPOINT

Program should not need a holder file for pointing at several other files. Program may not require the use of FILES command. Instead, program could do this:
Let user create his blade files whenever each is desired. All such files will be created into the program's default directory.
Program could permit user to open any chosen file through FILEDIALOG, with suitable 'template'. User will see the list of files and recognize which file corresponds with the desired blade, and chooses the file he wants.

[zzz000abc]

hi jarych,
Important thing is whether your .dat file contains only one record or may contain multiple records?
If it contains only one record you need not create many files. Instead you can create only one .dat file containing required fields, you can make date primary key and sort your records accordingly as brand names may have duplicate entries.

[jarych]

Jul 20, 2022 11:59:03 GMT zzz000abc said:

hi jarych,
Important thing is whether your .dat file contains only one record or may contain multiple records?
If it contains only one record you need not create many files. Instead you can create only one .dat file containing required fields, you can make date primary key and sort your records accordingly as brand names may have duplicate entries.

Some further thoughts were put into what I described in my posting of July 17, 2022. Better plan may be to set up a menu-based WINDOW, and let certain buttons allow user to interact with a given quantity of ,... files. Each file contains information for a single category each. This way no file points to any other file. Each file would contribute to information to combobox controls in the further interfaces of the program. Recall I described in july 17 post, focusing mostly on one category of items. Too hard how to think of the consequences of building ONLY a text-based menu-driven program.

Very generally I am think of this kind of arrangement:

File, catogory1: itemA, itemB, itemC, etc.
File, category2: item2a, item2b, item2c, etc.
File, category3: item3a, item3b, item3c, etc.
AND EACH ITEM in its file would not be arranged in a row, but on a single line.
What I mean is that the file should look, for example, like this:

itemA
itemB
itemC

Thanks for your thoughts.

[jarych]

My posting from 2 hours ago: I am thinking about a MENU-like program that takes a form like this, at least in adding to files and viewing the items in a file; and for future planning no "holder" file and no file points to any other file.

This would be instead of trying to make just a text-based menu-driven program


   nomainwin

   WindowWidth = 550
   WindowHeight = 410

   UpperLeftX=int((DisplayWidth-WindowWidth)/2)
   UpperLeftY=int((DisplayHeight-WindowHeight)/2)

   button #main.button1, "add to file CatA", [button1Click], UL, 70, 86, 122, 35
   button #main.button2, "add to file CatB", [button2Click], UL, 70, 161, 122, 35
   button #main.button3, "look at CatA", [button3Click], UL, 206, 86, 122, 25
   button #main.button4, "look at CatB", [button4Click], UL, 206, 161, 122, 25
   button #main.button5, "this does what?", [button5Click], UL, 390, 271, 122, 25
   open "File for each Category" for window as #main
   print #main, "trapclose [quit.main]"

   print #main, "font ms_sans_serif 10"

   wait

[quit.main]
   Close #main
   END


[button1Click]    'Perform action for the button named 'button1'
   'Insert your own code here
   notice "user would give an item to file for categoryA here"
   wait


[button2Click]    'Perform action for the button named 'button2'
   'Insert your own code here
   notice "user would give an item to file for categoryB here"
   wait


[button3Click]    'Perform action for the button named 'button3'
   'Insert your own code here
   notice "user to see list of items in categoryA file"
   wait


[button4Click]    'Perform action for the button named 'button4'
   'Insert your own code here
   notice "user to see list of items in categoryB file"
   wait


[button5Click]    'Perform action for the button named 'button5'
   'Insert your own code here
   notice "Broad example illustration"+chr$(13) _
   +chr$(13)+"Lets user add items to a file one at a time" _
   +chr$(13)+"for either of two different categories, each " _
   +chr$(13)+"catory being its own separate file." _
   +chr$(13)+"User can choose too to look at the list of items" _
   +chr$(13)+"of each file."
   wait