System and method for evaluating claims to update a record from conflicting data sources

A system and method for evaluating claims from sources to update database records. A trust score is developed for each source. If a source submits a claim, the trust score for that source and the value of the claim are evaluated against prior conflicting claims. If the current claim is deemed the most likely, then it is adopted as provisional “truth”. If not, the current claim is rejected.

COPYRIGHT NOTICE

Portions of this disclosure contain material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the records of the United States Patent and Trademark Office, but otherwise reserves all rights.

TECHNICAL FIELD

This disclosure relates generally to systems, computer program products, and computer methods for managing database records, and more particularly, for evaluating claims to update database records, including claims from multiple conflicting sources.

BACKGROUND

In conventional database systems, users access data resources from a single logical database. Typically, data is retrieved from and stored to the database using the computing systems or devices of the user. For example, a user system might remotely access one of a plurality of servers that might in turn access the database. The user may issue a query to the database in order to retrieve data. The database processes the query and returns to the user information from the database that is relevant to the query. The maintenance of the database in order to retrieve and deliver accurate information to the user in a timely and efficient manner has been and continues to be a goal of administrators of database systems.

In a multi-tenant database system (“MTS”), various elements of hardware and software of the database may be shared by one or more customers through “cloud computing” solutions which allow service providers to offer access to hardware/software systems through a network, such as the Internet. For example, an application server may be configured to simultaneously process multiple requests for many different customers, and a database may be configured to store data that is shared by many different customers.

Of course, customers of database systems demand that the data they purchase be comprehensive and accurate. An ongoing business enterprise typically maintains significant amounts of data in a database related to the company's business, including information pertinent to sales, revenue, costs, business opportunities, inventory, networking, etc. As one example, electronic business cards or contacts are the lifeblood of many organizations, and the contact information can be maintained in the database. However, keeping contacts or any other information current in a database can be tedious, particularly when the information changes from time to time. For example, the database may have multiple business cards for the same individual, or errors in a business card for the individual.

A typical contact database allows users to enter changes directly to records, such as creating new records, updating existing records, and deleting old records. Of course, allowing direct access by users for changes can sometimes lead to mistakes in the record. In addition, changes may be made by many different sources, and this can lead to conflicting data. Further, it is difficult for the database to easily ascertain the “truth” with regard to a particular database record, such as a business card, or any of its fields or properties. In fact, the best verification that a contact is accurate is the lack of complaint or feedback that the contact was wrong in some respect after a customer purchases the contact.

It would thus be desirable to provide improved systems and methods that permit the database to be updated only when the source of the update has sufficiently trustworthiness.

DETAILED DESCRIPTION

This disclosure describes systems and methods for receiving a request from a source to update a database record, including creating or deleting the record. The request or “claim” can be accepted solely based on the trust level associated with the source of the claim, or in combination with other relevant factors. For example, updates affecting a record are only made if the trust score of the source exceeds a threshold. Further, if multiple claims are made against the same record, the claim of the source with the highest trust score will be accepted so long as the trust score of the source exceeds a threshold, or multiple sources make the same claim.

In general, the methods described herein may be implemented as software routines forming part of a database system. As used herein, the term multi-tenant database system refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, an application server may simultaneously process requests for a large number of customers, and a database table may store rows of data for a potentially much larger number of customers. As used herein, the term query refers to a set of steps used to access information in a database system.

FIG. 1is a simplified block diagram illustrating one embodiment of an on-demand database system16operating in a computing environment10. User devices or systems12access and communicate with the on-demand database system16through network14in a known manner. While the methods described herein may be implemented using any type of on-demand database system, the following discussion will describe an implementation of the method using an on-demand multi-tenant database system. More detailed examples for implementing an on-demand multi-tenant database system116are shown inFIGS. 2A and 2B, described at the end of this Detailed Description. User devices12may be any type of processor-based computing device, such as a desktop, laptop, tablet, smartphone, etc. Network14may be any type of processor-based computing network, such as the Internet, local area network (“LAN”), wide area network (“WAN”), etc.

The operation of on-demand database system16is controlled by a central processor system17, and network interface15manages inbound and outbound communications between the network14and the on-demand database system16. One or more applications19are managed and operated by the on-demand database system16through application platform18. For example, a database management application runs on application platform18and provides program instructions executed by the processor17for indexing, accessing, updating and storing information for the database. In addition, a number of methods are described herein which may be incorporated, preferably as software routines, into the database management application for receiving and handling claims that a record should be updated.

The on-demand database system16provides user systems12with managed access to many features and applications available on or through the on-demand database system16. For example, the on-demand database system16provides access to tenant data storage22, which is configured through the on-demand database system16to maintain tenant data for multiple users/tenants. Tenant data storage22may be physically incorporated within the on-demand database system16, or configured as remote storage (not shown), likewise accessible and useful to the on-demand database system16to support user systems12. The on-demand database system16is designed to facilitate storage and organized access for many different types of tenant data.

3. Database Records

A database is a collection of objects, such as a set of logical tables, containing data that is organized into defined categories. The objects are typically accessible through an application programming interface (API), which is provided through a software application, for example, a customer relationship management (CRM) software product, such as those offered by Salesforce.com, of San Francisco, Calif. A table is one representation of a data object, and is used herein to simplify the conceptual description of objects, but should not be considered limiting. The terms “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields or properties according to a defined schema. Each row of the table is a record containing an instance of data for each category defined by the fields.

In a typical example, a database such as on-demand database system16stores and provides access to records containing the information of one or more organizations. Each record, also called an entity, includes multiple fields or properties. For example,FIG. 3shows a representation for a typical schema300for a database record called contact, which includes a number of predefined fields or properties, including a first_name field310, a last_name field311, a title field312, a company field313, a company_address field314, a telephone field315, an email field316, and so forth. The fields shown and described are merely illustrative since a database record and its schema could be constructed in many ways for many different applications with different numbers of fields or properties. Individual data records r1, r2 and r3, for example, are created according to the schema300and each record represents a business card or contact for a single individual having values for the predefined fields, some of which are shown.

FIG. 4illustrates one embodiment of a table400, where entities r1, r2, r3 are actually stored as separate rows in the table organized in accord with schema300, each row being a collection of name/value pairs. For example, row r1 includes the data pairs: [first_name, “Robert”]; [last_name, “Doe”]; [title, “Vice-President, Sales”]; etc.; row r2 includes the data pairs [first_name, “George”]; [last_name, “Smith”]; [title, “Vice-President, Engineering”]; etc.; and row r3 includes the data pairs [first_name, “Jack”]; [last_name, “Daniels”]; [title, “Vice-President, Legal”].

Database access is typically secure such that users may only access objects for which they have authorization, as determined by the organization configuration, user permissions and access settings, data sharing model, and/or other factors related specifically to the system and its objects. For example, users of the database can subscribe to one or more objects on the database in order to access, create and update records related to the objects.

The nature of a multi-tenant database, and in particular, the use of a crowd-sourcing approach for populating contact data, can lead to conflicting claims about the accuracy of stored data. For example, the stored business card r1 may have originally listed a first name as “Bob” when created by a first user, but was updated by a second user who claimed that the first name was actually “Robert.” Another update offered by a third user claimed that the name was actually just “Rob” and not “Robert.” The database has no way to know which update is correct. However, as described herein, the database can implement software tools to help evaluate these claims upon receipt and to determine the most likely true value for an entity or its properties.

4. Application for Handling Change Requests

An important objective for the administrator of MTS16is to maintain accurate, up-to-date, and detailed information in the database. For example, for a database that stores contact data, a user/customer may report errors in the data via a report to the database administrator, or alternatively, may attempt to directly update a contact record. A unique feature of the system and methods described herein is one or more applications19, managed and operated by the MTS through its application platform18, that facilitate this objective by providing one or more sets of program instructions that generate tools and features to help maintain and secure the accuracy and reliability of the stored data, as well as enhance the data where possible. For example, in one embodiment described herein, instructions are provided for receiving one or more “claims” from users regarding a contact record that needs to be updated.

The block diagram shown inFIG. 5illustrates one embodiment of an application19athat performs initial handling and simple pre-processing steps, and a corresponding application19b, which handles the main analysis and processing steps for a claim to update or delete a record. Although the two applications19aand19bare shown as part of MTS16, these applications may implemented as integrated or discrete parts or modules, and may also be located elsewhere, but accessible to the MTS. Also, the construction of suitable program code and interaction between different code modules can vary greatly according to need and/or desire and software platform, and thus the illustrated embodiments are not intended to limit how various software solutions may be implemented.

In pre-processing application19a, a first program module50has program code suitable to receive a claim from a source49, such as a user12of MTS16. A second program module51stores the details of the claim in storage22. A third program module52retrieves the relevant record for processing.

In processing application19b, a first program module53obtains the trust score for the user that made the claim, either by looking up the trust score, or, if the user has no history of making changes, calculating a new trust score for this user. A second program module54evaluates the claim in light the trust score and other factors, such as internal consistency of the claim. A third program module55updates the record if the evaluation determines that the user is a trusted source, and it would be appropriate to update the record. A fourth program module56updates (or creates) the history for this user.

5. Process for Handling Record Change Requests

Referring nowFIG. 6, a process600is illustrated for receiving and handling claims to update records. In step602, a claim is initiated by a source, and in step604, the details of the claim are stored in the database. The claim details should include at least (i) the relevant data record; (ii) the claimed true value of one or more properties of the record; (iii) the source of the claim; (iv) when the claim was made; (v) other claims made against this record; and any other relevant details.

Typically, the source will be a subscribed user of the database, but claims could also originate from other sources. For example, the database may employ its own search and verification techniques which generate update claims, or may receive reports from outside services, such as bounce reports from email services, which may generate update claims. Ideally, all sources would be reliable and trusted for all update claims. Unfortunately, that is generally not the case, as the reliability of sources or contributors of data varies. However, the accuracy of a source's claims can be tracked over time to provide one indication of the reliability and trustworthiness of the source.

In step606, the claim is associated with the relevant record. In step608, the claim is also associated with the source. Typically, the claim may be stored as part of the data record or the user record, perhaps as metadata, or as a link to a separate record, or in any other known manner.

In step610, the relevant record is retrieved from storage. The present state of the record also reflects a claim as to the truth and accuracy of its contents, whether presented by the original source, or later updated, and thus the present claim includes a trust score as well. If there are other claims or relevant links, they would be discovered here, and step611is used to determine whether there are any other claims associated with this record. If so, the claim will be handled by process650, described with reference toFIG. 7below. If not, then in step612, the source is looked up to see if there is a history and trust score for the source in storage related to other claims by this source for updates. Step614determines whether a history and trust score was found in step612, and if so, then the history and trust score for this source are retrieved from storage in step616and used along with other factors to evaluate the claim against defined criteria in step620. If step614determines that that there is no history or trust score, then a trust score will be assigned or calculated for this source in step618.

The calculation of a score to measure the reliability or trustworthiness of individual sources or contributors can be accomplished in many ways, from a simple manual scoring, to a computer-implemented solution whereby simple or complex scoring algorithms can be processed for multiple data inputs to arrive at a score.

In a simple manual scoring solution, a database administrator could be used to assign scores, but such as solution may be impractical given the amount of data and number of updates that can occur. In one embodiment, an automated scoring solution is applied, but manual intervention by the database administrator may be appropriate to resolve disputes or to review scoring decisions.

Table I below represents a classic schema for manual scoring the reliability of a human intelligence source, and Table II represents a schema for manual scoring the reliability of the content or information provided by the source. For example, a score of “A1” would indicate a reliable source has provided confirmed data, while a score of “E5” would indicate an unreliable source has provided improbable data.

TABLE IRELIABILITY OF SOURCERatingCategoryDescriptionAReliableNo doubt of authenticity, trustworthiness, orcompetency; has a history of complete reliabilityBUsuallyMinor doubt about authenticity, trustworthiness,Reliableor competency; has a history of valid informationmost of the timeCFairlyDoubt of authenticity, trustworthiness, orReliablecompetency but has provided valid informationin the pastDNot UsuallySignificant doubt about authenticity, trustworthi-Reliableness, or competency but has provided valid infor-mation in the pastEUnreliableLacking in authenticity, trustworthiness, andcompetency; history of invalid informationFCannot BeNo basis exists for evaluating the reliability ofJudgedthe source

TABLE IIRELIABILITY OF INFORMATIONRatingCategoryDescription1ConfirmedConfirmed by other independent sources; logicalin itself; Consistent with other information onthe subject2ProbablyNot confirmed; logical in itself; consistent withTrueother information on the subject3PossiblyNot confirmed; reasonably logical in itself; agreesTruewith some other information on the subject4DoubtfullyNot confirmed; possible but not logical; no otherTrueinformation on the subject5ImprobableNot confirmed; not logical in itself; contradictedby other information on the subject6Cannot BeNo basis exists for evaluating the validity ofJudgedthe information

The schemas shown in Tables I and II can be readily adapted to a machine solution by those with suitable programming skills. In one embodiment of a machine solution, the scoring is not limited to a discrete set of values as shown in Tables I and II, but instead, a numerical value between 0 and 1 is assigned or calculated as trust scores for a users and claims. Thus, a value of 1 would represent 100% trust and confidence in either the source or the claim, whereas a value of 0 would represent 0% trust and confidence in either the source or the claim.

There are also existing machine solutions and web services that implement different algorithms for scoring sources or contributors. For example, CrowdFlower <https://crowdflower.com> is a crowdsourcing service that has many vetted contributors, where the contributors are scored for their expertise, and customer tasks are assigned teams of appropriate contributors. Klout (<klout.com>) is a service that develops an influence score for contributors based on the content contributed and how people react to the content. In another embodiment, statistical methods could be employed to develop a scoring schema, for example, by applying a regression analysis to relevant factors, such as accuracy of prior claims, internal consistency of claim(s), number and score of other sources that agree with claim, etc. Finally, a panel of expert “super” users could be polled to provide a manual rating of sources.

Returning toFIG. 6, in step620, the claim is evaluated, as shown in more detail inFIG. 8, described below. In step622, if the evaluation determined that the claim is appropriate and correct, then in step624, the record is updated including assigning a trust score for the accepted claim, now taken as truth for the record. In step625, the history and trust score for the prior source of the record claim is updated. For example, since the claim of the prior source has now been discarded, the trust score of the prior source will be reduced. In step626, the history for the current source is also updated to reflect that this claim resulted in the record being updated. For example, the fact that the claim was accepted can be used to improve the trust score of the current source. If the evaluation determines that the claim is not appropriate or correct in step622, then the record is not updated, but the source history is still updated in step626, and the trust score of the current source may be reduced. By this process, the trust scores of sources and claims can be continuously updated based on actual performance of the claims, i.e., whether claims were accepted or rejected.

Referring now toFIG. 7, a process650for handling multiple claims is illustrated. In step652, a set of “recent” claims is identified. What constitutes a “recent” claim can be configured, but common time frames might be within the last 24 hours, or within the last week, or within the last month. At some point, a claim is no longer considered “recent” and will not be considered relative to a new claim.

In step654, a trust score is obtained for the set of recent claims and the sources of the recent claims. In step656, the set of recent claims are re-evaluated against each other and against the current claim. Factors relevant to the criteria for evaluation include: (i) how many sources assert the current claim versus different claims; (ii) what are the user trust scores for those sources asserting the current claim and for those sources asserting different claims; (iii) does the current claim fit with other relevant data, such as historical data including trends and/or patterns in the data; (iv) how old is the claim, etc. For example, email addresses that were created for individuals in a particular company with a specific domain, e.g., jigsaw.com, may be replaced with a new domain when the company is acquired, e.g., salesforce.com. Over some period of time, this trend becomes obvious, and the trust score for contacts in the domain salesforce.com can be increased while the trust score for contacts in the domainjigsaw.com can be decreased. In addition, the fact that salesforce.com acquired jigsaw.com can be discovered and considered accordingly.

Step658determines whether the evaluation meets the defined criteria for accepting a claim. In one example, if the source has a 75% trust score and the claim has a 75% trust score, then the criteria is satisfied. In another example, the criteria includes considering timing of the claims. For example, if there are two conflicting claims, one from a well-rated source but presented one year ago, and the other from two sources with slightly lower ratings but both presented within the last week, then the criteria may be defined to accept the more recent claim. If the acceptance criteria are satisfied, then the claim is accepted in step660, the record is updated in step624, and the history of all sources is updated in step626.

If the acceptance criteria is not met in step658, then step662determines whether other sources have made the same claim. If so, then the claim may be accepted in step660. If not, then the claim is rejected in step664, and the history of all sources is updated in step626.

Referring now toFIG. 8, one embodiment of a process620for evaluating the claim is illustrated. In step670, the history and trust score of the source are evaluated in light of the defined criteria. If the score meets defined criteria for acceptance in step672, then external factors are considered in step674, such as the internal consistency of the proposed update; nicknames or abbreviations for names or other fields; external searches to confirm data; etc. One external factor that may be weighted is the value of the record. That is, if the record is in high demand, e.g., is frequently purchased by subscribers, then the threshold for acceptance of a claim might be set higher than that for a less valuable record. If the claim is consistent with the external factors in step676, then the record is updated in step678and the history for the source is updated in step680. If the claim is not consistent with the external factors in step676, then the claim is rejected in step664, and the history for the source is updated in step626.

Referring toFIG. 9, a simple example of interpreting the quality of competing claims is illustrated. At time t=1, first claim701against a record is received by the system. Since few or no other facts support the claim at this time, the trustworthiness is assigned a status of UNKNOWN. By time t=2, additional facts have been collected that support the assertion in the first claim700, and the status of the first claim is upgraded from UNKNOWN to LIKELY TRUE. The absence of any negative facts, e.g., the lack of complaints about the accuracy of the record, such as no bounce reports for purchased email accounts, can be taken as a fact to support the accuracy of the record. At time t=3, however, a second claim702is received against the record, for example, an email bounce report. Since the second claim702deviates from the first claim701, and the second claim is supported by few or no other facts at this point, it is initially treated as suspect and assigned a status of LIKELY FALSE. However, mechanisms may be initiated either to gather evidence regarding the second claim702, and/or to facilitate alerts regarding the new assertion. Thus, by time t=4, the second claim702has gathered additional support, and its status is upgraded from LIKELY FALSE to UNKNOWN. The first claim701is still considered more likely. At time t=5, the second claim702has gathered enough support to be considered the more highly trusted claim.

6. Detailed Database Embodiments

FIG. 2Ais a block diagram of an exemplary environment110for use of an on-demand database service. Environment110may include user systems112, network114and system116. Further, the system116can include processor system117, application platform118, network interface120, tenant data storage122, system data storage124, program code126and process space128. In other embodiments, environment110may not have all of the components listed and/or may have other elements instead of, or in addition to, those listed above.

User system112may be any machine or system used to access a database user system. For example, any of the user systems112could be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices. As illustrated inFIG. 2A(and in more detail inFIG. 2B), user systems112might interact via a network114with an on-demand database service, which in this embodiment is system116.

An on-demand database service, such as system116, is a database system that is made available to outside users that are not necessarily concerned with building and/or maintaining the database system, but instead, only that the database system be available for their use when needed (e.g., on the demand of the users). Some on-demand database services may store information from one or more tenants into tables of a common database image to form a multi-tenant database system (MTS). Accordingly, the terms “on-demand database service116” and “system116” will be used interchangeably in this disclosure. A database image may include one or more database objects or entities. A database management system (DBMS) or the equivalent may execute storage and retrieval of information against the database objects or entities, whether the database is relational or graph-oriented. Application platform118may be a framework that allows the applications of system116to run, such as the hardware and/or software, e.g., the operating system. In an embodiment, on-demand database service116may include an application platform118that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems112, or third party application developers accessing the on-demand database service via user systems112.

The users of user systems112may differ in their respective capacities, and the capacity of a particular user system112might be entirely determined by permission levels for the current user. For example, where a salesperson is using a particular user system112to interact with system116, that user system has the capacities allotted to that salesperson. However, while an administrator is using that user system to interact with system116, that user system has the capacities allotted to that administrator. In systems with a hierarchical role model, users at one permission level may have access to applications, data, and database information accessible by a lower permission level user, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users will have different capabilities with regard to accessing and modifying application and database information, depending on a user's security or permission level.

User systems112might communicate with system116using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system112might include an HTTP client commonly referred to as a browser for sending and receiving HTTP messages to and from an HTTP server at system116. Such an HTTP server might be implemented as the sole network interface between system116and network114, but other techniques might be used as well or instead. In some implementations, the interface between system116and network114includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the data stored in the MTS; however, other alternative configurations may be used instead.

One arrangement for elements of system116is shown inFIG. 2A, including a network interface120, application platform118, tenant data storage122for tenant data123, system data storage124for system data125accessible to system116and possibly multiple tenants, program code126for implementing various functions of system116, and a process space128for executing MTS system processes and tenant-specific processes, such as running applications as part of an application hosting service. Additional processes that may execute on system116include database indexing processes.

FIG. 2Balso illustrates environment110. However, inFIG. 2Belements of system116and various interconnections in an embodiment are further illustrated.FIG. 2Bshows that user system112may include processor system1110, memory system1111, input system112C, and output system112D.FIG. 2Bshows network114and system116.FIG. 2Balso shows that system116may include tenant data storage122, tenant data123, system data storage124, system data125, User Interface (UI)230, Application Program Interface (API)232, PL/SOQL234, save routines236, application setup mechanism238, applications servers2001-200N, system process space202, tenant process spaces204, tenant management process space210, tenant storage area212, user storage214, and application metadata216. In other embodiments, environment110may not have the same elements as those listed above and/or may have other elements instead of, or in addition to, those listed above.

User system112, network114, system116, tenant data storage122, and system data storage124were discussed above inFIG. 2A. Regarding user system112, processor system1110may be any combination of one or more processors. Memory system1111may be any combination of one or more memory devices, short term, and/or long term memory. Input system112C may be any combination of input devices, such as one or more keyboards, mice, trackballs, scanners, cameras, and/or interfaces to networks. Output system112D may be any combination of output devices, such as one or more monitors, printers, and/or interfaces to networks.

As shown byFIG. 2B, system116may include a network interface115(ofFIG. 2A) implemented as a set of HTTP application servers200, an application platform118, tenant data storage122, and system data storage124. Also shown is system process space202, including individual tenant process spaces204and a tenant management process space210. Each application server200may be configured to tenant data storage122and the tenant data123therein, and system data storage124and the system data125therein to serve requests of user systems112. The tenant data123might be divided into individual tenant storage areas212, which can be either a physical arrangement and/or a logical arrangement of data. Within each tenant storage area212, user storage214and application metadata216might be similarly allocated for each user. For example, a copy of a user's most recently used (MRU) items might be stored to user storage214. Similarly, a copy of MRU items for an entire organization that is a tenant might be stored to tenant storage area212. A UI230provides a user interface and an API232provides an application programmer interface to system116resident processes to users and/or developers at user systems112. The tenant data and the system data may be stored in various databases, such as one or more Oracle™ databases, or in distributed memory as described herein.

Application platform118includes an application setup mechanism238that supports application developers' creation and management of applications, which may be saved as metadata into tenant data storage122by save routines236for execution by subscribers as one or more tenant process spaces204managed by tenant management process210for example. Invocations to such applications may be coded using PL/SOQL234that provides a programming language style interface extension to API232. A detailed description of some PL/SOQL language embodiments is discussed in U.S. Pat. No. 8,271,341, entitled Method And System For Governing Resource Consumption in a Multi-Tenant System, which is incorporated by reference herein. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata216for the subscriber making the invocation and executing the metadata as an application in a virtual machine.

Each application server200may be coupled for communications with database systems, e.g., having access to system data125and tenant data123, via a different network connection. For example, one application server2001might be coupled via the network114(e.g., the Internet), another application server200N-1might be coupled via a direct network link, and another application server200Nmight be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between application servers200and the database system. However, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.

In certain embodiments, each application server200is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server200. In one embodiment, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is coupled for communication between the application servers200and the user systems112to distribute requests to the application servers200. In one embodiment, the load balancer uses a “least connections” algorithm to route user requests to the application servers200. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain embodiments, three consecutive requests from the same user could hit three different application servers200, and three requests from different users could hit the same application server200. In this manner, system116is multi-tenant and handles storage of, and access to, different objects, data and applications across disparate users and organizations.

In certain embodiments, user systems112(which may be client systems) communicate with application servers200to request and update system-level and tenant-level data from system116that may require sending one or more queries to tenant data storage122and/or system data storage124. System116(e.g., an application server200in system116) automatically generates one or more SQL statements (e.g., one or more SQL queries) that are designed to access the desired information. System data storage124may generate query plans to access the requested data from the database.