I use DF a LOT... Basically, I use DF whenever there will be lots of additions,
deletions, or searches. If my data is fairly small (i.e. just a few forward
chains), and fairly static, I go with a flat file. DF adds a bit of overhead,
like any database would, but the benefits far exceed the minuses.
Quote:
> Hi, TPF guys:
> I am sure some of you ever used or are using TPFDF (TPFDB). As I
> heard, there are more and more TPF workshops are approaching to apply TPFDF
> in their system. Some big shops have been utilizing it for many years. And
> TPFDF becomes a standard to apply on their new records, even on the
> temporarily used work records. In some extreme case, conventional files
> were a history that only allowed to survive in the old records, which were
> defined before TPFDB was created / implemented and whose related package
> have not been rewritten yet.
> Yes, TPFDF has a lot of advantages, which simplifies and standardizes
> the record I/O accessing with macro calls. To programmer, the chain handling
> becomes no longer a nightmare and they are enabled to accomplish some
> complicated process with few codes. Just append/insert/add and meanwhile
> TPFDF still maintains all the logical records in proper, organized order
> perfectly. (Absolutely, he is a hard worker behind the scenes, those who
> ever traced it will agree on that.) For some programmers, it is longing
> relief and regarded as an upgrade that promotes TPF's DB handling with
> SQL-alike syntax. Others might feel the coding (calling) is going dry and
> less challengeable. System may be getting more stable since the dumps
> associated with I/O error are more likely to be decreasing as well as the
> records can be maintained with less effort. But the system also copes with
> the monster that has a good appetite on CPU resource. As the CPU's computing
> capability is improving and memory's price plunging year after year, for
> some shops, that may not be a big issue to keep them away from implementing
> it.
> There are so many controversial issues around this topic, but I
> haven't seen related discussion in the Internet/ Newsgroup. Maybe it has
> been regarded as an inevitable trend as it naturally came along with some
> packages that prevail in this industry. And once a shop implements it for a
> certain package, people might like to exploit more value from it, instead of
> wasting its shining features.
> I believe TPFDB is a valuable tool and with which there are plenty of
> requirements can be well fulfilled. But since it is a tool (or utility)
> instead of a foundation, I wonder if it is worth using it all-inclusively
> through out the system? Or we should have an another thought like - TPFDF
> should be used where it needs to or where it better fits with.
> OK. Here is my question, assume you agree with my point, - Is there a
> criterion that you ever applied or ever thought of to determine when, where
> or how a TPFDF should be used, instead of a conventional file? Surely, your
> experience or comment about TPFDF using or the comparison with conventional
> file will be very helpful.
> Many thanks
> Rick
--
Chuck Rush
Pond Rushes, http://members.home.net/crush11
N. Texas Water Garden Society, http://www.ntwgs.org
Anti-spam note - to reply, remove the _nojunkmail from the address.
Si fallatis officium, quaestor infitias eat se quicquam scire de factis vestris.
If you fail, the secretary will disavow all knowledge of your activities.