QuickBase Best Practices, Part I
Sunday, January 24th, 2010So as a public service, we’d like to give you a few guidelines for putting together your QuickBase. If you can put these into practice, then when the time comes to work with a consultant, we promise you’ll hear some nice comments on the other end of the phone - “Nice job, you really know what you’re doing!”
I know you’re busy so we will keep this brief — a few here and then a few more next issue.
Most of a database’s power, and most of its complexity, is in the relationships between tables. If your application has one table in it, that is a clear sign that you are missing out on the jelly in the QuickBase doughnut. Relationships are important!
You need to learn how QuickBase deals with relationships, but even before that, you need to see why relationships are important. A good starting point is the article here. This is specifically about MS Access, but the article is still good for QuickBase users and it is way easier to understand than the Wikipedia article!
In most cases, it’s best to keep your company’s work in a single QuickBase application. That’s because tables often relate to each other. For example, if you have one application for Order Entry and another for Customer Satisfaction, they are both going to use your Customer List, your Employee List, and probably other tables too. You don’t want to have two Customer lists so that means that one application will need to hold the Customer list, and the other will have to use a cross-application relationship to see it. Cross-application relationships are OK, but they have some limits. Better to keep it all in one application.
Of course, there are exceptions to this. If your applications are owned by different people, or they just get big and un-manageable, it’s best to separate them. But don’t do it unless you have a good reason.
3. Know what you’re doing with Proxy Fields
Almost every time you set up a relationship in QuickBase, a “proxy field” is created. That’s so when you pick a parent record, you see a dropdown that is meaningful to you.
For example, if you have a relationship between Projects and Customers (one Customer to many Projects), the real relationship is between the Project and the Customer’s Number. But a Customer Number (1,2,3) is probably meaningless to you. What you really want to see is the Customer Name. So in a case like this, you want the Customer Name to be a proxy field in the relationship.
The Infamous Proxy Field - Should it be banned?
At Data Collaborative, our general practice is not to use Proxy Fields. But we are QuickBase geeks - we eat and breathe this stuff. Our advice to you is this: pick one strategy and stick with it. If you use Proxy Fields, be careful about mixing a Proxy Field and a Lookup Field on the same form. If you don’t use Proxy Fields, learn how to use Record Picker fields to make the lookup dropdown have meaningful values.
