>Ok, I've been playing with VFP (3.0) for awhile, reading everything I can get my hands on and trying to understand how VFP thinks. Now I have two questions on approaching VFP and forms etc.
>
>1) As suggested in all of my literature, I've created a database out of normalized tables, breaking things down into individual parts to avoid redundancy etc. Thus when I need to create my forms (my project is very forms/data entry based) I need to put different parts together via relations to make the interface understandable to my users. I haven't been able to do this easily with standard form controls and most of my documentation uses forms that have relatively simple data environments with a single or two tables per form.
>
>It was suggested here that I use Views to create some of my one to many, and many to many relations which I could then use as bases for my forms. However since I can't create indexes on Views, I'm assuming I'd have to create a "complex" View that contains every possible field I'd need in a form since I can't relate my Views to my other tables in the proper Parent to child relations.
>
>My question is what is the best approach to forms which need to display related info (fields) from multiple (3+) tables? Do I forego normalization and create redundant tables? Keep fighting Views? Argh.
>
>2) I have a number of different "code" tables in my DBC, one for each type of code (there are about 20 tables). I have read where others have included all codes in one large table and included a "codetype" field to differentiate between code types. I was afraid this would slow down my app, which is a typically a better approach?
>
>Finally, *many* thanks for the information you have all provided me. You've been most helpful and your input is much appreciated by this newbie who up til now thought she was the only one on the planet using this stuff ;-).
>
>Mandy


1) You can, as I've recently learned, index a view, although you must create it at run time.
SELECT 0
USE myview
INDEX ON myexpression TAG mytag

2) Use one table for codes. With a compound index on the codetype + code you should actually see improved performance.

HTH