Core Data 比 SQLite 更适合服务器客户端数据库设计吗？
我正在设计一个服务器客户端数据库，我不确定 Core Data 是否合适？
我有一个服务器数据库，它将维护数据的主副本及其关系。
每个客户端应用程序都有一个空的客户端数据库，只有关系。
客户端启动时，它将向服务器请求数据并尝试用数据填充它。
由于客户端数据库中的关系会导致插入失败，因此客户端会编译自己仍然缺少的信息列表，并发出必要的请求，直到成功插入所有信息。
所以总而言之，客户端将仅拥有来自服务器的数据的子集。
在我的设计中，主键和关系必须由服务器数据库管理。
但似乎 Core Data 有目的地抽象了主键和关系的管理。
我可以使用 Core Data 模拟我自己的主键和关系机制。同时获得 Core Data 提供的好处。
或者实现 SQLite 并处理我自己的数据。
I'm having a server client database design which I'm unsure is Core Data suitable?
I have a server database which will maintain the master copy of the data and their relationship.
Each client application will have an empty client database with only relationship.
Upon the start up of the client, it will request for data from the server and try to populate it with data.
As the relationship in the client database will cause the insertion to fail, the client will compile a list of information that it is still lacking and make the necessary request until it succeed in inserting all information.
So in conclusion, client will have only a subset of data from the server.
In my design, the primary keys and relationships have to be managed by the server database.
But it seems that Core Data purposefully abstract the management of primary keys and relationships.
I can either emulate my own primary keys and relationships mechanism using Core Data. While reaping the benefit of what Core Data provides.
Or implements SQLite and handle my own data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用核心数据。如果您使用 SQL，无论如何您最终都会手动复制大量 Core Data 功能。
实现这项工作的关键是充分理解数据，以便将其转化为对象。在设计核心数据实体图时，不要错误地考虑表、列和行。您没有尝试对 SQL 数据库进行建模。
相反，您尝试创建一个图表来模拟数据本身所代表的现实世界对象、条件或事件中的关系。如何在磁盘上管理数据与设计无关。毕竟，如果您的数据来自多个来源怎么办？
一旦你有了一个好的模型，那么你需要做的就是从服务器提取数据，然后将正确的数据放入正确实体及其属性的实例中。如果您有正确设计的模型，那么这项任务总是相对微不足道的。
Go with Core Data. If you use SQL, you will end up duplicating a lot of Core Data functionality by hand anyway.
The key to making this work is understanding the data well enough that you can turn it into objects. Don't make the mistake of thinking in terms of tables, columns and rows when designing the Core Data entity graph. Your not trying to model the SQL database.
Instead, your trying to create a graph that mimics the relationships in the real world objects, conditions or events that the data itself represents. How the data is managed on disk is irrelevant to the design. After all, what if your data comes from multiple sources?
Once you have a good model, then all you need to do is extract the data from the server and then put the right data in an instance of the right entity and its properties. That task is always relatively trivial if you have a properly designed model.