In Part 1 of this post we talked about how Force.com platform manages the Data model. In this post we’ll describe about Multitenant App Development.. Read on…
The previous section explains the architecture that Force.com uses to store metadata and data. This section briefly explains how app developers can create a schema’s underlying metadata and then build apps that manage data.
Developers can declaratively build server-side application components using the Force.com Web browser-based development environment, commonly referred to as the Force.com Setup screens. This point-and-click UI supports all facets of the application schema building process, including the creation of an application’s data model (objects and their fields, relationships, etc.), security and sharing model (users, profiles, role hierarchies, etc.), user interface (screen layouts, data entry forms, reports, etc.), declarative logic (workflows), and programmatic logic (stored procedures and triggers). For example, the following screen is the Force.com Schema Builder, an intuitive, ERD-like data modeling tool.
SELECT Id, Name FROM Account WHERE Name = 'Acme'
FIND {"Joe Smith"} IN Name Fields RETURNING lead(name, phone), contact(name, phone)
… nested loops join, drive using view of rows that user can see. | ||
… use of index related to filter. | ||
… ordered hash join, drive using MT_DATA. | ||
… use of index related to filter. |
Web-based application users have come to expect an interactive search capability to scan all or a selected scope of an application’s database, return up-to-date ranked results, and do it all with sub-second response times. To provide such robust search functionality for applications, Force.com uses a search engine that is separate from its transaction engine. The relationship between the two engines is depicted in the following figure. The search engine receives data from the transactional engine, with which it creates search indexes. The transactional engine forwards search requests to the search engine, which returns results that the transaction engine uses to locate rows that satisfy the search request.
Web-based application users have come to expect an interactive search capability to scan all or a selected scope of an application’s database, return up-to-date ranked results, and do it all with sub-second response times. To provide such robust search functionality for applications, Force.com uses a search engine that is separate from its transaction engine. The relationship between the two engines is depicted in the following figure. The search engine receives data from the transactional engine, with which it creates search indexes. The transactional engine forwards search requests to the search engine, which returns results that the transaction engine uses to locate rows that satisfy the search request.
For more system data such as planned maintenance, historical information on transaction volume and speed, etc., visit trust.salesforce.com, the Force.com community’s home for real-time information about system performance and security.
We hope you enjoyed the series of these post about the Force.com platform, please stay tuned for other interesting articles on Salesforce.