It is a good practice to define globals in a globals table whether you share the database or not. It makes it easier to keep track of them and reduces the "clutter" in your other tables. Since the value in a global field can be accessed from any script, layout or calculation in your file, you can do this for all global fields except those used as match fields in relationships.
In a database hosted over a network, one Knowledge Base article indicates that there can be some performance improvements by putting globals in their own table, but I haven't seen a noticeable improvement in my own systems: http://help.filemaker.com/app/answers/detail/a_id/5895
is it generally good practice to store global variables that will be used to find / filter views in a separate table?
Specifically, it will depend on how you use that field to find/filter views. If used by the user to enter criteria for a find, put the field in the globals table. But you can use that global as a match field in a relationship as a way to find and filter records and then you can't put the global in a Globals table.
is it best to create one record with a field for each global or to create new records for each global with one field holding the global name and the other holding the value?
Well the fields are Global--the field holds the same single value no matter what record is current. Doesn't even matter what table is specified for that layout. So you generally do not need any records in your globals table. What you may be thinking of is the issue that occurs with hosted databases: If a user modifies the value of a global field, the change to that global field is not retained when they close the file. Nor is any change that a client makes to a global field visible to any other user--each have their own "virtual copy" of the database.
What some developers do is set up yet another table with non-global fields and/or records that correspond to the global fields. A script then copies data from this table into the global fields each time the file is opened. That way, a user can make a lasting change to a global field by editing the data in this table of non-global fields.
For more on using global fields in a hosted database: http://help.filemaker.com/app/answers/detail/a_id/3604/kw/global
Thanks very much. Perfect.
I really don't know how you find the time in the day to answer so many question so thoroughly and expertly.