多租户数据库系统中的自定义实体和字段

摘要

用于在固定物理数据库模式中容纳诸如动态表和列等可变模式数据的系统和方法。提供了诸如表的标准对象以供多个租户或组织在多租户数据库系统(201)中使用。每一组织可添加或定义自定义字段以包含在标准对象(203)中。多租户的自定义字段被存储在对象数据结构内的单个字段中，且该单个字段可对每一租户(213)包含不同的数据类型。还提供了索引列，其中租户可指定用于索引的字段。指定字段的数据值被复制到索引列中，每一索引列可包含多种数据类型(210)。每一组织也可定义包含自定义字段和索引列(201)的自定义对象。多个租户的自定义对象被存储在单个自定义对象数据结构中。单个自定义对象表的主键值是全局唯一的，但也可包括可在不同实体中重用的对象专用标识符。

说明书

发明背景

本发明一般涉及多租户数据库，尤其涉及用于在多租户数据库系统中创建诸 如自定义实体和字段等自定义对象的系统和方法。

在多租户数据库系统，诸如salesforce.com服务中，使用了多租户体系结构， 其中顾客组织(即，租户)共享一个逻辑数据库中的数据库资源。数据库表本身一 般是共享的；数据模型中的每一实体一般包含为每一租户区分行的organization_id (组织id)列。在此(被索引的)organization_id列上的租户过滤器的上下文中的 所有的查询和数据处理用于确保适当的安全性和虚拟专用数据库的外观。例如在 salesforce.com系统中，该策略被用来向顾客展示诸如Account(账户)、Contact (联系人)、Lead(潜在顾客)和Opportunity(机遇)实体等的标准实体。

然而，顾客可能希望向数据库系统添加除标准应用配备的标准实体和字段以 外的他们自己的自定义数据。在传统的客户机/服务器应用中，其中顾客具有其自 己的物理数据库，自定义数据的添加通常是经由针对该数据库的DDL(数据定义 语言)来完成的，以创建新的物理模式——表和列。在在线多租户数据库系统，诸 如salesforce.com服务中，由于各种原因该方法可能是无法维持的。例如，对具有 大量租户(例如，1,000或10,000或更多租户的数量级)的数据库系统，所有期望 的模式的联合将淹没底层数据词典式目录(例如，Oracle词典)。此外，维护所有 这些模式对象将是DBA(数据库管理员)的几乎不可能的负担。此外，当前的关 系型数据库不能足够良好地支持在线DDL(在高度并发事务系统中)以便组织能 维持逻辑独立。具体地，一个组织进行的模式创建将对引起不可接受的延迟的所有 其它顾客锁定应用。

从而，期望提供一种系统和方法，它们提供在固定物理模式中存储可变模式 数据以便克服以上和其它问题的方法。

发明简述

本发明提供用于在固定物理数据库模式中容纳诸如动态表和列等可变模式数 据的新颖的系统和方法。

根据本发明，提供诸如表等标准对象以供多个租户或组织使用。每一组织可 添加或定义自定义字段以包含在标准对象中。在一个方面，多租户的自定义字段被 存储在对象数据结构内的单个字段中，且该单个字段可对每一租户包含不同的数据 类型。还提供了索引列，其中租户可指定用于索引的字段。指定字段的数据值被复 制到索引列中，每一索引列可包含多种数据类型。每一组织也可定义包含自定义字 段和索引列的自定义对象。在一个方面，多个租户的自定义对象被存储在单个自定 义对象数据结构中。单个自定义对象表的主键值是全局唯一的，但也可包括可在不 同实体中重用的对象专用标识符。

根据本发明的一方面，提供了一种用于在单个多租户数据结构中存储多个租 户的多个字段的计算机实现的方法。该方法一般包括定义具有多个数据列和一个或 多个索引列的多租户数据结构，为第一租户定义第一数据字段，所述第一字段具有 第一数据类型；以及为第二租户定义第二数据字段，所述第二字段具有第二数据类 型，其中第二数据类型不同于所述第一数据类型。该方法一般还包括当所述第一和 第二字段中具有数据值的记录由所述第一和第二租户创建时将第一和第二字段的 数据值存储到数据结构中的单个列中，其中该单个列对不同租户包含具有不同数据 类型的数据值；以及响应于来自第一租户的在第一数据字段中索引数据的请求将单 个数据列中为第一字段存储的数据值复制到索引列的第一个中。

根据本发明的另一方面，提供了一种用于在单个多租户数据结构中容纳一个 或多个组织的多个表的计算机实现的方法。该方法一般包括定义含有主键列、组织 id列和多个物理数据列的多租户数据结构；为第一租户定义第一表，该第一表具有 第一数据字段且第一租户具有第一租户id；将第一表id分配给第一表；为第二租 户定义第二表，该第二表具有第二数据字段且第二租户具有第二租户id；以及将第 二表id分配给第二表。当由第一租户为第一表创建记录时，对所创建的每一记录， 该方法一般包括将第一数据字段的值存储到该数据结构中的单个数据列，将第一租 户id存储到组织id列，并将第一表id存储到主键列。当由第二租户为第二表创建 记录时，对所创建的每一记录，该方法一般包括将第二数据字段的值存储到数据结 构中的单个数据列，将第二租户id存储到组织id列，并将第二表id存储到主键列， 其中第一和第二租户的第一和第二表被存储到该数据结构中。

根据本发明的又一方面，提供了一种用于在单个数据结构中为一个或多个租 户存储多个表的计算机实现的方法。该方法一般包括定义具有主键列、组织id列 和多个数据列的数据结构；为第一租户定义第一表，该第一表具有第一数据字段， 该第一数据字段具有第一数据类型，且第一租户具有第一租户id；将第一表id分 配给第一表；为第一租户定义第二表，该第二表具有第二数据字段，该第二数据字 段具有不同于第一数据类型的第二数据类型；以及将第二表id分配给第二表。当 为第一表创建记录时，对所创建的每一记录，该方法一般包括将第一数据字段的值 存储到数据结构中的单个数据列，将第一租户id存储到组织id列，并将第一表id 存储到主键列。当为第二表创建记录时，对所创建的每一记录，该方法一般包括将 第二数据字段的值存储到单个数据列，将第一租户id存储到组织id列，并将第二 表id存储到主键列，其中第一租户的第一和第二表被存储到数据结构中，且其中 所述单个数据列包括具有所述第一和第二数据类型的数据值。

参考说明书的其余部分，包括附图和权利要求书，将理解本发明的其它特征 和优点。本发明的其它特征和优点以及本发明的各个实施例的结构和操作以下参考 附图详细描述。附图中，相同的参考标号指示相同或功能类似的元素。

附图简述

图1示出了根据一个实施例可在其中使用多租户数据库系统(MTS)的环境。

图2根据一个实施例更详细地示出了MTS的元素及其中的互连。

图3示出了根据本发明的一个实施例表示为标准主表和相关联的自定义字段 表的对象的示例。

图4示出了根据一个实施例表示为包含物理索引列320的自定义字段表310 的自定义对象。

图5示出了根据一个实施例表示为自定义实体表的自定义对象的示例。

图6a示出了根据本发明的实施例的自定义字段定义元数据表。

图6b示出了根据本发明的实施例用于记录为每一组织定义的每一自定义实体 对象的名字和其它信息的元数据表。

图7示出了包含标准列和自定义字段列的标准实体表的示例，以及多个虚构 组织的实际数据值的示例。

图8示出了包括含有虚构组织的数据值的自定义表的自定义实体对象的示例。

发明的详细描述

图1示出了可在其中使用多租户数据库系统的环境。如图1中所示(且在图2 中更详细示出)，任何用户系统12可经由网络14与多租户数据库系统(MTS) 16交互。这些用户系统12的用户可以是处于不同容量(capacity)中的用户，特 定用户系统12的容量可由当前用户完全确定。例如，在销售员正使用特定的用户 系统12来与MTS 16交互的情况下，该用户系统具有分配给该销售员的容量。然 而，当管理员使用该用户系统与MTS 16交互时，该用户系统具有分配给该管理员 的容量。

网络14可以是LAN(局字段网)、WAN(广字段网)、无线网络、点对点 网络、星形网络、令牌环网络、网络集线器网络或其它配置。当前使用中最常见类 型的网络是TCP/IP(传输控制协议和互联网协议)网络，诸如将在此处的众多示 例中使用的通常被称为“Internet(因特网)”(其中字母“I”大写)的网络的全 球互联网，但应理解，尽管TCP/IP是当前较佳的协议，但本发明可使用的网络不 受此限制。

用户系统12可使用TCP/IP与MTS 16通信，且在较高的网络级处，使用诸如 HTTP、FTP、AFS、WAP等其它常规的因特网协议来通信。作为示例，在使用HTTP 的情况下，用户系统12可包括常规被称为“浏览器”的HTTP客户端，它用于发 送HTTP消息和从MTS 16处的HTTP服务器接收HTTP消息。这样的HTTP服务 器可被实现为MTS 16与网络14之间的唯一网络接口，但也可使用或替代使用其 它技术。在某些实现中，MTS 16与网络14之间的接口包括负载共享功能，诸如 在多个服务器之间平衡负载和平均地分配传入的HTTP请求的循环HTTP请求分配 器。较佳地，多个服务器中的每一个至少对于访问该服务器的用户能访问MTS数 据。

在较佳的方面中，图1中所示的系统实现基于web的顾客关系管理(CRM) 系统。例如，在一个方面中，MTS 16可包括被配置成实现并执行CRM软件应用 程序以及提供相关数据、代码、表单、网页和其它信息给用户系统12并提供来自 用户系统12的这些信息，且将其存储至数据库系统相关数据、对象和网页内容中 并从中检索的应用程序服务器。使用多租户系统，租户数据较佳地被安排成使一个 租户的数据与其他租户的数据分开保存，以使一个租户不能访问他人的数据，除非 该数据被明确共享。

MTS 16的元素的一种安排在图1中示出，它包括网络接口20、租户数据的存 储22、MTS 16以及可能的多个租户可访问的系统数据的存储24、用于实现MTS 16 的各种功能的程序代码26以及用于执行MTS系统进程和租户专用进程的进程空 间28，诸如作为应用程序服务的一部分的运行中的应用程序。

图1中所示的系统中的若干元素包括不必在此详细解释的常规的、公知的元 素。例如，每一用户系统12可包括台式个人计算机、工作站、膝上型计算机、PDA、 手机或任何启用WAP的设备或能够直接或间接接口至因特网或其它网络连接的任 何其它计算设备。用户系统12一般运行HTTP客户端，例如，浏览程序，诸如微 软的Internet Explorer^TM浏览器、网景的Navigator^TM浏览器、Opera的浏览器或在 手机、PDA或其它无线设备的情况中的启用WAP的浏览器等，从而允许用户系统 12的用户(例如，CRM系统的订户)访问、处理和查看从MTS 16经由网络14 向其提供的信息和页面。每一用户系统12一般也包括一个或多个用户接口设备， 诸如键盘、鼠标、触摸屏、笔等，用于与显示器上(例如，监视器屏幕、LCD显 示器等)由浏览器提供的图形用户界面(GUI)以及由MTS 16或其它系统或服务 器提供的页面、表单和其它信息交互。如上所述，本发明适用于因特网，因特网指 的是网络的专用全球互联网。然而，应理解，可使用其它网络来代替因特网，诸如 内联网、外联网、虚拟专用网(VPN)、非基于TCP/IP的网络、任何LAN或WAN 等。

根据一个实施例，每一用户系统12及其所有组件是使用诸如浏览器等应用程 序可配置的操作器，这些应用程序包含使用诸如英特尔奔腾处理器等的中央处理单 元运行的计算机代码。类似地，MTS 16(以及存在一个以上的MTS的附加实例) 及其所有组件可以是使用应用程序可配置的操作器，这些应用程序包含使用诸如英 特尔奔腾处理器等一中央处理单元或多个处理器单元运行的计算机代码。用于操作 和配置MTS 16来与此处所述的网页和其它数据以及媒体内容互相通信并对其进 行处理的计算机代码较佳地被下载和存储在硬盘上，但整个程序代码或其部分也可 被存储在所公知的任何其它易失性或非易失性存储器介质或设备中，诸如ROM或 RAM，或在能够存储程序代码的任何介质上提供，诸如光盘(CD)介质、数字多 功能盘(DVD)介质、软盘等。另外，如公知的，整个程序代码或其部分可例如 经由因特网从软件源或从另一服务器中发送或下载，或经由使用所公知的任何通信 介质和协议(例如，TCP/IP、HTTP、HTTPS、以太网等)的公知的任何其它常规 网络连接(例如，外联网、VPN、LAN等)发送。可以理解，用于实现本发明的 各方面的计算机代码能以可在服务器或服务器系统上执行的任何程序设计语言来 实现，诸如例如以C、C++、HTML、Java、JavaScript、诸如VBScript等任何其它 脚本语言以及公知的众多其它程序设计语言来实现。

根据一个实施例，每一MTS 16被配置成向用户系统12提供网页、表单、数 据和媒体内容，以支持作为MTS 16的租户的用户系统12进行的访问。如此，除 非数据被共享，否则MTS 16提供安全机制来保持每一租户的数据分开。如果使用 一个以上MTS，它们可位于彼此靠近的位置(例如，在单幢建筑物或校园中的服 务器场(server farm)中)，或它们可分布在彼此远离的位置中(例如，位于城市 A中的一个或多个服务器以及位于城市B中的一个或多个服务器)。如此处所使 用的，每一MTS可包括本地或跨一个或多个地理位置分布的一个或多个逻辑和/ 或物理连接的服务器。此外，术语“服务器”旨在包含计算机系统，它包括处理硬 件和进程空间、以及相关联的存储系统和本领字段中公知的数据库应用程序(例如， RDBMS)。也应理解，“服务器系统”和“服务器”在此处通常可互换使用。类 似地，此处所述的数据库可被实现为单个数据库、分布式数据库、分布式数据库的 集合、具有冗余在线或离线备份或其它冗余的数据库等，且可包含分布式数据库或 存储网络及相关联的处理智能。

图2更详细地示出了MTS 16的各元素和各种互连。在此示例中，网络接口被 实现为一个或多个HTTP应用程序服务器100。也示出了包含单独的租户进程空间 104的系统进程空间102、系统数据库106、租户数据库108和租户管理进程空间 110。租户数据库108可被划分成单独的租户存储区112，这可以是物理排列或逻 辑排列。在每一租户存储区112内，可为每一用户类似地分配用户存储114。

也应理解，每一应用程序服务器100可经由不同的网络连接通信地耦合至数 据库系统，例如系统数据库106和租户数据库108。例如，一个服务器100₁可以经 由因特网14耦合，另一服务器100_N-1可经由直接网络连接耦合，而另一服务器100_N可经由又一不同的网络连接耦合。传输控制协议和互联网协议(TCP/IP)是用于在 服务器100与数据库系统之间通信的较佳的协议，然而对本领字段的技术人员显然 的是，取决于所使用的网络互连，可使用其它传输协议来优化系统。

在较佳的方面中，每一应用程序服务器100被配置成为任何用户/组织处理请 求。因为期望能够在任何时间为任何原因向服务器池添加应用程序服务器或从中移 除应用程序服务器，较佳地不存在用户和/或组织对特定应用程序服务器100的任 何服务器亲和力(server affinity)。因此，在一个实施例中，实现负载平衡功能的 接口系统(未示出)(例如，图5的Big-IP负载平衡器)在服务器100与用户系 统12之间通信地耦合，以便向服务器100分发请求。在一个方面中，负载平衡器 使用最少连接算法将用户请求路由至服务器100。也可使用负载平衡算法的其它示 例，诸如循环和观察响应时间。例如，在某些方面中，来自同一用户的三个连续的 请求可命中三个不同的服务器，且来自不同用户的三个请求可命中同一服务器。以 此方式，MTS 16是多租户的，其中MTS 16处理跨不同用户和组织的不同对象和 数据的存储。

作为存储的一个示例，一个租户可以是雇佣销售人员的公司，其中每一销售 员使用MTS 16来管理他们的销售过程。因此，用户可维护联系人数据、潜在顾客 数据、顾客跟踪数据、性能数据、目标和进展数据等，所有这些均适用于该用户的 个人销售过程(例如，在租户数据库108中)。在较佳的MTS安排中，由于所有 这些数据以及要访问、查看、修改、报告、传输、计算等的应用程序可由仅能够进 行网络访问的用户系统来维护和访问，因此用户可从众多其它用户系统中的任一个 管理他或她的销售成果和周期。例如，如果销售员正拜访顾客，且该顾客在他们的 大厅里具有因特网接入，则销售员在等待顾客到达大厅的同时可获得关于该顾客的 关键的更新。

尽管每一用户的销售数据可以不论每一用户的雇主为何而与其它用户的销售 数据分开，但某些数据可以是组织范围内数据共享的，或可由多个用户或作为租户 的给定组织的所有销售人员访问。因此，可能存在由MTS 16管理在租户级分配的 某些数据结构，而其它数据结构可在用户级管理。因为MTS可支持包含可能竞争 者的多个租户，因此MTS应具有保持数据、应用程序和应用程序使用分开的安全 协议。而且，因为多个用户可选择访问MTS而不是维护他们自己的系统，因此冗 余性、正常运行时间和备份是更关键的功能并需要在MTS中实现。

除用户专用数据和租户专用数据以外，MTS 16也可维护可由多个租户使用的 系统级数据或其它数据。这样的系统级数据可包括可在租户之间共享的行业报告、 新闻、告示等。

在某些方面中，客户机系统12与应用程序服务器100通信来请求和更新来自 MTS 16的系统级和租户级数据，这可能需要对数据库系统106和/或数据库系统 108的一个或多个查询。MTS 16(例如，MTS 16中的应用程序服务器100)自动 生成被设计成访问所需信息的一个或多个SQL语句(SQL查询)。

每一数据库一般可看作包含符合预定义目录的数据的对象的集合，诸如一组 逻辑表。“表”是数据对象的一种表示，此处用来简化根据本发明的对象和自定义 对象的概念描述。应理解，“表”和“对象”在此处可互换使用。每一表一般包含 逻辑上以可查看模式排列成列或字段的一个或多个数据目录。表的每一行或记录包 含由字段定义的每一目录的数据的实例。例如，CRM数据库可包括描述顾客的表， 该表带有诸如名字、地址、电话号码、传真号码等基本联系信息的字段。另一表可 描述购买定单，包含诸如顾客、产品、销售价格、日期等信息的字段。在某些多租 户数据库系统中，可提供标准实体表。对CRM数据库应用，这样的标准实体可包 括帐户、联系人、潜在顾客和机会数据的表，每一张表包含预定义的字段。

自定义字段

根据一个实施例，对诸如标准实体的表的一张表，在物理模式中定义了附加 的一组一列或多列，例如10、100或250列的文本数据。这些附加的列此处也被称 为自定义数据列、自定义字段列或自定义字段，它们允许系统管理员定义未包含在 该实体的预定义标准字段中的附加的字段。这些自定义字段较佳地含有VARCHAR (变长字符)数据类型。在一个方面中，这些自定义字段较佳地存储在来自主实体 表的行之外，尽管这些字段可被存储在主表中。例如，如果主表被称为 “sales.account”，则自定义字段数据可以被存储在被称为“sales.account_cfdata” 的表中，其中“cf”代表“自定义字段”。这两张表较佳地包含区分租户行的 organization_id列，以及在整个数据库中标识这些行的相同索引的主键(例如，在 此情况中为帐户id)。而且，这两张表较佳地在DB(例如，Oracle DB)上物理分 区来促进平行化，例如当需要为维护目的而对整张表操作和需要维护较浅的索引 时。

图3示出了表示为主表220和相关联的自定义字段表210的对象的示例。在 图3中所示的特定示例中，主表200(.account)表示标准帐户实体，自定义字段 表210(.account_cfdata)包含由使用主表200的各个组织(租户)定义的自定义 字段。如图所示，主表200包括组织ID(“org id”)列201和用作表200的主键 的表ID(例如，.account id的“acc id”)列202。数据表200也包括多个数据列 203。在图3的特定示例中，其中表表示标准实体，数据列203是向可使用该表的 各个组织提供的预定义数据列，即标准字段。在标准帐户实体示例中，这样的标准 字段可包括名字列、地点列、多个雇员列以及可用于存储帐户相关信息的其它列。 每一数据列203较佳地被定义为对每列存储单个数据类型。提供org id列201来区 分使用多租户帐户表200的组织。如图所示，N个不同的组织含有在表200中存储 的数据。列201中的org id较佳为Char(15)，但可包含其它数据类型。在一个方面 中，org id的前3个字符被置成预定义的前缀，诸如“00d”，尽管如有需要，org id 中的字符的另一子集可用于保存这样的前缀。

自定义字段表210类似地包括org id列211、表id列212和多个数据列213。 如上所述，表id列212用作表210的主键，且较佳地包含与表200的表id列202 相同的值。在所示的特定示例中，存在标注为val0、val1...val249的250个数据列 213。可以理解，按照期望的方式可使用任何其它编号，例如10或100。

当一开始创建组织并使其与数据库表200相关联时，对该组织自定义字段列 213为空。然而，每当在主表(例如帐户)中创建记录，即行时，在自定义字段表 中创建相应的行——所有的自定义字段列为NULL，从而直到使用之前不占用任何 空间。

在一个方面中，仅当例如由组织的管理员定义该组织的新“列”时，才允许 将数据输入这些自定义字段中。例如，在帐户实体示例中，可能期望特定组织来创 建除标准字段203以外的一个或多个附加的自定义字段，来存储在预定义标准字段 中可能未说明的特定类型的数据。本发明有利地允许组织为这样的数据创建附加的 自定义列。该定义被存储在元数据中，例如在可包含一个或多个元数据表的元数据 目录中，而非定义物理列(在Oracle中，其定义将被置于Oracle词典式目录中)。 物理列的定义同样可按照XML或某种其它格式存储。

图6a示出了根据本发明的一个实施例的自定义字段定义元数据表500 (“custom_field_definition”)的示例。custom_field_definition元数据表500被用 于为每一组织定义的每一自定义字段列和表(例如，将在以下更详细描述的标准表 和自定义表)存储名字、数据类型和其它信息。如图所示，元数据表500包括 custom_field_definition_id(自定义字段定义id)列510、organization_id(组织id) 列520、table name or id(表名字或id)列530、field name(字段名)列540、field datatype(字段数据类型)列550、is_indexed(是否索引)列560以及column_number (列号)列570。Organization_id列520存储为其创建自定义字段的组织的org id， custom_field_definition_id列是表500的主键。table name列530存储标准实体表的 名字，诸如帐户，或为组织创建的自定义实体表的id。field name列540存储自定 义字段的文本名，field datatype列550存储该自定义字段的数据类型。数据类型的 示例包括文本、数字、日期、参数选用表等。参数选用表数据类型是其中值从所枚 举的值列表中选择值的文本字段。参数选用表一般显示为UI中的下拉式菜单。 is_indexed列560存储指示字段是否被标志为用于索引的值，这将在以下更详细描 述。在一个方面中，列560存储布尔值。column_number列570存储分配给自定义 字段表210(图3)中的自定义字段的列号(例如，“val0”)。

在应用中创建新的自定义字段将分配自定义字段列213的其中之一来保存数 据。在较佳方面中，最小编号的列被首先填入。例如，如图3中所示，对每一组织 首先填入“val0”列，然后是“val1”列，以此类推。从而，取决于由组织定义的 自定义列的编号，每一自定义字段213可包含或可不包含该组织的数据。现在，当 组织中的应用程序的用户编辑该表的行时，新的自定义字段出现在屏幕上(或经由 API出现)，这将与其它标准字段一样出现。然而，当数据被持久保存在数据库中 时，该自定义字段的值被存储在单独的自定义字段表210的指定自定义字段列中， 而非在标准主表200中。

在一个方面中，对这些自定义字段允许多个虚拟数据类型，即使底层物理存 储可能是基于字符的。当组织的系统管理员定义例如数字或日期自定义字段类型 时，则值以允许容易转换回逻辑数据类型的规范格式存储为文本。如前所述，在一 个方面中，较佳地使用VARCHAR的数据类型。例如，在该方面中，数据以 YYYYMMDD格式存储，这允许经由TO_DATE(<列>，‘YYYYMMDD’)函数转 换，并且也允许不经任何转换而进行适当的排序。对数字，使用通常的十进制格式， 并且可使用Oracle函数TO_NUMBER()来转换回数字值，以便排序、数学运算和 过滤等。

因为数据库是多租户的，给定的物理自定义字段列可包含跨多个组织的数据。 例如，因为组织不限于特定数据类型，因此一个组织可定义诸如日期的一种数据类 型，而另一组织可定义诸如串或数字的不同的数据类型。从而可能在一个物理自定 义字段列中找到串、数字和日期。图3示出了包含不同数据类型的自定义字段列的 示例。如例如“val0”自定义列中所示，由组织1定义的自定义列数据类型是数据 类型1，由组织2定义的自定义列数据类型是数据类型2，而由组织N定义的自定 义列数据类型是数据类型3。数据类型1、2和3可以是相同的，或它们可以不同。 例如，数据类型1可以是文本，数据类型2可以是日期而数据类型3可以是数字。 图7及以下的相关讨论示出了其中在自定义字段列中混合不同数据类型的示例。在 一个方面中，为不同数据类型的自定义字段提供了单独的列池，即单独的池中的每 一自定义字段列包含单个数据类型。

在一个实施例中，使用元数据来确定给定自定义字段列中的数据类型。即， 元数据被用于跟踪每一自定义列中的每一组织的逻辑数据类型。在一个方面中，从 元数据中创建映射函数。例如，当组织为标准实体定义自定义字段时，在元数据表 500中存储了自定义字段定义，包括该组织的组织id、表名(例如，.account_cfdata) 和自定义表中分配的列号(例如，val0)。以这种方式，给定列号、表名和组织id， 可确定任何自定义列中的数据类型以供有效的数据检索。

自定义字段索引

现在考虑索引这些自定义字段列(例如，列213)中的数据以便允许快速检索 的问题。例如，用户期望将数据值过滤为日期，将数字值过滤为编号。然而，为了 使这些过滤器能有效工作，给定用于转换它们的值的上述表达式，需要对给定自定 义字段列表中的每一组织的数据片施加函数索引(例如，Oracle DB函数索引)。 这从Oracle DB观点来看是不可能的，因为Oracle DB不理解一个物理列包含多个 格式的数据。例如，如果试图对以上TO_DATA或TO_NUMBER表达式创建索引， 则由于在该物理列中的其它文本值不符合期望的格式而导致出错。

类似地，当对串数据搜索时，用户期望大小写不敏感的搜索。即，搜索“car” 应找到“CAR”或“CaR”。然而，大小写不敏感的定义是取决于语言的，而使用 这样的多租户数据库结构的服务(例如，CRM服务)可能启用多语言。为对多语 言的数据适当搜索，需要使用利用Oracle中的各种NLS(自然语言标准)函数建 立的函数索引。由于给定的物理列可包含多种语言的数据，有必要为所支持的每一 语言建立N个不同的索引，这将导致不可量的解。

鉴于以上列出的原因，在一个实施例中通过在单独的一组索引列中对数据排 序来实现这样的“索引的自定义字段”。根据本发明的一个实施例，提供了多个附 加的索引列以便允许索引自定义字段。当自定义字段由数据库管理员标志用于索引 时，多个索引列的其中之一被分配给该带有标志的列。来自带有标志的列的数据被 复制给所分配的索引列。数据以便于搜索，例如日期和串的格式被存储在索引列中。 例如，YYYYMMDD本身是可搜索的格式，因为按此格式的串可使用普通串比较 来进行词汇上的比较。

图4示出了根据一个实施例表示为包含物理索引列320的自定义字段表310 的自定义对象的示例。在一个方面中，每一自定义字段数据表包含多个(例如，10、 100、250等)例如使用标准Oracle B^*树索引的物理索引的列320。在具有10个索 引的列的示例中，管理员从而可指定要索引的多达10个串或日期类型的自定义字 段。当自定义字段被标志用于索引时，原始列中的数据(它们仍旧被维护以便当需 要时向用户显示未经修改的格式)被复制到这些索引的列的其中之一。例如如图4 中所示，自定义数据字段“val0”由组织1的系统管理员标志为索引的自定义列。 来自该带有标志的列的数据被复制给索引列“ival0”。类似地，自定义数据字段 “val1”由组织2的系统管理员标志为索引的自定义列，来自该带有标志的列的数 据被复制到索引列“ival0”。稍后，组织2的系统管理员可标志另一自定义字段列， 来自该列的数据被复制给另一索引列(例如，如图4中所示，列“val0”的数据复 制到列“ival1”)。在一个方面中，类似于自定义字段，较佳地首先使用或填入最 小编号的索引列。

在一个方面中，为避免跨多种语言进行搜索的问题，实现(例如，在应用程 序服务器中)将每一串自定义字段值转换成通用大小写不敏感格式的“大小写折叠” 算法。一种这样的大小写折叠算法是由Unicode Consortium(统一代码联盟)在 Unicode 4.0标准3.13章——Caseless Matching(http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf)中定义的算法，它 通过引用包含在此，这是对具有大小写概念的所有语言将字符转换成可独立于大小 写进行二元比较的形式的表式查找函数。无论何时搜索到原始自定义字段列中的 值，SQL即改为在对正搜索的文字执行相同的大小写折叠操作之后对相应的大小 写折叠的索引的列进行过滤。数据不必从其YYYYMMDD格式修改，这些数据也 作为文本包含在索引(未经修改的)中。

选择不使用索引的自定义字段的组织则在这些字段中具有null值，而NULL 在索引中不占用任何空间。以此方式，数据库中空间仅当实际索引自定义列时才被 消耗。而且，索引列320较佳地被存储在相应的自定义字段表中，然而，它们可被 存储在行以外，在此情况中，较佳地org id 311和table id 312列被复制到单独的索 引的列表中以便于搜索。

自定义字段唯一性

另一期望的模式特征是唯一性约束概念。再一次，不能对自定义字段物理列 施加唯一索引，因为尽管值可能对一个组织是唯一的，但它们可能对共享该物理列 的某些其它组织不唯一。例如，有可能两个不同组织的两条记录具有存储在同一自 定义字段中的同一提取数据值。

为实现该唯一性特征，在一个方面中，提供了仅包含要求唯一性的顾客的数 据值的单独的表。一旦组织管理员为唯一性而启用了自定义字段，该组织的所有值 被插入该唯一的索引表中，且对该自定义字段列的正在进行的改变被同步更新到该 唯一索引表(以下描述)。如果这些操作中的任一引起Oracle DB唯一索引违反， 则向最终用户传回该错误——管理员需要在声明其唯一之前“清除”字段中的数据。

唯一索引维护表的一种模式如下：

1.organization_id(组织id)

2.custom field definition id(自定义字段定义id)

3.custom field value(自定义字段值)

该模式允许索引来自同一组织(和实体)的多个自定义字段。前两列较佳地 以Oracel DB唯一索引压缩，这将使得物理索引较小，且该表可以是索引组织的， 因为其作为表的唯一目的是用作唯一索引。

自定义表

期望为扩展基本应用或与其它系统集成的目的而创建全新的逻辑实体表(实 体)。例如，使用由系统提供的标准实体的组织可期望创建一个或多个新实体来特 别迎合该组织的特定企业模型且便于为该组织的特定企业模型进行数据存储和检 索。从而，本发明的一个实施例提供创建自定义实体表或自定义实体的功能。

如同自定义字段的方法一样，根据一个实施例，所有的自定义实体数据行被 存储在单个多租户物理表中。然而，不同于标准自定义字段表，自定义实体数据表 在一个方面中对每个组织包含多个逻辑表。顾客的多个“表”实际上存储在一个大 型表中，这对顾客是透明的。

图5示出了根据一个实施例表示为自定义实体表400的自定义对象的示例。 表400包括org id列401、custom entity id(自定义实体id)列402和多个custom field (自定义字段)列403(标记为“val0”、“val1”...)。也可提供多个可任选索引 列420(标记为“ival0”、“ival1”)。org id列被用于区分各个组织填充表400。 例如，多个组织可创建自定义实体，一个方面中所有的自定义实体被存储到表400。 custom entity id列402被用于区分存储在表400中的各个自定义实体表。custom entity id列402也用作表400的主键。custom field列403用于为由各个组织定义的 各个自定义实体存储数据。特别地，自定义字段列403存储为由各个组织填充表 400定义的各个自定义实体的每一个所定义的列。索引列420类似于以上参考图4 描述的自定义字段索引的列320来实现。

根据一个实施例，全局唯一主键字段402的前3个字符被用于标识具体实体 类型。该技术有利地允许一个组织的多个自定义实体类型在该一个自定义实体表 400中区分，如将在以下描述的。然而可以理解，可使用主键的少于或多于3个的 字符来标识实体，或者可使用主键的字符的任何子组合。

当组织管理员定义新的自定义实体时，该定义被存储在元数据中而非底层数 据词典中。图6b示出了根据本发明的实施例的自定义实体定义元数据表600 (“custom_entity_definition”)的示例。当定义新的自定义实体时，数据库系统 为该实体类型的行分配(该组织内)唯一的3字符前缀。一个方面中，选择字母‘a’ 作为所有自定义实体主键的第一个字符，例如如表400的列402中所示的 a01...a02...a03...aMN...。如图所示，跨所有组织，可重复使用该相同的3字符前缀。 例如，重复使用“a01”作为多个组织的前缀。然而，自定义实体id的其余部分确 保全局唯一性(且来自不同组织的数据永不混合)。在一个方面中，这些3字符id 以基62编码，因此每一初始字符允许每个组织62*62＝3844个不同的自定义实体 类型——这是对基本上所有的使用足够大的数字。然而，应理解可使用不同的编码 基来为每个组织提供更少或更多自定义实体类型。也应理解，自定义实体id字段 可以是合成主键，例如跨两个或多个列，一个列用于前缀，其它列用于自定义实体 id的其余部分。为简单起见，在表400中未示出行分区，然而示出了组织分区450 和实体分区460。

参考图6b，使用custom_entity_definition元数据表600来记录为每一组织所定 义的每一自定义实体对象的名字和其它信息。如图所示，元数据表600包括 custom_entity_definition_id(自定义实体定义id)列610、organization_id(组织id) 列620、entity_name(实体名)列630以及key prefix(键前缀)列540。organization_id 列620存储对其创建自定义实体的组织的org id，custom_entity_definition_id列610 是表600的主键。entity_name列630存储自定义实体表的名字，例如作为文本数 据类型。keyprefix列640存储为该实体类型的行分配的3字符前缀(例如，“a01”、 “a02”等)。

当创建自定义实体表时，组织的管理员为自定义实体指定(组织内)唯一的 开发员名字——这是用于标识API调用的特定实体以及进入系统的其它开发员入 口点的名字。该名字存储在表600的实体名列630中。自定义字段也可为自定义实 体定义，如上所述，当期望时，自定义字段可标志用于索引。一旦为自定义实体定 义了自定义字段，组织即可开始像任何其它标准实体一样使用该自定义实体。例如， 所有的API操作(例如，描述、插入、更新、删除、查询、搜索)均可用，且组 织可定义用户界面，用于在在线应用程序中编辑该自定义实体。然而，该自定义实 体表对用户和组织是透明的，它以及由该组织和其它组织定义的其它自定义实体表 被存储在单个自定义实体表400中。

当对自定义实体表操作时，SQL方面的一个不同是，除对组织id以外，还需 对自定义实体id过滤来确保来自一个组织内的多个逻辑实体类型的数据不混合在 一起。例如，主键索引的前3字符部分(例如，a01...aMN)可用于这种有效的过 滤。因此，对组织id和3字符前缀的过滤提供了对该组织的特定实体类型的判断。 类似地，应向插入PL/SQL调用告知当插入新主键值和自定义实体行时将使用哪个 3字符前缀。

类似于图3的自定义字段列213，自定义字段列403可包含多个数据类型。例 如，如图所示，当组织#1定义自定义实体表1(表400中由“a01”或org 1“00d1” 标识)时，具有数据类型1的自定义字段列定义可被分配给“val0”列。类似地， 如图所示，具有数据类型2的第二自定义实体表(由org 1的“a02”标识)的自定 义字段列定义可被分配给“val0”列。数据类型1和2可以相同或不同。以此方式， 有可能可为由各个组织定义的各个自定义实体在自定义实体表400中的任何给定 自定义字段列403中存储众多数据类型。从而，如上所述，使用可任选索引字段 420，组织能够标志其自定义实体中的一个或多个列用于索引。过滤也可类似于上 述方式进行。

在一个实施例中，当创建自定义实体时，外键可定义为数据类型。以此方式， 可提供与标准实体或另一自定义实体的关系，以便于数据存储和检索(例如，减少 冗余数据存储)。例如，当定义自定义实体时，系统管理员可将自定义字段定义为 外键数据类型，以建立与一个或多个其它实体的关系。相关实体的主键被复制并存 储在该自定义字段中。在一个方面中，提供多个列来存储类型为外键的自定义字段。 这些单独的列可被索引。

具体示例

图7示出了包含标准列703和自定义字段列713的标准实体表700的示例， 以及多个组织的实际数据值的示例。如图所示，标准表700表示具有标准name(名 字)字段和其它标准字段703的帐户实体。在此示例中，ABC公司(由org id字 段701中的“00d1”标识)为“account web address(帐户网址)”定义了自定义 列，它被分配给val0列。该自定义字段的数据类型被定义为文本。此外，ABC公 司为“account stock price(帐户股票价格)”定义了第二自定义字段，它被分配给 val1列，并为“account ticker symbol(帐户定单符号)”定义了第三自定义字段， 它被分配给另一列。这些列的数据类型分别是数字和文本。类似地，123公司(由 org id字段701中的“00d2”标识)和XYZ公司(由org id字段701中的“00dN” 标识)各自分别为“account next annual meeting date(帐户下一年会日期)”和“account fiscal year(帐户财政年度)”定义了自定义字段。这些自定义字段的数据类型分 别是日期和参数选用表。这些自定义字段均被分配给val0列，尽管它们的数据类 型不同。如上所述，这些自定义字段的定义被存储到例如元数据表500的元数据中。

如图所示，表700为ABC公司保存帐户数据，包括所示的“IBM”、“Dell” 和“Apple”的具体帐户数据。类似地，表700也为123公司和XYZ公司保存帐户 数据。如图所示，123公司和XYZ公司对具有相同名字：“Disney”的帐户各族 具有特定条目。然而，这些条目基于全局唯一主键702(或712)区分。例如，对 XYZ公司，“Disney”的帐户条目具有主键值“001...932”，而123公司的“Disney” 俄帐户条目具有主键值“001...87”。如上所述，val0自定义列中的数据值具有混 合的数据类型。例如，对ABC公司，“web address”字段是文本，而123公司的 “next annual meeting date”字段具有日期数据类型，XYZ公司的“fiscal year”字 段具有参数选用表数据类型。

图8示出了包含ABC公司的自定义表810的自定义实体对象800的示例。如 图所示，ABC公司(由org id列801中的“00d1”标识)定义了表示资产的自定 义对象810。资产对象810的定义被存储到元数据，例如表600中(图6b)。资产 对象810为custom entity id(自定义实体id)分配了前缀“a02”。而且，如图所 示，ABC公司定义了另一自定义对象，例如在custom entity id列802中由前缀“a01” 标识。可在表800中提供单独的列来存储表800中所存储的各个对象的前缀(例如， “a01”)。使用自定义外键列和各个数据列定义了资产对象810。自定义外键(FK) 列被分配给“Val0”列，而“asset name(资产名)”、“asset value(资产值)”、 “asset depreciation type(资产贬值类型)”和“asset replacement date(资产重置 日期)”的数据字段被分别分配给列“Val1”到“Val4”。在此示例中，这些字段 的数据类型分别为文本、数字、参数选用表和日期。

资产对象810是帐户对象700的子自定义对象。自定义外键列将对象810中 的每一行连接至其父帐户(在这些示例中，帐户对象700为其table id分配了前缀 “001”)。例如，外键值“001...9”连接至帐户名“DELL”的表700中的行。类 似地，外键值“001...8”和“001...10”分别连接至帐户名“IBM”和“APPLE”的 表700中的行。如图所示，而且XYZ公司(由org id列801中的“00dN”标识) 也定义了自定义对象来适应其企业需求，该自定义对象也存储在表800中。照此， 任何给定的数据列803可包含取决于表800中所存储的各个自定义对象的定义的混 合的数据类型。

可重用服务

自定义实体的一个目的不仅是支持数据网格(例如，由组织和/顾客配置的行 和列)，而且也支持为标准实体展示的同一组应用程序高级语义服务。这允许系统 不仅作为在线数据提供者，而且作为具有复杂可重用服务的应用程序构建的基础架 构。

参考salesforce.com服务，这样的可重用服务以及它们如何应用于自定义实体 的若干示例如下：

历史跟踪

salesforce.com中的标准实体(诸如范例和机会实体)支持对数据至记录的改 变进行自动监察。该监察一般发生在应用程序服务器中的较低级上，其中所有的数 据正被写入数据库。该相同的代码路径较佳地与自定义实体一起使用。

用于标准实体的相同的广义模式也用于自定义实体——这是较佳的每行带有 一个字段增量的数据透视表(pivoted)模式：

1.organization_id

2.custom entity data id(自定义实体数据id)

3.custom field definition id(自定义字段定义id)

4.old value(旧值)

5.new value(新值)。

然而，它可以是非数据透视表模式。非数据透视表模式对每一条单独的信息具有多 个列。它看上去像excel电子表：

  ID  Name  Phone  Email address  111   Craig   555-1212   foo@bar.com

数据透视表模式使用普通列名，诸如：

  ID  Property Name  Property Value  111   Name   Craig

  111   111   Phone   Email Address   555-1212   foo@bar.com

数据透视表模式其中具有多得多的行，但这些行更瘦(想象，如果存在50列数 据——这将变成数据透视表模式中的50行，但数据透视表模式本身具有相同的 列)。因此正常模式是短而宽的，而数据透视表模式是高而瘦的。数据透视表模式 可用于例如监察目的，诸如用于提供范例历史相关列表——其中，向用户示出每个 字段值作为网格中的一行字段改变。然而，数据透视表模式一般难以用于如带有个 人的所有信息的细节屏幕的正常数据显示。

如果管理员在自定义实体和自定义字段的定义中“开启”该属性，则其行为 自动发生(改变被记录到这一个多租户监察表中)。该普通历史表中的数据可用于 在在线应用程序中或经由API查询显示。

作为示例，考虑对诸如范例等标准实体进行的改变。系统可当保存对范例的 编辑时记录以下历史行：

  Org Id Case Id  Field Name Old Value  New Value  Date  00d1   00d1   00d1   00d1   00d1   5001   5001   5001   5002   5002   Subject   Status   Priority   Status   Rep Name(custom)  Problem with Disc drive  Open  Low  Open  Frank   Problem with Disc Drive   In Progress   Medium   Closed   Sally   3/4/04   3/4/04   3/4/04   3/5/04   3/5/04

以上数据记录了两个编辑操作，一个是2004年3月4日对范例5001进行的，另一 个是2004年3月5日对范例5002进行的。每次编辑若干个字段。

作为另一示例，考虑对图8的资产自定义对象810进行的改变。2004年3月 4日进行的单个编辑操作的历史跟踪行的示例可能如下：

  Ora Id Cust Ent Id  Field Name  Old Value  New Value  Date  00d1   00d1   00d1   a02   a02   a02   Asset Name   Asset Value   Deprec.Type   Laptop X   50   Linear   Laptop Y   45   Accelerated   3/4/04   3/4/04   3/4/04

所有的这些信息由系统自动记录。用户界面(UI)可呈现类似于以上示出或按照 任何其它方便的格式的信息。

基于许可的安全和共享模型

管理员可希望将访问限于来自特定用户配置文件的特定实体类型——以具有 诸如EDIT_ACCOUNT等许可的标准实体相同的方式。

管理员可定义，给定的实体类型要求显式的READ(读)或EDIT(编辑)许 可。普通profileCustomEntity(配置文件自定义实体)元数据表(可供经由API编 辑使用)允许创建使配置文件(读访问)与自定义实体类型相关联的关系行，并可 任选地声明该配置文件中的用户是否可编辑该实体类型的行。

检索和编辑自定义实体数据的公共应用程序服务器和PL/SQL码然后可为当 前用户检查该元数据，并且如果用户不具有适当的许可则拒绝操作。

在一个方面中，共享模型允许对行的更细粒度的访问——除以上许可检查以 外。管理员在定义自定义实体类型时，可选择该实体类型是否可由所有用户编辑(公 有读/写)、对所有用户只读(公有读/只读)或者仅对记录的所有者或被准许对记 录的显式共享访问的用户私有可用(私有)。

为支持后面的共享模型，在一个方面中，向自定义实体数据表添加标准所有 者字段，该字段在API中可用。附加到其它标准实体中的所有者字段的同一语义 适用。例如，角色分层结构中的经理能访问下属拥有的所有记录。而且，例如 customEntityShare(自定义实体共享)等普通共享实体在一个方面中被用于进入对 用户或组的特定自定义实体行的手动显式共享访问——以accountShare(账户共享) 实体可供在API(和UI)中使用以便允许准予显式的帐户访问的相同方式。

货币类型

自定义实体中的一标准字段是控制该行中所有数字货币自定义字段的货币的 单货币类型。该功能与所有标准实体一致，且允许与应用程序中其它地方相同的货 币兑换。

每个实体类型多个商业处理

标准实体允许多个“记录类型”或商业处理的定义。例如，机会实体可具有 电话销售机会以及直接销售机会两者。取决于个别机会行的记录类型，可供参数选 用表字段使用的值按照组织管理员配置的方式改变。

自定义实体允许管理员对该同一元数据的指定。该实体中的参数选用表自定 义字段较佳地以字段标准实体相同的方式作用。

工作流程

在一个方面中，本发明提供对触发条件的定义和对特定实体类型的动作。例 如，如果机会量超过特定值(触发条件)，则诸如电子邮件等通知被发送(动作) 给预先指定的个人或组，例如该组织的销售副主管。

再一次，内部用来定义这些规则的元数据较佳地以类似于对标准实体的方式 对自定义实体操作。例如在应用程序服务器或数据库服务器中执行的代码为每一行 编辑评估这些条件，它们在较低级出现，其中标准和自定义实体均能够利用该功能。

尽管经由示例并按照特定实施例描述了本发明，但可理解本发明不限于所 公开的实施例。相反，如对本领字段的技术人员而言，显然它旨在覆盖各种修 改和类似的安排。从而，所附权利要求书的范围应与最宽泛的解释一致，以便 包含所有这样的修改和类似的安排。