Objects
Strictly speaking, Force.com does not store objects in its database. Force.com’s objects are more closely related to database tables than they are to anything in object-oriented programming. Objects contain fields, which are equivalent to the columns of a database table. Data is stored in objects in the form of records, like rows in a database table.
Objects belong to one of two categories: standard and custom. Standard objects provide data for Salesforce applications like Sales Cloud or core platform functionality such as user identity. They are built in to Force.com and cannot be removed, although you can extend them by adding your own fields. Custom objects are defined by you, the developer, and you’ll be spending most of your time with them as you build your own applications. Custom objects include custom settings, a close relative of the custom object intended for small amounts of frequently accessed data, like user preferences.
Beyond the name, custom objects differ from their relational table counterparts in some significant ways.
Logical, Not Physical Objects
Unlike relational database tables, custom objects have no physical representation accessible to the Force.com developer. There are no physical storage parameters to tune, no tablespace files to create and manage. The Force.com platform decides how best to represent, index, back up, migrate, scale, and tune your database.
Delegated Operations
For the most part, operational concerns such as performance and reliability are managed entirely by the platform. This means you can design and build an application without worrying how to support it in production.
When you run your own database software and hardware, you inevitably face operational tasks such as backup, recovery, and replication for scalability. Although nothing prevents you from exporting the data from your Force.com instance and backing it up to your own servers, there is normally no reason to do so.
Note
Force.com applications that involve tens of thousands of users, tens of millions of records, or hundreds of gigabytes of total record storage belong to a category called Large Data Volume (LDV) deployments. Such deployments require special architectural considerations to maintain favorable performance. For more information, refer to the whitepaper titled “Best Practices for Deployments with Large Data Volumes” at http://wiki.developerforce.com/page/Best_Practices_for_Deployments_with_Large_Data_Volumes.
Undelete Support
Normally, when a row is deleted in a standard relational database and you need to recover it after a commit, you’re out of luck unless you have backups of the database or are using a database that provides some proprietary technology like Oracle’s Flashback. To avoid this situation, you could implement your own support for undeleting rows, like triggers to copy data to an audit table or a “deleted” column to accomplish a “soft” delete.
In contrast, Force.com provides undelete functionality on every object. When records are deleted, they go into the Recycle Bin, where they stay until they expire (15 days after deletion) and are gone for good or an administrator undeletes them. Deleted records can be queried and programmatically undeleted as well.
Accidentally dropping a table or another database object can also lead to a lot of unpleasant work for a system administrator. If your database vendor doesn’t offer specialized recovery features, you are stuck recovering data from backups. In Force.com, deleting objects sends them to the Recycle Bin. They stay there until they expire or are explicitly erased or undeleted by an administrator. If an object is undeleted, its definition and all its data are restored.