如何将现有 MySQL 架构转换为核心数据
我有一个 MySQL 数据库，希望在 Core Data 中有类似的结构。我对将 Core Data 与 Xcode 结合使用还很陌生。我有几个基本问题：我的做法是否正确。
我的 Mysql DB 看起来与此类似：
table.caveconditions
visibilityID
percolationID
xxxx
table.visibility
visibilityID
visibilityValue
...等等。然后，我将使用 JOINS 连接表。
现在，我已经完成了这样的核心数据建模，但我不太确定这是否是正确的方法。
如果你们中有人能告诉我这是否是正确的方法，那就太好了。最后我想使用 JSON 字符串将 mysql 表转储到核心数据中。
多谢 Chris
我已经创建了新架构。这是对的吗？
I have a MySQL database and would like to have a similar structure in Core Data. I am very new with using Core Data with Xcode. I have a few fundamental questions if I am doing the right thing.
My Mysql DB looks similar to this:
table.caveconditions
visibilityID
percolationID
xxxx
table.visibility
visibilityID
visibilityValue
...and so on. I would then connect the tables using JOINS
Now, I have done the Core Data modeling like this but I am not quite sure if this is the right approach.
Would be great if someone of you could tell me if this is the right way to do it. In the end I would like to use JSON strings to dump the mysql table into core data.
Thanks a lot
Chris
I have created the new schema. Is this right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了所有“xxxID”属性（例如
caveID）之外，它看起来不错。您还需要遵循命名约定。您在两个或多个实体中具有相同的属性名称和（大概）相同的值。这在 SQL 中对于连接是必需的，但在 Core Data 中，这是由对象和关系处理的。
核心数据中的每个对象自动都是唯一的。这意味着当您创建从一个对象到另一个对象的关系时，该关系具体标识特定的唯一对象。
这意味着您只需要在
caveID指定的实际实体中添加像caveID这样的属性，在本例中（大概）是Caves实体。您不需要CavesConditions实体或与“Caves”实体有关系的任何其他实体中的属性。（如果
xxxID只是 SQL 的产物，那么您实际上在 Core Data 中并不需要它们，除非您的应用程序与之交互的某些外部数据库需要它们。）一个好的经验法则是，任何特定值应该只出现在关系的一侧，并且理想情况下，在整个数据模型中只出现一次。
命名约定与 SQL 略有不同。核心数据实体不是表。实体更类似于类。每个实体都应该描述托管对象的单个实例。这些实例中有多少最终出现在对象图中是无关紧要的。因此，实体名称是单数的。
在本例中，
Caves应为Cave，Countries应为Country，依此类推。关系以其目标实体命名。这不是很明显，但可视数据模型编辑器上的每个相互关系（默认）实际上是两个关系，因为每一方都有一个关系描述。每一方都有目标实体的名称。按照惯例，一对一关系具有单数名称，而一对多关系具有复数名称。
所以：
...将成为
命名约定很重要，因为 Objective-C 使用约定名称来生成和搜索访问器方法。
It looks good except for all the "xxxID" attributes e.g.
caveID. You also need to follow the naming conventions.You have the same attribute names with (presumably) the same values in two or more entities. This is necessary in SQL for joins but in Core Data, this is handled by objects and relationships.
Each object in Core Data is automatically universally unique. This means when you create a relationship from one object to another, that relationship concrete identifies on specific unique object.
This means you only need an attribute like
caveIDin the actual entity thatcaveIDdesignates which in this case is (presumably) theCavesentity. You don't need the attribute in theCavesConditionsentity or any other entity that has a relationship to the "Caves" entity.(If the
xxxIDwere just artifacts of SQL, you don't actually need them at in Core Data unless some external database your app interacts with requires them.)A good rule of thumb to use is that any particular value should show up on only one side of a relationship and, ideally, only once in the entire data model.
Naming conventions are a little different than SQL. A Core Data entity isn't a table. An entity is more akin to a class. Each entity is supposed to describe a single instance of a managed object. How many of those instances end up in the object graph is irrelevant. Therefore, entity names are singular.
In this case,
Cavesshould beCave,Countriesshould beCountryand so on.Relationships are named after the entity they target. It is not immediate obvious but each reciprocal relationship (the default) on the visual data model editor is actually two relationships because there is one relationship description for each side. Each side has the name of the entity targeted. By convention to-one relationships have a singular name and a to-many relationship has a plural name.
So:
...would become
The naming conventions are important because Objective-C uses conventions names to generate and search for accessor methods.
CoreData 不是数据库。尽可能简单地以适合应用程序中使用方式的方式重新构建数据，并且不要考虑连接或基于结构的优化。您无法控制 CoreData 对象模型的支持架构。这是开始使用 CoreData 时必须克服的最难的概念，但一旦你做到了，你的情况就会更好。
CoreData is NOT a database. Remodel your data as simply as you can and in a way that suits how it will be used in your application and do not think about joins or structure based optimization. You do not have control over the backing schema of a CoreData object model. This is the hardest concept you must get over when starting to use CoreData, but once you do, you will be better off.