When you add fields to SugarCRM modules via Studio, the fields are created in a different table from the stock one.
This helps keep customizations separate.
For example, Accounts are stored in the accounts table. If you take a stock instance, and add, for example, an active flag on the Accounts module you will find that sugar creates a table called accounts_cstm and a field accounts_cstm.active_flag_c
the _c is added to all custom field names and is helpful in identifying custom fields when you are working with SugarBeans (see more about that below).
The accounts_cstm table will also have an id_c foreign key to link it to the original accounts table:
accounts.id = accounts_cstm.id_c
Any other fields you might add after that to the Accounts module will also be added to the accounts_cstm table.
Now, if you create your own module, and later add more fields, it too will have an _cstm table and fields named _c.
Again, it distinguishes the original deployment from later additions.
There are ways to get around this in code but you need to be familiar with the way sugar handles vardefs and create your new fields in code instead of using Studio - which may or may not be worth the trouble depending on your situation. I would certainly recommend not trying to get around the _cstm table for stock modules, it is good to keep things separate.
From a programming standpoint, the Accounts bean will contain both your stock and custom fields so you will not need to worry about the table distinction as the beans joins those tables for you.
