On 3/12/08, Drew Jensen <[EMAIL PROTECTED]> wrote: > > Which brings me to point two. > 2) Referential Integrity is not always that big a deal...( oh the heresy > ;>). What I mean is that in a desktop database for personal use you can > often get by with just using the features supported in Form->SubForm > functions without actually creating the FK relations. If you are not > going to be importing data from other databases and not going to be > doing updates with SQL INSERT statements then not having FK's setup for > the tables is not really that much of a problem. The form->subForm > mechanisims still work, you can still do joins in queries to generate > reports and the like, just fine. > > So - for what it's worth my advice would be to go ahead and leave the > AuthorID fields in the Book table. Make the first one "required" and go > ahead and make it a FK to the Author table in the GUI relation designer > if you like. Then when you create your form for Books just use a drop > down list box for each of the AuthorID fields and you will be fine.
Drew, I'm familiar with the ideas behind the explanation you provided. Point two though prompts a question. Using form->SubForm to enforce relationships for editing and viewing the data requires that the relationships be created consistently for any form that needs to display the relationship. On the other hand if the point one technique is used the database maintains the relationship between the tables and any tables/fields on any form are then constrained by that relationship. In other words define the relationship once, in the table structure, then see it "automatically" enforced whenever those tables are used. So the question is, wouldn't relying on maintaining relationships in the forms lead to a less maintainable database? If no then why not? Thanks.
