Page 1 of 1

filemaker and mysql

Posted: Mon Jun 14, 2004 6:49 pm
by jrough
What is the difference in a local networked database like Filemaker compared to MySQL? for example, Filemaker has a limit of 250 clients connections and MySQL is unlimited connections. Filemaker you can access on a LAN at speeds of TCP/IP where as MySQL is limited to the speed of the internet connection. I admit that when it comes to mobile offices the LAN isn't as important as it was but still I think the majority of offices use local networked databases. MySQL is scalable but Filemaker 7.0 is now able to have unlimited file sizes so size isn't as big a problem as it was with 6.0. A drawback of Filemaker is it is slower on a WAN connection.

I like the fact that MySQL is open source vs Filemaker is proprietary. You have to buy the Advanced Server for to web enable the database which has a connector to Apache but with MySQL you also have to buy the db server although it is much cheaper.


But can anybody realistically give me the drawbacks of MySQL in conjunction with PHP for printing, graphical user interface, etc especially for smaller to midsize databases.

Do users sometimes get hung up on the fact that their browser access is not as fast as an applcation. I know MYSQL is optimized for speed and Filemaker is slower becuase it is dependent on hard drive writes but now with FM 7.0 it is some calculations are done on the server and not all on the client.

It still seems for a simple database Filemaker is easier with the graphical user interface tools but perhaps if you have to spend the same time in Filemaker with writing a CGI in that case MySQL would be better?
thankx,

Posted: Mon Jun 14, 2004 7:11 pm
by feyd
well with mysql and a browser, all the calculation (that matters) is done on the server, so you can have very simple, thin clients for the end users.. which can save a lot of money. You could write an application that does all the queries and make it look just like Filemaker.

Personally, I like the flexibility and control I have over writing my own interface and application. So I chose mysql and php.

Posted: Mon Jun 14, 2004 7:41 pm
by jrough
that makes sense, so for a filemaker application you need to buy the filemaker client $250.00 for the user whereas with MySQL you have a smaller client that is installed. Sorry to be a pain but I thought the Mysql database was only the backend tables and you use SQL queries to access the data requests sent from browser forms. What do you create the thin client from? Where do you create the SQL queries at. I will read the manuals and set it up but I have to write this up for a client.

Posted: Mon Jun 14, 2004 7:51 pm
by feyd
all the queries are generated within php, some data for them may come from the user.. The thin clients are extremely simple computers, which only need a network connection and a web browser capable of displaying whatever version of html/javascript your php pages send. The more low end machines can run an (web) application like mysql over the network gives more access to the "common" folk, giving more exposure and ease of maintenance..

It's also possible to run a local (on the end user's machine) version of mysql server inside a (binary) application.

Posted: Mon Jun 14, 2004 8:12 pm
by redmonkey
I worked for a company for 6 years that used filemaker as their database system. They used it for everything. Filemaker is not limited to simple databases, it is a fully featured relational database, and the system developed by the company I was working for involved very complex database structure.

With applications like filemaker you do not have to be a coder/programmer to get it up and running and database management is fairly straight forward, you do not have to be any sort if IT wizard to use filemaker.

It is probably a costly business to initially setup a filemaker system but I would think alot of that cost could be offset against the cost of development time and programmer time involved with developing a similar app with mySQL. mySQL is purely a database, there is no GUI, you have to write your own (PHP, ASP, Perl etc...).

If some of the calculations are done on the client side then that will reduce the load on the server which can be benifical.

I think it really depends on the overall requirements of your project. In very general terms, if this was purely for internal use then I personally would not have any problems with using something like filemaker, if it were to accessed via the web then I would probably look more to a mySQL and (PHP or Perl) solution.

Speed of development for a filemaker based solution I have always found to be quicker than that of a comparitive mySQL/PHP solution. For printing, filemaker is just like printing from any other app whereas a web-based mySQL/PHP solution will lead to headaches and the only real way to get accurate printing is to have your app produce .pdf documents.

Posted: Thu Jun 17, 2004 2:59 pm
by McGruff
I maintain a FMP db for a small company and it's biggest advantage over php/mysql is quicker development time mainly due to the simpler scripting language and the fact that you don't have to build layouts with html code. Add-on tools like mobile companion make it easy to sync desktop db's with handhelds.

It's biggest disadvantage is the simple scripting language... The other day I found myself resorting to php & regex to clean up some inconsistently entered user data (although I could have avoided that with stricter definitions for allowed data in FMP). It is reasonably powerful - good enough for a small to medium business.

Php would suffer slightly in terms of usability: in the web paradigm, if you want to edit data you fill in a form and submit it to "save" the changes. With many dbs like FMP you just enter the data and that's it. This could be a big deal if staff are used to working without saving. You can bet that data will be lost from time to time.

Finally, I find that FMP files can very easily become corrupted if the computer crashes - I think due to its auto-save feature getting in a tangle. Regular backups are very important.

Posted: Tue Jun 22, 2004 9:57 am
by Crashin
The company I work for has used FMP for years. Only over the last couple of years have they begun to implement some more advanced web functionality for their clients, via PHP and MySQL.

The biggest hurdle I've encountered with FMP is the very thing that makes it so popular: it is so easy to use. Because of that very fact, all of the databases were built haphazardly, with very little planning or thought about scalability and normalization. Now, if FMP is all that you're using, it's fine. Or, if a seasoned db admin is designing the dbs from the start, no problem. But, I ran into considerable difficulty when trying to integrate our in-house FM customer, product, and other dbs with the web.

So, in short, if you've got the time and the experience I'd say go with MySQL and develop the client to access the db. You'll have to code all of your reports, forms, etc., but you'll have the piece of mind of knowing how it was all done.

Posted: Tue Jun 22, 2004 9:57 am
by Crashin
The company I work for has used FMP for years. Only over the last couple of years have they begun to implement some more advanced web functionality for their clients, via PHP and MySQL.

The biggest hurdle I've encountered with FMP is the very thing that makes it so popular: it is so easy to use. Because of that very fact, all of the databases were built haphazardly, with very little planning or thought about scalability and normalization. Now, if FMP is all that you're using, it's fine. Or, if a seasoned db admin is designing the dbs from the start, no problem. But, I ran into considerable difficulty when trying to integrate our in-house FM customer, product, and other dbs with the web.

So, in short, if you've got the time and the experience I'd say go with MySQL and develop the client to access the db. You'll have to code all of your reports, forms, etc., but you'll have the piece of mind of knowing how it was all done.

Posted: Tue Jun 22, 2004 9:58 am
by Crashin
The company I work for has used FMP for years. Only over the last couple of years have they begun to implement some more advanced web functionality for their clients, via PHP and MySQL.

The biggest hurdle I've encountered with FMP is the very thing that makes it so popular: it is so easy to use. Because of that very fact, all of the databases were built haphazardly, with very little planning or thought about scalability and normalization. Now, if FMP is all that you're using, it's fine. Or, if a seasoned db admin is designing the dbs from the start, no problem. But, I ran into considerable difficulty when trying to integrate our in-house FM customer, product, and other dbs with the web.

So, in short, if you've got the time and the experience I'd say go with MySQL and develop the client to access the db. You'll have to code all of your reports, forms, etc., but you'll have the piece of mind of knowing how it was all done.

Posted: Tue Jun 22, 2004 10:00 am
by Crashin
Whoa! Sorry about that...

Guess I got my point across! :oops: