What are the practical record # limitations? 500k?

[SoCalMacDude]

Looking to build an image database for search on intranet. Thumbnail names would be calculated within the database, html page would call the thumbnail from a huge hard drive.

Could it handle 500,000 records (finds only, no sorts!)?

Has anyone pushed the limits? How many records do you have?

What's a better choice (and is it easy to handle)?

Thanks ...

[Vaughan]

FMP's limits are 2G records, and 2G file size whichever comes first... where G=giga. Lots of room there.

There may be better technologies, but they're gonna cost orders-of-magnitude more to develop, set up, and run. (I'm thinking SQL stuff.)

[Unable]

In the Sample Files forum you may find some useful information/examples on serving images on the web with FMPro.

Good luck.

[SoCalMacDude]

Are you saying 2 Billion records?

What is practical? How many records can you search within reasonable time (10 seconds?) without it choking?

Anyone have an example fully populated on the web? (Please note how many records it has!)

[Kurt Knippel]

I do not remeber seeing and limit on the number of actual records.

The amount of records that can be searched in a reasonable time without choking is almost undefinable. Indexed searches take miliseconds even on millions of records. Unindexed searches can take ages even on only a few records. Also large found sets can result in slow "perception" of performance as a big record set needs to be cached on the local machine.

I will usually limit users to a max of like 2000 records. A normal person can only deal with a dozen or so at one time anyways, but it is easier to present them with a few thousand and let your interface restrict it further.

[Anatoli]

Ok, I have database with 8500+ records with all PR articles for full ITC industry.

Small search/sort/serve is up to a second.

Fulltext search/sort/serve for letter "a" which is actually finding all records in database is 6 seconds.

Fulltext search for "mode" will find modem and model, actual found set is 1839 records, sort and serve up to 4 seconds.

The server is in Europe/Prague and I am testing this from LA.

The secret is to limit displayed result to 10-20 records. That is instantaneous. I guess 90% of the time is search.

Windows NT, Celeron II, 1300MHz/256k, ATA Barracuda 7200 RPM, 256MB, 133MHz bus, slow 133MHz memory.

[Steve T.]

We have a small DB (800 records) but discovered that ANATOLI's SECRET really is critical to speedy operation on web. Limiting displayed results to <20 at a time is QUICK, while leaving it open-ended took many minutes, even on "small" search results of about 200.

I don't think anything will be easier or quicker to develop than FMP. Another Mac option is an AMP system (Apache-MySQL-PHP) but I'm still learning about this so cannot recommend it yet.

MAC ADVICE: I suggest going FMP-Unlimited on pure Mac OS X w/no classic installed. We haven't had a problem after switching from 9 to pure X, but other folks seem to be getting Unexpected Quit's, even on X (similar on Windows, too). Some OS X and Windows folks have no problems, though, but I have not seen a good fix yet, just workarounds. If it happens to you and you can't solve it, look at CRON from the Terminal command line to re-boot every day during non-peak. Good luck.

[Anatoli]

It is not my Secret

It was recommended by FMI

[Steve T.]

Sorry, Anatoli ! Didn't mean to imply you were claiming credit for discovering it.. just crediting you for bringing it up !

You, garry, jeff spall, along with the hosts/moderators, et al. together help make this forum the best on the net ! You'll never convince me to swtich to Windows , but your contributions to this forum will always be appreciated (except perhaps by Keith Davie who I haven't seen around much lately). Keep it up!

[Anatoli]

RE: You'll never convince me to swtich to Windows

I am not trying to do that In any case -- if someone is happy with his/hers tools, why to change it?

That goes both ways to Mac and Windows users.