Hi Craig, Sorry for this long post, which is meant to clarify the previous one.

1) Here is a description of a transaction table that we use in our VFP product. Below I explain how we want to do it differently in the new project.
* Beside ID, foreign keys, and other such fields, the transaction table has many fields of two general types: hours worked and income received.
* The hours worked fit into different types. Just as examples: Sunday regular time, Sunday day overtime, Sunday night overtime, Sunday day overtime with surcharge1, Sunday day overtime with surcharge2, etc, etc, etc.
* The income types follow a similar variety of types.
* These income and time categories need to be kept separate because thay have many different business rules regarding how they are paid, what taxes are they subject to, do they accumulate for severance, and a long etcetera.
* Here is the description of our current transaction table, just to show the immense number of fields that it has, and that continue increasing
CREATE TABLE pling FREE (FREE (NPLA N(5,0),NTRA N(8,0),CCODEMP C(6),CCODSUC C(3),CCODDEP C(6),CCODDIV C(6),CCODHOR C(6),CCODCCO C(6),CCODPRO C(8),CCODSPR C(10),NORDENPLA N(5,0),NSALHORA N(10,6),NSALHORA1 N(10,6),NCOMISHORA N(10,6),NHR N(6,2),NHRFER N(6,2),NHRDOM N(6,2),NHRDOMREG N(6,2),NHRJORMIX N(6,2),NHRJORNOC N(6,2),NHRDIALIB N(6,2),NHSD N(6,2),NHSM N(6,2),NHSN N(6,2),NHSDR N(6,2),NHSMR N(6,2),NHSNR N(6,2),NHSDD N(6,2),NHSMD N(6,2),NHSND N(6,2),NHSDDR N(6,2),NHSMDR N(6,2),NHSNDR N(6,2),NHSDF N(6,2),NHSMF N(6,2),NHSNF N(6,2),NHSDFR N(6,2),NHSMFR N(6,2),NHSNFR N(6,2),NHSOBACUM N(5,2),NHTP N(5,2),NHTNP N(5,2),NHAJ N(6,2),NHANJ N(6,2),NHCM N(6,2),NHCMDISPON N(6,2),NDIFREDOND N(4,2),NHAJUSTE N(6,2),NSALHAJUST N(8,2),NTHORASREG N(6,2),NTHORASST N(6,2),NSALREG N(8,2),NSALSOB N(8,2),NCOMIS N(8,2),NBONO N(8,2),NBONO2 N(8,2),NBONO3 N(8,2),NBONO4 N(8,2),NBONO5 N(8,2),NBONIF N(10,2),NGRATIF N(10,2),NNAVIDAD N(10,2),NOTROSING N(8,2),NOTROSIN2 N(8,2),NOTROSIN3 N(8,2),NOTROSINX N(8,2),NLICMAT N(8,2),NLICRP N(8,2),NLICENF N(8,2),NBONOXIII N(8,2),NAJUSTE N(8,2),NSALBRU N(8,2),NTACUVAC N(10,2),NVAC N(8,2),NDIASVAC N(3,0),NTACUXIII N(8,2),NPACUXIII N(8,2),NXIII N(8,2),NPARTIC N(10,2),NINDEM N(10,2),NINDEMREC N(10,2),NPRIMA N(10,2),N6PORC N(8,2),NPREAVISO N(8,2),NBONOASIS N(8,2),NTRANSP N(8,2),NVIATICO N(8,2),NTACUGRVAC N(8,2),NTACUGRXII N(8,2),NPACUGRXII N(8,2),NGASTOREP N(8,2),NGRVAC N(8,2),NGRXIII N(8,2),NOTROSGTO N(8,2),NOTROSGT2 N(8,2),NOTROSGT3 N(8,2),NOTROSGT4 N(8,2),NOTROSGT5 N(8,2),NADELANTO N(8,2),NTNOGRAV N(8,2),NTPAGSS N(8,2),NSS N(8,2),NTPAGSE N(8,2),NSE N(8,2),NTPAGISR N(10,2),CMETODOISR C(1),NISRFIJO N(8,2),NISRADIC N(8,2),NISR N(8,2),NTPAGRP N(8,2),NSALNETO N(8,2),LDESCONTAR L,NDEDUCC N(1,0),NTFONJUB N(8,2),NTFONCES N(8,2),NTDED N(8,2),NTDEDLEGA N(8,2),NTNETO N(8,2),CPERIODO C(6),NESPECIE1 N(8,2),NESPECIE2 N(8,2),NESPECIE3 N(8,2),NESPCOMB N(8,2),NDIETA N(8,2),CMETCAPHRS C(15),LCALCAT L,LIMPORTAR L,LCALCULOS L,LPOSTEADO L,LCHEQUEIMP L,LEFECTIVO L,CFORMAPAGO C(1),LCANCELADA L,NEXTRA0 N(10,2),NEXTRA1 N(10,2),NEXTRA2 N(10,2),NEXTRA3 N(10,2),NEXTRA4 N(10,2),NEXTRA5 N(10,2),NEXTRA6 N(10,2),NEXTRA7 N(10,2),NEXTRA8 N(10,2),NEXTRA9 N(10,2),CSTATUS C(3),CSEMAFING C(8),LGRVACPISR L,LGRVACPSS L,LGRVACPSE L,LGRXIIIPIS L,LGRXIIIPSS L,NTGASGRAV N(8,2),NTNOGRAV2 N(8,2),NTPAGSSXII N(9,2),NDONAC N(8,2))

2) I want to replace this structure by just a few tables:
Table pling with fields global to the transaction
Table pling_detail, an Entity-Attribute-Value table with a record for each non zero money or time value
Table Attributes, a table that describes all possible attribute types, with the corresponding business rules

3) At run time I would like all values related to the transaction to appear as fields in a view or as properties of a BusinessObject
I'd like the framework to facilitate this arrangement so it would be trivial to add a new time or income field
If the new app were written in VFP I could write the necessary code, but since it will be unfamiliar language I'm looking for help from the framework

I don't know is the problem is is any clearer now.

Thanks for the help.

Alex


>I'm not sure I follow what you're asking. Can you provide an example?

>Thank you for the answer Craig. I think I have not expressed myself clearly. I don't want to overstate the frequency with which attributes will need to be stored as records in Object-Atribute-Value tables (or is it Entity-Attribute-Value) rather than as columns in the application we are developing.
>
>Most of the attributes of our BOs will be known at development time, but we have found that an infinity of new types of time and income categories (that follow different business and tax rules) appear as time goes by and we don't want to create new columns in several tables every time this happens. Rather, we would like to store time and income values as records in a detail table rather than columns in a transaction table, yet have them show up as attributes on a transaction BO. That is what I mean by storing some attribute values as records rather than columns in a table.
>
>We would like this to be handled by the framework we choose. I anticipate there would be an attribute definition table with defaults that is referred to when adding properties to BO.
>
>What do you think?
>
>Alex
>
>
>
>
>
>>If you're going to store business attributes, you may be better off with a NoSql solution such as MongoDb.
>>
>>If you want tools to help automate database evolution, go with SqlServer and use Entity Framework along with EF Code Migrations. Small customer sites can probably get by with SQLServer Express.
>>
>>If you want a no-cost SQL solution, look into Postgress rather MySQL, but you'll give up the automation of Code Migrations.
>>
>>Use a good CSS Framework, such as Bootstrap. Don't roll your own CSS.
>>
>>>A short while ago I wrote about our wish to migrate a successful vfp app to a language with a more abundant developer supply long term.
>>>
>>>As a cautious first step, we think it would be good to start with a smaller new and related app in order to gain experience. So this thread is about that new app. A big goal is to choose tools that give developer productivity and avoid the need to write repetitive code.
>>>
>>>So far we are leaning in the following ways but are open to suggestions:
>>>1) Web based
>>>2) .NET
>>>3) Undecided between SQL Server and MySql for reasons of cost to customer vs advantages to developer (what are the advantages to developer?)
>>>4) Use MVC framework
>>>4) Use tools that automate database evolution at user site
>>>5) Use tools that simplify business rule evolution with valid date range for the rules
>>>6) We would *really* like it if the tools we chose allow us to store some BusinessObject attributes in Object-Attribute-Value form rather than exclusively as columns in a table
>>>
>>>All comments are welcome.
>>>
>>>Alex