Benim yazdığım AYSPro yu Abank ın ve Telecom un Merkezi arşivinde kullanılıyor. 1 milyon kayıt var. 400-500 MB ı geçmiyor. Hiç bir sıkıntı yaşamıyorduk.
Şimdi size Filemaker ın Kapasitesi ile ilgili bir örneği aşağıda paylaşıyorum. Her paragrafı da kısaca özetlemeye çalıştım.
https://community.filemaker.com/thread/80015 yazının orjinal linki.
38 MILYON KAYIT VE SISTEM HER SABAH OTOMATIK 40-50 BIN YENI KAYIT ALIYOR. TOPLAM BOYUT 7 Gbyte.
My biggest database right now is just under 38 million records. The system does an automated import every morning and adds between 40 and 50,000 records. There are very few concurrent users and most are local to the city. Right now that 38 million record file is under 7 gigs and could be smaller if we cleared out some legacy garbage that is taking up extra index space. Backing up isn't really an issue. A quick test with the Verify Backup Integrity on takes about 4 minutes. With Verify Backup Integrity off (not recommended) it takes 55 seconds.
BİRÇOK İŞLEM ÇOK HIZLI HALLEDİLİYOR. DASHBOARD DA WEBVIEWER NESNESİ ÜZERİNDE JAVASCRİPT İLE CHATS YAPIYORLAR. iPhone ve PC KULLANICILARI Server Script ler İLE İŞLEM YAPIYORLARMIŞ. 3 DK 40-50 BİN KAYIT RAPORLAMA İÇİN DASHBOARD A ÇEKİLİYOR.
Most operations are very fast, including generating Javascript-based chats in a web viewer and grabbing summary information via ExecuteSQL for display on a dashboard interface. Even over LTE on my iPhone I can get more than satisfactory results. Most users are coming in, viewing the dashboard and getting out. This system is designed for data analysis, no data entry by users other than to generate reports. Data entry is via the daily server script to do the importing. Importing those 40-50,000 records takes about 3 minutes.
CALCULATİON VE SUMMARY ALAN KULLANIRSAN BU BOYUTTA CANIN YANAR. (summary alanı 100 bin kayıtta denesen de sıkıntı çıkarır. Bu boyutta 1 gün beklersin. )
Other operations can be glacial. If we need to change the database schema for instance. Adding a calculated field to the main data table is painful. Searches generally aren't bad. At one point there was a summary field on a layout and it was VERY bad. It's long gone. Working with smaller record sets helps a lot. We found that most users were interested in what happened in the past week or 30 days 90% of the time. Doing a search to limit those 38 million records down to under 1 million also sped things up considerably.
EĞER FİLEMAKER DA UYGUN DATA MODELELEMESİNİ YAPARSAN, KULLANICI YÜKÜNÜ VE NETWORK CONFİGURASYONUNU İYİ AYARLARSAN SIKINTI YAŞAMAZSIN. FİLEMAKER MÜKEMMEL ÇALIŞIR.
I would go with the phrase - your mileage may vary. Depending on what you're trying to do, an optimal data model and record set, user load, network configuration you may file FileMaker works perfectly. You may also find that it doesn't suit your particular needs.
EĞER KULLANICI LOGLARINI KÜÇÜK SETLER HALİNDE TUTAR VE ANALİZ EDERSEN KULLANICILARIN ALIŞKANLIKLARINIZ UYGUN YAPIYI OLUŞTURUP YAZILIMIN SAĞLIKLI ÇALIŞMASINI SAĞLARSIN.
If you've got users logging in to work with a very small set of records you'd likely find things work pretty well. If you're sorting and summarizing huge data sets with lots of network traffic you may not like what you get. FileMaker doesn't do any load balancing or mirroring of files so everything is going to come down to a few machines.
EĞER WEBDIRECT KULLANICISI 2000 KADAR OLURSA BU SAYIYI FILEMAKER KALDIRAMAZ. AMA ONDE PHP ARKADA VERITABANI OLARAK FILEMAKER ÇALIŞTIRIRSAK ÇOK DAHA ESNEK BİR YAPI ELDE EDERIZ.
You're likely not going to use WebDirect. If you've got 1000-2000 concurrent users WD isn't going to be able to handle that at this time. PHP connecting to a FileMaker back end is more sensible. If you're doing PHP you're in the realm of double-developing - building both a FileMaker back-end and the PHP-based front-end. Any system where you're using technology A to connect to database B is going to have that double development issue, doesn't matter if its FileMaker or an SQL-based system. A purely native FileMaker system will be less development.
