Custom objects and their custom fields are all created in the Custom Objects/Custom Fields table in the underlying Salesforce database. Custom object data resides within the Salesforce database, and both custom objects and custom fields have a __c suffix. In the example of a SOQL query issued for data held in a custom field called MyField in an object called MyObject, the syntax would look as follows:
SELECT MyField__c FROM MyObject__c
Queries on data held purely within these objects will be relatively quick, but any data on parent objects (especially where that object is a standard object) will incur a small performance penalty as the results will require the use of a JOIN in the underlying SQL query issued to the Salesforce database.
While the data for both standard and custom objects is held on-platform within the Salesforce database, external object data is held off-platform in an external data source, typically within another application. The idea behind external objects is that data is held off-platform, but end users interact with it as if it were on-platform. Salesforce uses web service callouts to access external data in real time. External data is available to users in real time through Salesforce, and the external object will always return the most up-to-date data from the external data source.
External objects require an external data source definition in the Salesforce instance, which is then used to determine how to access the external system.
External objects are denoted in Salesforce with a __x suffix in the object name. For example, invoice data from SAP for an order within Salesforce will have the name Invoice__x. External objects support indirect and external lookups to link the data with your Salesforce records.
External objects are supported in Salesforce API version 32 and later and are available with Salesforce Connect and Files Connect.
Big objects are used to store and manage huge amounts of data (up to 1 million records out of the box, but this can be scaled up at an additional cost to tens of millions or even billions of records). Big objects provide consistent performance. In my experience, big objects tend to lend themselves to auditing and archiving use cases, but anything that requires consistent performance when working with hundreds of millions or billions of records is what big objects are designed for.
Big objects work using a distributed database and are not transactional in nature. Therefore, sharing isn’t supported on big objects other than object and field permissions. Additionally, this means that automation from workflow, to flow, to triggers is not supported on big objects.
Idempotence
When the same record representation (that is, exactly the same set of data for a record) is inserted multiple times to a big object, only a single record is created. This is so that writes to the big object can remain idempotent. Inserting the same record representation into an sObject (whether standard or custom) will result in multiple entries.
Salesforce objects are linked together through relationships in one of several ways. These relationship can affect sharing and data access. The various relationship types are explained here.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
