Jump to content

Performance/File Size = Num Records or Num Bytes?


This topic is 7823 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

??

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 7823 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.