iOS的核心数据限制

除了由情境内存，磁盘空间等所施加的限制外，对Core Data本身没有逻辑上的限制。但是，如果使用SQLite存储，则会获得SQLite本身的默认限制。如果您正在为iOS写作，那么您将永远不会达到那些极限。 确实，您使用Core Data遇到的唯一实际限制来自读取大blob等引起的内存问题。尝试将图像或音频存储在SQLite存储中。可以通过将blob存储在外部文件中来避免这种情况。 顺便说一句，我警告您，我可以用您表达问题的方式告诉您，您在考虑核心数据是错误的。 核心数据不是SQL的对象包装。核心数据不是SQL。实体不是表格。对象不是行。列不是属性。核心数据是一个对象图管理系统，该系统可能会或可能不会持久化对象图，并且可能会或可能不会在后台使用SQL。试图用SQL术语来考虑核心数据会导致您完全误解核心数据，并导致很多痛苦和浪费时间。

核心数据是一个丰富而复杂的对象图管理框架，能够处理大量数据。 SQLite存储可以扩展到具有数十亿行，表和列的TB级数据库。除非您的实体本身具有很大的属性或大量的属性，否则10,000个对象被认为对于数据集来说是相当小的大小。使用大型二进制对象时，请查看二进制大型数据对象（BLOB）。 二进制大数据对象（BLOB） 如果您的应用程序使用诸如图像和声音数据之类的二进制大对象（BLOB），则需要注意使开销最小化。对象是小还是大取决于应用程序的使用情况。一般规则是，小于兆字节的对象是小型或中型，大于兆字节的对象是大型。一些开发人员使用数据库中的10 MB BLOB取得了良好的性能。另一方面，如果应用程序在一个表中有数百万行，那么即使128个字节也可能是一个CLOB（字符大对象），需要将其标准化为单独的表。 通常，如果需要将BLOB存储在持久存储中，请使用SQLite存储。其他存储要求整个对象图都驻留在内存中，并且存储写操作是原子的（请参阅持久性存储类型和行为），这意味着它们不能有效地处理大型数据对象。 SQLite可以扩展以处理超大型数据库。如果正确使用，SQLite可为高达100 GB的数据库提供良好的性能，并且单行最多可容纳1 GB（尽管无论存储库的效率如何，将1GB的数据读取到内存中都是一项昂贵的操作）。 BLOB通常表示实体的属性，例如，照片可能是Employee实体的属性。对于小到中等的BLOB（和CLOB），请为数据创建一个单独的实体，并创建一对一关系来代替属性。例如，您可能创建了Employee和Photograph实体，它们之间具有一对一的关系，其中从Employee到Photograph的关系替换了Employee's photograph属性。这种模式最大程度地发挥了对象故障的好处（请参见故障和唯一化）。任何给定的照片仅在实际需要时才检索（如果遍历关系）。 但是，如果能够将BLOB作为资源存储在文件系统上，并能够维护到这些资源的链接（例如URL或路径），则更好。然后，您可以根据需要加载BLOB。