CompuServe Messages

DM> What I really had in mind when I spoke of including the lookup table DM> in the same file was the ability to use all the related component DM> files in a simple non-relational database program or spreadsheet, DM> including the auxiliary lookup tables. Yes, I read that into your message, which is why I responded as I did. But lookup tables imply relationality. Flat-file databases rely on one file to have all the data, resulting in repeated info that is subject to corruption or mangling (if you change the abbreviation for BLACK from BK to BA, you have to make sure you get ALL the occurrences of K or you've mangled things). DM> Many spreadsheets can open a DBF file, but I am guessing if there is DM> a collection of related DBFs, the spreadsheet may have to open each DM> DBF individually, then require some manual setting up of VLOOKUP DM> functions and the like to expand the super-abbreviated fields. Is DM> that right, or do spreadsheets actually recognize relatedness and DM> somehow adapt to it these days? No, that's right. With any Xbase system the relationality has to be programmed in, it's not part of the table structure, and that drives the database purists nuts. One important aspect of a "true database" is that the rules for data access and validity are part of the database and not part of any program. Xbase and flat ASCII files and most spreadsheets all fail that test. But the data are usable <g> to the rest of the world, at the possible expense of security and data integrity. DM> All the time I see spreadsheets, DM> database managers, word processors, and desktop publisher programs DM> evolving to have more and more of each other's functions built in. Part of the lure of "suites" is the linkage between the parts. The latest versions of WordPerfect have significant spreadsheet capabilities, too, and the mail-merge in WP is really a database in disguise. Shoot, they're all just databases of some sort or other when you look under the hood, it's just the sheet-metal that's different. DM> Anyway, I guess a non-relational DBF file is widely useful, if not DM> quite as widely as text, but if we introduce the relational aspect, DM> it gets compacted further, but no longer very useful to any but DM> relational database programs. Yes. One thing I would like to build into the registered version of the relational program is the ability to spit out the user's choice of fields into another DBF so that the user could select fields, including lookup fields from related tables, and generate a flat DBF or ASCII file for importing into something else. Main reason for relationality in this forum is to minimize the download size, isn't it? DM> I'll have to make a separate table for localities for my collection DM> catalog as well as my minerals/localities database; there are so many DM> entries for Franklin, for example, that both databases would shrink DM> dramatically. I'll bet. Yours in freedom, -=< Angus Scott-Fleming >=- GeoApplications Tucson, Arizona * TANSTAAFL * Database (n.) more information than you'll ever need.