Apex Code Development You need to sign in to do that
Don't have an account?
Book_Guy Using Salesforce As a Relational Database
Is it prudent to create an object in Salesforce the same way you would create a table for a relational database. See example below. The reason for doing this is so these tables can be controlled by Salesforce users rather than in an inaccessable SQL table, but once the table is setup, no users will have to modify them.
| Grade (table/object) | ||
| GradeID | GradeDesc | |
| A | Great | |
| B | Good | |
| C | Fair | |
| D | Below Average | |
| E | Poor | |
| ContestGrade (table/object) | ||
| ContestID | GradeID | PointValue |
| C101 | A | 20 |
| C101 | B | 10 |
| C101 | C | 5 |
| C101 | D | 3 |
| C101 | E | 0 |
| C102 | A | 100 |
| C102 | B | 80 |
| C102 | C | 50 |
| C102 | D | 20 |
| C102 | E | 10 |
| C103 | A | 5 |
| C103 | B | 4 |
| C103 | C | 3 |
| C103 | D | 2 |
| C103 | E | 1 |
I am concerned with creating clutter in Salesforce, when tables like this can be managed in our SQL database. The positive
is the data will be available so we can change it directly.
One significant ramification is that this table will count against your maximum number of custom objects. Depending on your SFDC edition, this may be a big deal, or less so.
From a database perspective, it's certainly the "right" thing to do if you need this data in your SFDC app. If you're worried about clutter you can control this using the tab mechanism, so that users who don't need to modify these lookup tables won't have them constantly in their faces.