General Tips For Oracle PL/SQL Developers Switching To Salesforce

Here are some notes from the trenches on what it's like to try to do switch from Oracle PL/SQL to Apex for your anonymous database modification code & stored procedure & trigger development:

1. Trigger-writing in Salesforce essentially means "surrounding a crippled version of SQL in a crippled version of Java."
   It's definitely doable, but a pretty big paradigm shift from Oracle PL/SQL trigger programming and a bit of a shock to the system at first.
    
2. You can't build as complicated of "SOQL" queries in Salesforce as you can build "SQL" queries in Oracle.
   • The "Salesforcey" way around this is typically to cache the results of simpler "SOQL" queries in Java-like "List" & "Map" & "Set" data structures and then use Java-like code to loop through the cached data and finish off the aggregations + filters + joins.
      
3. Some "SOQL" queries can be made more elegant by putting half of their complexity into the definition of a "formula field" on a given object - but the downside is that you now have your code split between the trigger code and the definitions of the tables themselves. Nevertheless, for example, rather than hard-code this logic into the trigger, you could add a "is SAT verbal score greater than 600 and SAT math score greater than 500?" Boolean formula field to the "Test Score" table in Salesforce and just have the trigger check it for "==TRUE."
    
4. Although you'll be writing in Java-like code, except when you're creating "reference" objects (like here), you won't be doing a lot of "object-oriented" programming.
   Mostly, you'll be defining functions and writing step-by-step procedural code that calls them.
   In code, this will play out as most of your "classes" and "methods" having the modifier "static."
   So don't worry too much about not being experienced at object-oriented programming.
    
5. Just as you can write "stored procedures" but not attach them to a database trigger in PL/SQL, in Salesforce you can save snippets of code that you're not sure how often you'll actually need to use (but may suddenly need to invoke on demand) in Java-like "classes."
    
6. Just as you can execute "anonymous procedures" in PL/SQL, in Salesforce you can anonymously execute lines of Java-around-SQL-like code. This is often useful for one-off data fixes that are too complicated for "export, fix, & re-import" fixes with Data Loader or "MassImpact" fixes with DemandTools.
    
7. "Export, fix, & re-import" fixes are often made much faster by doing the "fix" step with Python rather than Excel.
   • Anyone responsible for such work will find it handy to have a Python environment + the "NumPy" & "Pandas" & "CSV" plugins installed on their computer and an IDE for Python code execution (the "Spyder IDE" / "WinPython" environment works well for me).
      
8. Get a copy of Dan Appleman's "Advanced Apex Programming" to get more "how to make your code efficient" tips and to learn subtle "variable scope" differences in Salesforce's Java variation. Also handy is a StackOverflow account, because we have our own sub-board at salesforce.stackexchange.com.