On 19 Aug 2008 at 23:09, John Howell wrote: > Could we define our terms for the non-experts here? What the heck is > a"flat database,"
A "flat database" is a table with columns and rows, not related to any other table. An Excel spreadsheet, or a table in Microsoft Word would be a "flat database." The alternative is a "relational database," where you split your data into different tables that are connected to each other in various ways. For example, in this case, you would store your database about the music in your library in one table and the data about composers in a different table. The composers table would have a ComposerID that is stored in each record in the table with your music data. In a flat structure, you'd have to store all the information in the composer table inline, in the music table. That means you have to store it multiple times and that if you need to update it, it has to be updated each time it occurs. There are other technical issues that make relational data more efficient to search, but I won't go into that (unless you want me to!). > and why do you [Eric] say (in another message) that FMP is > one when David says it is something else? FileMaker is relational, in that you can have multiple tables that are related to each other. Now, the degree to which those relationships are enforced by FM's database engine, I can't say. There is some dispute among the database gurus about whether or not a database that lacks engine-live relational integrity enforcement, i.e., if there's a relationship between two tables, the data in the child table has to connected to the parent table. In the present example, this means that you couldn't store ComposerID 999 in your music table unless there was actually a composer with ID # 999 in your composer's table. Some database engines (like 1990-era versions of Paradox, dBase before version V, and MySQL with its native MyISAM table format) do not provide that. You can have tables that you relate yourself, but there's nothing to forces users to put in data that conforms to the relation that you've defined in your head (and, presumably, in your application). I believe that Eric said that Bento was flat file. It may be, though I didn't see it in anything on the web page about it that I read. Certainly it is designed to be simple and store unstructured data, which implies that it's likely going to default to flat file. But that doesn't meant it completely lacks the capability of storing data in related tables. I asked Eric to provide a citation that showed that Bento was more limited than FM itself. So far, I haven't seen any response to that request, so I can't say whether or not Bento is more limited than FM in this respect or not. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
