Performance/File Size = Num Records or Num Bytes?

[kennedy]

There seems to be much angst in this forum about inclusion of images increasing file size. Well, clearly a database's performance is highly related to the number of records (one measure of file size). But it need not be so critically tied to the number of bytes in each record, depending upon how the DBS is implemented.

QUESTION: Given a database with 25,000 records, how much does FMP performance degrade for these cases:

A) "Portrait" is a Text Field with a 40 character short description

: "Portrait" is a Text Field with a 40,000 character long description

C) "Portrait" is a Container Field with a 40KB Photo image

??

[Kurt Knippel]

Generally it depends upon the implementation, stored vs unstored, indexed vs un-indexed, displayed on screen or not, amount of calculations, etc.

Option A results in a DB of at least 0.95MB, and should not cause any kinds of performance issues.

Options B & C both of which are 40kb, both result in a DB of at least 976MB and could cause performance problems.

But it really depends upon what you are doing.

I have one DB, where a few (77 records) hi-res images were stored and it was horribly slow, until I moved the images out to a secondary DB, then it was pretty quick. Now I believe that this was due to the fact that this DB was used as a reference DB by many other DBs, but the images were almost never used by these reference DBs. In this case the size of the DB is what was causing the slowdown, as these DBs were forced to open the DB with images, when all they needed was a small piece of text.

I have another set of DBs which store digital photographs, and display them in sets of 36, 6, 4, 2 or 1 depending upon user preference. This DBs contains a stored thumbnail, as well as references to both low and hi resolution photos. I do not notice any performance differences between versions of this DB with 10 photos or those with 20,000 photos. This biggest bottle neck for this seems to be the speed of screen refreshes.