为什么核心数据预填充如此困难?

发布于 2024-09-12 20:21:32 字数 482 浏览 1 评论 0原文

这更像是一个关于苹果设计决策的哲学问题,而不是一个关于核心数据的问题。

为什么拥有一个如此难以预先填充的模型系统是有用的?有什么优点?我知道你可以让你的程序生成 sqlite 文件并手动编辑它,但据我所知,如果你有任何关系,你就不能这样做。

我将其与 Rails 中使用的 MVC 范例进行比较,这似乎更有意义。 Rails 中的模型提供了与 Core Data 类似的抽象级别(据我所知),但它们还允许您手动(或通过脚本)将您想要的任何内容输入到数据库中。

我对 Core Data 的问题是:由于(对我来说)rails 似乎证明您可以从数据库中获得出色的模型抽象,同时保留几种方便的方法来预填充它,那么删除该功能会带来哪些可能的优势?核心数据是否更高效?预填充所涉及的困难是否仅仅是其他设计选择的副作用?如果是这样,为什么没有考虑预填充?

(免责声明,我真的对这些选择背后的推理感兴趣,尽管我的帖子可能会暗示这一点,但我并不是真的在寻找“Rails 中的模型与核心数据”的辩论。)

This is a more a philosophical question about Apple's design decisions than a question about Core Data.

Why in the world is it useful to have a model system that is so difficult to prepopulate? What are the advantages? I know you can have your program generate the sqlite file and edit it manually, but as far as I can tell, you can't do that if you have any relationships at all.

I compare this to the MVC paradigm used in rails, which seems to make way more sense. Models in rails provide a similar level of abstraction to Core Data (from what I can tell) but they also allow you to enter whatever you want into your database manually (or through a script).

The problem I have with Core Data is that: since rails seems to prove (to me) that you can have an excellent model abstraction from the database while retaining several convenient methods to prepopulate it, what possible advantages does removing that ability offer? Is Core Data somehow more efficient? Is the difficulty involved in prepopulation merely a side-effect of other design choices, and if so, why wasn't prepopulation taken into consideration?

(A disclaimer that I'm genuinely interested in the reasoning behind these choices, and though my post might suggest it, I'm not really looking for a "Models in Rails vs. Core Data" debate.)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

趁年轻赶紧闹 2024-09-19 20:21:32

因为核心数据不是数据库。它是一个恰好持久化到磁盘的对象图,其中一种持久化格式是数据库。这意味着你需要以反向视角来看待它。

Core Data 的设计目的是尽可能快地从持久存储中检索对象并将其保存回来。这样做的一个副作用是,持久格式专注于使该目标更快,而与其他任何东西兼容充其量是次要的。因此,SQLite 文件的内部结构是为了性能,而不是兼容性。

我对预填充的看法是,核心数据被设计为一个闭环系统。您可以使用 Core Data 轻松填充数据文件。填充 Core Data SQLite 文件并不比编写脚本将 Oracle 数据转换为 CSV 格式更难。

如果您留在 Cocoa 和 Core Data 中,那么这根本不困难。您编写命令行应用程序或编辑应用程序并导入数据。从 Cocoa 程序员的视角来看,这是一个微不足道的任务,只需要几分钟。

Because Core Data is NOT a database. It is an object graph that happens to persist to disk and one of those persistence formats is a database. This means you need to look at it in a reverse PoV.

Core Data is designed to be as fast as possible in retrieving objects from that persistent store and saving them back out. One side effect of this is that the persistent format is focused on making that goal faster and being compatible with anything else is secondary at best. Thus the internal structure of the SQLite file is aimed at performance, not at compatibility.

My opinion about pre-population is that Core Data is designed as a closed loop system. You can use Core Data to populate the data file easily. It is no harder to populate a Core Data SQLite file than it is to write a script to translate your Oracle data to CSV format.

If you stay within Cocoa and Core Data then it is not difficult at all. You write a command line app or editing app and import the data. From the PoV of a Cocoa programmer, that is a trivial task that takes just a few minutes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文