Peter,

While I find myself agfreeing with most of what you said there are a couple of things I feel the need to comment on.

>Summarizing it all : when the logical datamodel is normalized properly 100 % AND you apply this to the physical model, you will be having more tables opposed to less normalization, you will be having proper PK's, you won't have ANY CK, and you will be having FK's on all the users will ever need to sort upon.

Your reference here to CK's is totally offbase. Having a CK has nothing to do with normalization at all. It is totally possible and acceptable to have a table strucutre with more than one set of fields that satisfies the requirements for being the PK. Whenever this happens you have a CK. If you ignore the existance of the CK then you can never reach Boyce-Codd Normal Form( which immediately follows Third NF).

>Relators should have two logical fields only for the FK's, and a normal PK over it, and an additional reversed index.

Again, with normalization there is no reference to using Intersection tables at all. Intersection tables are only *** required *** for resolving many to many relationships. Although you can use them anytime you like, if you are dealing with a relationshiop that can never become many to many you adding unnecessary complexity to your data design.

>One thing (where I'm about to loose) : it is all native VFP tables, with the 2GB as a pain in our neck. So we are converting to a remote DBMS, and it is there where the views will come in. I'm pretty sure response will be worse, though nobody will believe that.

You may be surprised. The speed of VFP versus database servers has changed. Used to be VFP was hands down faster, that is no longer the case today. SQL Server 2000 can as fast and even faster than using VFP tables over a network. I am not familiar with Oracle but I would venture to guess that the situation there is similar.

>I honestly think you are wrong here, and maybe you didn't test it properly;
>with the non-remote dbms (i.e. native VFP tables on the fileserver) optimization is done within the PC.

Here you may be mistaken, Rushmore uses indexes for optimization, hwoever it is not necessary for the Worekstation to download the entire CDX file. VFP is smart enough to understand the structure of its indexes and use only the amount it needs. VFP also does a lot of caching of data in the background for optimization.

With Rushmore optimization the largest factor in performance IS the number of records in the result set. Also Rushmore applies both to SET FILTER and Views equally.

>Now I think of it : remember Jim Nelson's VFP8 whish "a server object" (or so) ?

Hmmm... I have one of those on my computer. It is named SQL Server