Do I really need table redundancies in FMP?
I need to develop a database for a bookstore that will include the following tables: 1. A book catalog 2. Publishers/ distributors catalog 3. A module to manage book purchases/ consigned items 4. Invoices 5. Inventory I'm not an expert developing databases in general or FMP in particular, but I've been working with FM for a while now and I feel pretty confident on the reliability and ease-of-use of it. However, a few days ago, I meet a developer that uses MS Access to do its work. He previously did some kind of analysis over the solution outlined above and then made an Excel file listing all the fields and tables that the DB should contain -all according to his expertise. The first thing that got me perplexed is that many of the tables on said file contain pretty few fields and that according to him, his design includes many "redundancies" that are supposed to make this DB faster and more reliable in the long run. I've never work with a design such as his but am pretty hesitant on whether or not to follow on his advice. Here's an example of what he proposes: For the book catalog, he proposes a table containing the following fields: Product ID ISBN Title Author Publisher (with a 4-digit code from another table) Retail price Another table will hold "Title number" (a redundancy in his words) and an "Alternate title" that will be related to the table above. Yet another table will hold "Author number" (yet another redundancy) and Co-author. From my perspective, I will only create a single table with all of the above fields integrated into it. My question is, is there really any benefits with the "redundancy" method or should I go with my original idea? Thanks in advance!