>Hi All,
>which is true ? for table desings
>table has etc. 5 column but has 300.000 record
>table has etc. 15 column but has 30.000 record
>
>which is important thing at table desings for prevent table enlarge...
>
>TIA

Both the table size in bytes, and in records, can be a problem in some cases.

The absolute size (bytes) can make you go over the VFP limit of 2 GB. Of course, the disk space itself can also be a problem, but that is usually not much of a problem with today's hard disks.

The number of records can make queries slower. That should not be a serious problem with a good design, but larger tables (with more records) can mean that you need to fine-tune your application better, before it works well enough.

I would try to use standard database normalization most of the time. This often helps you save space, but mainly, your information is more organized.

Another thing that can usually (but not always) save space is to use primary keys without business value: the primary key is an integer (incremented automatically for each record) which the user never sees. (This takes up 4 more bytes in the table where the PK is defined, but usually saves space in other tables where it is used as a FK.) However, once again, the main reason I prefer criterion for using this is usually NOT space savings, but other reasons.

And, if your database is too big, you should seriously consider C/S.