核心数据有什么限制吗？例如;表/实体中最多可以有多少行？数据库中可以驻留多少数据？
一般来说，是否有某个文档可以描述核心数据（针对 iOS）中存在的所有类型的限制？
更新：关于@TechZen给出的答案，我的问题暗示了I/Core Data将在后端使用sqlite这一事实。但为了澄清这一点，我打算使用 sqlite，当我谈论 Core Data 的限制时，我间接询问 sqlite（数据库存储）的限制。
那么，当我们谈论时，除了 sqlite 的 限制 之外，核心数据是否还存在任何限制？ iOS环境？
Is there any limitations exist in Core Data? e.g; how many max rows can be in a table/Entity? How much data can reside in the DB?
In general if some document can describe all kind of limitations which exist inside the Core Data (for iOS)?
Update: w.r.t answer given by @TechZen, my question was implied to the fact that I/Core Data will be using sqlite at the backend. But to just clear the point, I am intended to use sqlite and when I am talking about limitations of Core Data, I am indirectly asking limit of sqlite (database store).
So is there any limitations imposed by core data other than the limitations of the sqlite when we are talking about iOS environment?
发布评论
评论（2）
除了由情境内存、磁盘空间等施加的限制之外，核心数据本身没有任何逻辑限制。但是，如果您使用 SQLite 存储，您将获得 SQLite 本身的默认限制。 如果您正在为 iOS 编写内容，则永远不会达到这些限制。
实际上，核心数据遇到的唯一实际限制来自 读取大块，例如尝试在 SQLite 存储中存储图像或音频。通过将 blob 存储在外部文件中可以避免这种情况。
顺便说一句，我想警告你，从你提出问题的方式来看，我可以看出你对核心数据的思考是错误的。
Core Data 不是 SQL 的对象包装器。核心数据不是 SQL。实体不是表。对象不是行。列不是属性。 Core Data 是一个对象图管理系统，它可能会也可能不会持久化对象图，并且可能会也可能不会在幕后使用 SQL 来执行此操作。尝试用 SQL 术语来思考 Core Data 将会导致您完全误解 Core Data，并导致很多痛苦和浪费时间。
There are no logical limitation on Core Data itself beyond those imposed by situational memory, disk space etc. However, if you use an SQLite store, you get the default limitations of SQLite itself. If you are writing for iOS, you will never hit those limits.
Really the only practical limitation you hit with Core Data comes from memory issues caused by reading in large blobs e.g. trying to store images or audio in an SQLite store. That can be avoided by storing the blobs in external files.
As an aside, I would warn you that I can tell by the way you phrased the question, that you are thinking about Core Data wrong.
Core Data is not an object wrapper for SQL. Core Data is not SQL. Entities are not tables. Objects are not rows. Columns are not attributes. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
Core Data 是一个丰富而复杂的对象图管理框架，能够处理大量数据。 SQLite 存储可以扩展到包含数十亿行、表和列的 TB 级数据库。除非您的实体本身具有非常大的属性或大量属性，否则 10,000 个对象对于数据集来说被认为是相当小的大小。使用大型二进制对象时，请查看二进制大型数据对象 (BLOB)。
二进制大型数据对象 (BLOB)
如果您的应用程序使用二进制大型对象 (BLOB)，例如图像和声音数据，则需要注意尽量减少开销。对象被视为小还是大取决于应用程序的使用情况。一般规则是，小于 1 MB 的对象为小型或中型对象，大于 1 MB 的对象为大型对象。一些开发人员已经通过数据库中的 10 MB BLOB 获得了良好的性能。另一方面，如果应用程序的表中有数百万行，则即使 128 字节也可能是 CLOB（字符大对象），需要将其规范化为单独的表。
一般来说，如果需要将 BLOB 存储在持久性存储中，请使用 SQLite 存储。其他存储要求整个对象图驻留在内存中，并且存储写入是原子的（请参阅持久存储类型和行为），这意味着它们不能有效地处理大型数据对象。 SQLite 可以扩展以处理非常大的数据库。如果使用得当，SQLite 可为高达 100 GB 的数据库提供良好的性能，单行最多可容纳 1 GB（当然，无论存储库的效率如何，将 1GB 数据读入内存都是一项昂贵的操作）。
BLOB 通常表示实体的属性，例如，照片可能是 Employee 实体的属性。对于小型到中等的 BLOB（和 CLOB），为数据创建一个单独的实体并创建一对一关系来代替属性。例如，您可以创建员工和照片实体，它们之间具有一对一的关系，其中员工到照片的关系取代了员工的照片属性。此模式最大化了对象故障的好处（请参阅故障和唯一）。任何给定的照片只有在实际需要时才会被检索（如果关系被遍历）。
但是，如果您能够将 BLOB 作为资源存储在文件系统上并维护这些资源的链接（例如 URL 或路径），那就更好了。然后，您可以在必要时加载 BLOB。
Core Data is a rich and sophisticated object graph management framework capable of dealing with large volumes of data. The SQLite store can scale to terabyte-sized databases with billions of rows, tables, and columns. Unless your entities themselves have very large attributes or large numbers of properties, 10,000 objects is considered a fairly small size for a data set. When working with large binary objects, review Binary Large Data Objects (BLOBs).
Binary Large Data Objects (BLOBs)
If your application uses Binary Large OBjects (BLOBs) such as image and sound data, you need to take care to minimize overheads. Whether an object is considered small or large depends on an application’s usage. A general rule is that objects smaller than a megabyte are small or medium-sized and those larger than a megabyte are large. Some developers have achieved good performance with 10 MB BLOBs in a database. On the other hand, if an application has millions of rows in a table, even 128 bytes might be a CLOB (Character Large OBject) that needs to be normalized into a separate table.
In general, if you need to store BLOBs in a persistent store, use an SQLite store. The other stores require that the whole object graph reside in memory, and store writes are atomic (see Persistent Store Types and Behaviors), which means that they do not efficiently deal with large data objects. SQLite can scale to handle extremely large databases. Properly used, SQLite provides good performance for databases up to 100 GB, and a single row can hold up to 1 GB (although of course reading 1GB of data into memory is an expensive operation no matter how efficient the repository).
A BLOB often represents an attribute of an entity—for example, a photograph might be an attribute of an Employee entity. For small to modest BLOBs (and CLOBs), create a separate entity for the data and create a to-one relationship in place of the attribute. For example, you might create Employee and Photograph entities with a one-to-one relationship between them, where the relationship from Employee to Photograph replaces the Employee's photograph attribute. This pattern maximizes the benefits of object faulting (see Faulting and Uniquing). Any given photograph is only retrieved if it is actually needed (if the relationship is traversed).
It is better, however, if you are able to store BLOBs as resources on the file system and to maintain links (such as URLs or paths) to those resources. You can then load a BLOB as and when necessary.