FileMaker thoughts from a FileMaker user
I received an e-mail this week from one of our customers who uses both Alpha Five and FileMaker. Considering our FileMaker debates that raged this past summer, I thought this customer brought up some very interesting points in his experience using both platforms that would be worth sharing here.
As he still has Filemaker Client's, we won't reveal his identity. So for now, let's call him Mr. X. Here's Mr. X's story, as he wrote it:
I use both FileMaker and Alpha Five. Both have very good points. But I thought you'd be interested in this observation.Actually, one of our Alpha team members did a little online searching after reading Mr. X's e-mail, and found that many FileMaker users are becoming frustrated over these typical FileMaker issues.
Some areas that FileMaker is extremely deficient in are:
Importing records
Compare importing say, 50,000 records into a FileMaker file versus an Alpha table (using similar index and field attribute settings for both tables.) Alpha will do this in minutes. FileMaker -- forget it -- go out to lunch and dinner, and maybe in six plus hours it might be done.
Import larger files -- forget about it.
Deleting records
Compare the time it takes to delete those same 50,000 records. In Alpha, it's near instant. In FileMaker, it takes even longer to delete the records than it does to import them. The common FileMaker "trick" to solving this problem is to create an empty clone of the data file and then delete the data file that contains the records. This "trick" must be done manually, as one cannot write a script to do it.
Updating large data tables Again, the Alpha edge is incredible. Try updating the 50,000 records, or even a subset of "found" records in the 50,000 records. Alpha will handle it very well. FileMaker does it, but you'll need to run it overnight because it will take ten to 12 hours OR LONGER.
Sorting records Try sorting that same 50,000 records by say, last name. In Alpha, it's near instant. In FileMaker, go to the bathroom and get a cup of coffee. It should be done by the time you return.
I am stunned at the lack of outcry by the FileMaker development community over these issues. I guess, it's they don't know other applications do it faster (much faster), or this is what they've grown use to and just accept it as the standard.
An example of this frustration is expressed in this posting.
"Slow Import
FileMaker Pro is impossibly slow in importing records, deleting records and even in doing something easy like emptying one field in a database. I have a database with 130.000 records. If you choose to import the records from a text file (which in my case was necessary because the field needed to be changed to unicode) it virtually took hours. And this is only for one field. Same problem if you need to delete a larger number of records.
If there is no workaround (I do not know of any) this problem makes FileMaker absolutely useless in my opinion."
For more Alpha vs. FileMaker info and comparisons, take a look at our previous posts on the matter.
8 comments:
Mr. Rabins,
Your Mr. X is mistaken all points.
Please see this video demonstration of the actual capabilities of FileMaker Pro 9.
http://www.applicationarch.com/temp/alpha5_blog_claims_challenged.mov
Thanks,
Chris Kubica
http://www.applicationarch.com
The comments comparing Alpha to FileMaker are so derogatory that they would be considered libelous. To post them and not allow true data to be posted in response is irresponsible. I will let Apple Legal know that your site is engaged in such libelous sales tactics. If you're lucky they will consider you insignificant and just ignore you. If you're not lucky, heaven help you.
Thanks for your comment, Chris. I've watched your video, and have forwarded it to the person who produced the original video. Watch this space, I will post his response here as soon as possible. Thanks again for reading our blog, and for the comment.
Theo, thanks for the comment. Please see my comment to Chris. If what we've posted is wrong, we'll be happy to issue a mea culpa. On the other hand, if what we posted is correct (and we believe it is) then you'll owe me the mea culpa. Fair deal?
As promised, I sent Chris's video to Mr. X. We won't reveal his true identity, as he is not only an Alpha consultant, but a FileMaker consultant as well. Mr. X watched the video, and it wasn't long before he sent me this response:
"Richard,
I watched the video and of course saw what he was doing. A MAC will run FileMaker faster than Windows because FileMaker--which is owned by Apple--was developed and optimized to run best on a MAC OS X, and not on a Windows PC. The difference can be as high as 20%.
His file was small; likely less than 500K. FileMaker isn't nearly as fast with 80MB, or 800MB files. Maybe when I get some time, I'll make a movie of running an import or file delete and let you post that. I'm not sure I could send you a file that big.
Second, he imported, what, 10 fields, and it appears that none of the fields had any calculations being performed as the exports were being imported. For example, changing 5" 1" to 5' 01", or "Blue" to "BLU," or creating any concatenations while importing.
For example, importing First Name "John," Middle Name "Paul," and last name "Jones," so that we end up with four fields of FName, MName, LName and FName+MNane+LName.
For example, changing the raw import text from 9091234567 to 909-123-4567, etc. … and doing these types of calculations on multiple fields on-the-fly during the import process will bring FileMaker to its knees. He showed you a very--and I do mean very--simple table.
Right, I forgot FileMaker doesn't offer a default field format for a phone number.
He also appeared to have no indexes set and few field properties set. Having no indexes on the table will speed the import, but who would have a table without some indexes, like on LName, Phone, State, DOB, etc. ... (key fields). Index fields are really required to do any serious data processing.
Also, not having any field calculations being performed as part of the import, or updates, etc. ... shows how one can really make the results favor just about anything one would like.
He also did not include any files, such as pictures (jpg images of the people). FileMaker offers two ways to store these pictures: (1) in a container field--this means that the jpg image actually becomes part of the table and will bloat the hell out of the table size. Or (2) store the link to the jpg file (which is how we do it), and then as part of the import, have FileMaker update the link to display the picture. Do that on 100,000 records with 20 to 30 fields and see how FileMaker behaves.
This same behavior will apply for updating records. For example, let's say you use a stored value to hold the path where the jpg files are stored ("D:\BackPain\Images\") and the file name the field was "pict.jpg." We would need to update the link to display the picture by concatenating the two fields. Very slow to do the first time. Now change the path value to say "X:\BackPain\Images\" and now the file must update itself on all 100,000 records so that each image will be displayed for each record. This is best done overnight.
His "Find & Replace" with adding PHD to the last name is joke. I'm surprised you haven't stopped laughing. That's like doing an Excel find and replace. That's not how a database processes data. Have him run something like this: if (first(C)lastname = "C," "Lastname+" "+PHD," First(C)Lastname = "R," Lastname +" "+"MBA," LastName+" "+"BS"), etc.
Or have the file be compared against the national zip code file and add area codes to the phone numbers based on the zip codes. Do this while you are also updating the photo path location. See how many passes you must make through the table to complete the operation, and then because five of the 25 fields have indexes, watch those fields get updated AFTER the modifications or imports are done.
He also didn't talk about exporting records. FileMaker cannot create a CSV (comma separated values delimited file). It will create a merge file ["John," "Paul," "Jones"], but cannot create a [John,Paul,Jones].
He also didn't show you how FileMaker behaves when you import 25,000 new records into his 50,000 records. But without any indexes and/or field calculations being performed, it would run fast.
Oh, and ask him how he would do an upgrade on a 100,000 database with multiple tables. In FileMaker, one must export and import all the records from all the old tables to the new tables because FileMaker is a unified file system. One cannot just drop in a new form, or procedure to modify an application. Can't do that with Alpha either, but Alpha is easier to handle upgrading an application than FileMaker."
Some interesting points to keep in mind. I still appreciate your comments. This kind of dialogue is what our blog is all about!
I just returned from a major educational tech conference where both Apple and Filemaker had ajoining booths.
Spoke with both a Filemaker SE and two very well known & highly respected Filemaker developers (must be good, or else Filemaker wouldn't have them in the booth).
We talked about this exact issue -- Filemaker speed for imports, exports, deletions, etc.... All agreed that it was very slow when field calculations are in use and even slower when images are present.
The two developers stated that this was a long time complaint / request with Filemaker to address these issues. The Filmaker SE did not dispute the comments. His only response, was "yeah, but it does so many other great things, etc..."
No one is making derogatory comments. As Sgt Friday said " ... nothing but the facts, maem, nothing but the facts..."
This is for Mr Filemaker .... "report you to the legal people..." person
What the hell are you doing browsing an Alpha V blog??
If Filemaker was the best desktop RDBMS product that you so want so badly to beleive it is, then why are you wasting your time or worrying about what a bunch of AV people are saying. Why do you even care?
My guess is that Filemaker isn't "quite" what you'd like it to be and you are still looking for something better. In many ways (not all ways), AV is better -- your quest is over -- you found AV. Welcome. Come join the AV club.
Plus Filemaker (Apple) are BIG boys. They can take of themselves. God knows they've got tons of legal eagles to do their fighting. They certainly don't need you.
I suspect you are another MAC nut who is still upset that Windows won the computer war. GET OVER IT. Both MAC and Windows have their place in the world and with ~ 5% of the US market (2.8% worldwide), MAC will live.
As much as folks complain about Bill Gates and Windows, I still prefer his open architecture philosphy to the closed philosophy of Steve Jobs. If Apple doesn't build it or authorize it, it ain't working on a MAC. Windows isn't that closed-minded.
Apple works in the old Big Blue (IBM) mentality .... "if it's not our stuff made by our people, then you ain't gonna run it on our machines."
If the computer war was won by Apple, I am convinced that computer prices would be 10 times what they are today. Apple doesn't give anything away. The next time you buy a MAC, get on your knees and thank Bill Gates, because without Billy G, Steve Jobs would have priced that MAC at $10K, and not $1,500. The only reason that MAC costs less than $2K is because Steve knows consumers would buy a Windows computer instead of the over-priced MAC. Windows competition keeps the MAC prices almost reasonable.
To Mr. X,
"One cannot just drop in a new form, or procedure to modify an application. Can't do that with Alpha either, ......"
Yes you can, but it must be done with xbasic. If you look in the code archives on the Alpha site and look for the "Export/Import" routine you'll find an early example of this.
Thanks,
Jim Chapman
Post a Comment