Let’s start with the Data model. It’s a way to model what database tables look like in a way that makes sense to humans.

If you’re not familiar with databases, think about storing data in a spreadsheet. Columns can store the address, cost, and other important attributes. Rows can store this information for each property that DreamHouse is selling. Database tables are set up in a similar way.

In Salesforce, we think about database tables as objects, we think about columns as fields, and rows as records. So instead of an account spreadsheet or table, we have an Account object with fields and a bunch of identically structured records.

Type of Objects in Salesforce:

1. Standard Objects – Objects that are included with Salesforce.
2. Custom Objects – Objects that you create to store information that’s specific to your company or industry.
3. External Objects –  Data is stored outside your Salesforce organization, but accessed by salesforce in realtime via web service callouts.
4. Big Objects – Object stores and manages massive amounts of data on the Salesforce platform, but with limitations with respect to regular objects.

Let’s talk about these in detail, which would help us to understand their deeper practical aspects.

Standard Objects

Salesforce is a SaaS that is specific to mainly  Sales Cloud, Marketing Cloud, and Service Cloud, and hence respective to these processes salesforce provides the bare minimum Objects which you need for your Sales or Services business.

Common Sales Cloud Standard Objects are Accounts, Opportunities, Contacts, and  Leads while for Service Cloud we have Cases (Support Tickets), Live Chat Objects like LiveChatTranscripts, etc.

However, Salesforce provides other standard objects which are applicable to use for every kind of operation like Users (Must have), Tasks, Events, Notes, Attachments Etc. and are not tightly bound with any other objects via relationships.

To know the complete list of Standard objects,

https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_list.htm

Custom Objects

Every Business is a type of its own and business owners have their own demands on how to run their business, the best part Salesforce knows this fact. Considering this fact, salesforce is flexible enough to not be limited to CRM sales or after-sales business management application but can be extended beyond it with its customization and to broaden the aspects of the solution with every other possibility.

Custom Objects allow Salesforce to extend functionality past the native CRM suite (Leads, Accounts, Opportunities, etc). Custom Objects are simply tables you create to store records that categorically do not belong in any of the existing tabs or objects.

For example, Human Resources is a department that does not fit well inside the standard Salesforce.com object model. Where would you store a new hire’s application, accrued vacation, 401K information, reviews, or payroll data? You could try to cram all this information on the Contact record but that would not be a great solution. All the aforementioned are good candidates for Custom Objects.

Using Custom Objects is an extended solution to any business model, but it’s good to know it’s advantages and disadvantages over Standard objects.

Advantages:

1. Data Model freedom: There are various restrictions on how you can related Standard Objects such as Contact to other objects. For instance, you cannot make Contact a Detail of a Custom Master record — Contacts can only be lookups. The same applies to Accounts.
2. Addon to Point 1, Custom objects are future safe as they provide flexibility to expand and linking capability with any other object in System. While Standard objects often have odd rules that you may not discover until after you’ve started using them and it is too late to change. CampaignMembers cannot be reparented and there is no way to change that, for example.
3. No Forced Record Sharing Security model. For Example, Salesforce User permission to view the contact record needs to have permission to Parent Account record as well, which might I don’t want in my business.
4. You avoid certain License restrictions, e.g.  High Volume Customer Portal license can only CRU, but not Delete, Contact records. With Custom Objects, you have complete freedom over what Portal or Force.com Site users can do as far as Object/Field Permissions.
5. Compartmentalizing your data into different objects makes data maintenance easier since you know all the data you are retrieving from an object actually has to do with its purpose.
6. Standard objects may have fields required which you do not need, and even worse may force you to put fields on standard layouts (Account Parent comes to mind for the second part).
7. Using an object just because it is standard leads to naming confusion. If you have a need to store information that doesn’t obviously fit the intended use of a standard object, you should strongly consider using a custom object for it to avoid confusion.
8. You remove yourself from the standard CRM Lead-to-Account/Contact/Opportunity conversion process. It can be a breath of fresh air if this is what you’re looking for, or a hassle.
9. Salesforce has the intention to organize your sales process and better CRM solution, however, if you need something different then these Custom Objects are your new friends indeed.

Disadvantages:

1. It’s time-consuming to implement Salesforce custom objects, and Exhaustive testing is vital for success with custom objects.
2. Salesforce recommends using Standard objects where ever possible for your sales process. When you work around Salesforce’s standard object features, you miss out on the area where Salesforce is always trying to innovate and improve. If you use custom objects, your Salesforce CRM cannot be optimized and you don’t receive all the benefits and features.
3. Many of the products available in the Salesforce AppExchange are not compatible with custom objects and you might need to develop those on your own supporting your custom objects.
4. Limitations on creating a number of custom objects can create issues for you in later terms, especially for Group / Professional Edition.

External Objects

External Objects act much like Standard and Custom Objects, only the data isn’t stored in Salesforce, the data is stored in an external system like SAP, Oracle, Workday or Amazon. Salesforce Connect calls out to external OData endpoints, an industry standard for building and consuming RESTful APIs, and gathers information about the data structure it exposes, and then stores metadata within an External Object.

For example, perhaps you have data that’s stored on-premises in an enterprise resource planning (ERP) system. Instead of copying the data into your org, you can use external objects to access the data in real-time via web service callouts.

Another example, you have a salesforce set up with a community site build to sell products, take the order, and initiate a payment, but you have your IMS (Inventory management system) maintained on another application/ SQL/ AWS. Instead of copying the data or integrating the data with Salesforce, access the data in real-time by making external Objects in salesforce, and connect them with your IMS using connectors.

Quick setup guide can help you understand how External object works in salesforce

https://www.youtube.com/watch?v=nxnUmk8y_zE

Big Objects

A big object stores and manages massive amounts of data on the Salesforce platform.  A big object provides consistent performance, whether you have 1 million records, 100 million, or even 1 billion. In the backend for BigObject salesforce uses Big data algorithms that help to optimize the performance of these objects in retrieving a large chunk of data on the go. 

The most practical example Big Object could be keeping

1. Large transactional data.
2. User Event Log.
3. Read-only User data dump.

Big Object Limitations:

1. Maximum 100 Big objects.
2. It cannot be used for a Report builder but can be used in Einstein Analytics.
3. Big Objects do no support data sharing rules. However, Field and Object-level security can be implemented
4. Big Objects cannot be used in triggers, flows, and processes.
5. When you insert an identical big object record with the same representation multiple times, only a single record is created so that writes can be idempotent. This behavior is different from other Salesforce objects, which creates a record for each request to create an object
6. Non-transactional database and a Horizontally scalable distributed database, unlike relational database that we use in other Salesforce objects.