Hi guys. So I have this pretty huge and sophisticated database which is working fine but there's a need to extend it and turn it into a web-store, basically serving stuff for web front end - goods, pictures, placing orders et cetera. It's going to be managed entirely via the FM client so the work shouldn't be that hard. However I'm thinking of what the web programmers should go with. I do just the database stuff and want to relegate the web programming to someone else. With FM Server 13 the options are there so what would you suggest based on experience for us to use? Should we use FM's PHP API or should we use ODBC connector called via PHP methods? Unfortunately I can't remember why, but when researching this subject a while back I definitely wanted to settle on ODBC-PHP combo but now reading through manuals I don't see a reason why I shouldn't use just the FM's PHP for that task. Maybe it was that pesky support for field names with Unicode characters in them... can't remember. So... has anyone done anything like that?

If you did not plan your FM schema to be SQL/ODBC compliant, then the PHP/XML may be a better fit. I say PHP/XML as you may use the API or FX.php or any PHP method(s) that can process the xml output from FMP. So that is your choice: query as xml or via odbc and process with whatever web applications can use the output. Your db structure may be the deciding factor along with your ablity to make either query type. I have used both ODBC/SQL and XML with various web applications. I started desigining new databases to be 'web ready' early on. Then ODBC works well!

Thanks for the insight. I'd really appreciate if you could offer a couple of points what makes a database schema SQL/ODBC/Web compliant. Not sure I really understand it fully.

Also I am really interested in FM's PHP API specifically that seems to avoid having any type of XML between the web front and the FMS. It's hard for me to put it in words, but the way I see it that API is almost like making direct SQL query that is instantly received by the web server as, e.g. text. Is my understanding correct here? With XML as I understand it would probably be similar but with an additional layer of XML semantics. I.e. same text but wrapped in tags.

 

I'm also worried about speed. How large a load can Filemaker Server handle before it starts being unacceptably slow? I know it's hard to define and would be seriously dependent on the actual presentation of web pages but still... There's a way of downloading/uploading a local "copy" of data on the web server, sort of like an always-syncing ghost image but I don't want to go that way.

Thanks for the insight. I'd really appreciate if you could offer a couple of points what makes a database schema SQL/ODBC/Web compliant. Not sure I really understand it fully.

 

table and field names need to be SQL safe (no spaces, only a-z, A-Z, 0 to 9 and underscores,... no reserved SQL keywords as names,...)

 

Also I am really interested in FM's PHP API specifically that seems to avoid having any type of XML between the web front and the FMS. It's hard for me to put it in words, but the way I see it that API is almost like making direct SQL query that is instantly received by the web server as, e.g. text. Is my understanding correct here? With XML as I understand it would probably be similar but with an additional layer of XML semantics. I.e. same text but wrapped in tags.

 

The FM PHP api, just like FX.php and other non-PHP apis (fmDotNet, rubyFM,...) all translate the XML under-the-hood so you that you never have to see it or work with.

 

The underlying XML interface a one benefit: it allows you to run scripts on the server, in case pushing data around is not enough.

 

I'm also worried about speed. How large a load can Filemaker Server handle before it starts being unacceptably slow?

 

That is truly impossible to say because it depends on so many factors.  Including the design of your solution, the hardware you throw at it and the hardware at the client side (mobile browsers?)

 

What kind of load do you have in mind?