Some Thoughts on Best Practices for Beginners

Finding Errors and Debugging

  1. Choose your editor wisely. Line numbers, syntax coloring, error checking, debugging, and unit test support are some of the items that text editors and IDEs offer to help developers. Look at the options available for your platform of choice, and try out a few of them. JetBrains makes awesome IDEs for various languages (and combinations thereof) on multiple platforms, including PhpStorm.
  2. Use all the available tools. In addition to the tools built into your IDE (as discussed above), there are server-side tools at your disposal. Be sure to make use of them! On your development environment, use a high level of PHP error reporting like E_ALL; become conversant with server logs; and use the tools built into FX.php by defining as "true" the DEBUG and DEBUG_FUZZY constants.

FileMaker Database Design for the web

  1. Make web optimized layouts. With FileMaker, every field on the specified layout is returned when you perform a query. So, for best performance, create separate layouts for your web queries; and only place the fields on it that you need for that query.
  2. Be careful what you put on a web layout. Summary fields on web layouts can make things grind to a halt. Unstored calculations can really slow things down too. And, as mentioned elsewhere, a portal on a layout with a scroll bar will return every related record for the current one. (Some FileMaker developers avoid using portals for the web, and just do an additional query instead.)
  3. Use underscores rather than spaces. Since you're typing in the names of fields, layouts, etc. an invisible character like a space can be problematic. If possible, consider using underscores when choosing names.

Performance & Query Optimization

  1. Avoid returning large found sets. Use the optional, third parameter of SetDBData() to break found sets into reasonable chunks; then either provide a paging interface, or use AJAX (asynchronous JavaScript and XML) to pull additional records as users scroll through your page.
  2. Make smart use of field/column indexing. Unless your data set is never going to grow, searching on a non-indexed field is asking for trouble. Also, become familiar with the types of indexing offered by your data source of choice — there may be options, other than the default, that work better for your needs.
  3. Be careful about how you use relationships. Sometimes, there is no substitute for relational data in a query (that's why we use relational databases, right?) On the other hand, relational data will slow your queries, so be judicious in your use of all that power.
  4. Test your queries during development. Keep in mind that people are used to quick responses from web pages, and web browsers will give up if your pages take too long to load. In some cases, caching may make sense (there's a MySQL caching class for FileMaker® databases in the EXTRAS directory of this distribution, and there are other options out there.) And when testing, check both common and uncommon text — you may be surprised at the results.
  5. Use the right database software for the job. FileMaker® databases scale to millions of records, MySQL can handle more, and PostgreSQL scales further still. For truly massive data sets, you may need to look at a NoSQL option. Keep in mind that if you need to move to a different option down-the-line, FX.php is designed to move with you.

Security

  1. Store passwords, etc. securely. Though simply putting items in the web root makes getting started with development easy, that's not where everything should be long-term — especially for servers accessible via the internet. When possible, keep sensitive data — like user names and passwords — out of the web path. A quick look at the output from PHP's phpinfo() function will tell you about the current include path, and the location of the active php.ini file (just in case you want to change it.) There's lots more great information in the php include documentation.
  2. Pick good passwords. There's lots of great information out there about what makes a good password (or pass phrase), so I won't rehash that here. Just make sure to avail yourself of that information when picking database passwords.
  3. Don't use an account with full access on the web. Should someone manage to compromise your system, the less access the better. Create database credentials for web access with just the privileges that you need there.