>>Hello,
>>
>>In the past I have broken data normalization rules but I am swearing that off :) I also want some table columns to be defined in a data driven way.
>>
>>I'm asking for help to see if I am missing something important. Please give me your comments and criticism as I need to make a choice soon and don't want to make a bad one.
>>
>>Say you have the following tables:
>>1. Header Table
>> header_id, other fields
>>2. Child Table
>> child_id, header_id, other fields
>>3. Table with name and value of "virtual fields" of child table - One record for each virtual column that has a non default value
>> Virtual_id, child_id, ColumnName, ColumnValue
>>4. Data dictionary with name of all possible "virtual fields" of child table - Contains description of all possible virtual columns
>> ColumnName,ColumnType,ColumnWidth,ColumnPrecision
>>
>>I am considering the following approach to integrate data from tables 2 and 3 during user edits:
>>I use Codemine framework which makes it relatively easy to go the cursor approach.
>>- Create either an object or a cursor with the following properties / fields
>> child_id, header_id, other fields from child table, VirtualColumn1, VirtualColumn2, VirtualColumn3 etc
>>- Update base tables as user makes changes
>>
>Instead of step 3 you might consider the route of NoSQL,
>which can to a part be simulated in vfp utilizing 1 memo field filled with key/value pairs
>
>Formats well adapted are Ini,JSon or Xml.
>Saves a lot of Join work but leaves you with packing worry for high-write setups.
>There is no rule that you cannot employ DD setups like step 4 such NoSQL/EVA hybrids
>- I even think it is a good policy ;-)
>
>regards
>
>
>thomas

Thanks for the lead, Thomas.

I have been considering the approach described in points 1-4 above because I want table structures that are stable yet adaptable to new situations. In the past I have modified table structure regularly to accommodate new needs and that is not satisfactory.

Now I have a new application and I want to follow best known practices. I thought the approach I was considering was a "best practice" but I have heard enough negatives now to keep looking for better ways.

The way you suggest sounds flexible, fast and easy. You say you think it is a good policy. Can you comment some more on that?

Alex