iPad App拉取和推送关系数据

发布于 2024-10-02 15:50:28 字数 380 浏览 3 评论 0原文

我目前正在为 iPad 开发一个商业应用程序。它将与 Microsoft SQL 服务器数据库对话。

我的问题是,通过线路提取关系数据的最有效方法是什么。一个例子是我在应用程序中显示联系人列表。联系人记录有一个departmentID字段(与部门表相关)和一个ContactTypeID字段(与ContactType表相关)。我希望当用户第一次启动应用程序时,我会将部门和联系人类型表数据拉到 ipad 上。当我提取联系人列表数据时,我将只提取字段的 ID,并将其相关数据从启动时提取的数据中提取出来。然后,用户必须能够单击列表中的记录并打开所选联系人的详细信息页面。这是一个简单的例子,但希望它能表达我的观点。

有人对这个问题的最佳方法有什么建议吗?我需要从服务器中提取数据和推送数据。

提前致谢

Im currently putting together a business app for an ipad. It will be talking to a Microsoft SQL server database.

My question is what is the most efficient way to pull relational data over the line. One example is im showing a contact listing in the app. The contact record has a departmentID field (which is related to the department table) and a ContactTypeID field (which is related to the ContactType table). I am hoping that when the user first starts the app I will pull the department and contacttype table data over onto the ipad. Than when i pull the contact listing data I will just pull the ID's for the fields over and pull their related data out of the data i pulled at startup. The user must than be able to click on a record in the listing and bring up the details page for the selected contact. This is a simple example but hopefully it makes my point.

Has anyone got any advice on the best approach for this? I will be needing to both pull data and push data to and from the server.

Thanks in advance

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

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

发布评论

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

评论(1

饮惑 2024-10-09 15:50:28

一种流行的方法是将服务器端对象转换为 JSON,然后将 JSON 字符串发送到设备。在设备上,使用一些 JSON 框架将 JSON 解码为 NSDictionary/NSArray 值(我建议使用 JSONKit 因为它非常简单并且非常快)。

一旦你有了解码后的 JSON,你就可以使用(无耻的插件警告) 此技术将您的 NS* 对象转换为 CoreData 对象,并将它们保存到您的手机上。

至于维护关系,您可以使用嵌套表示或平面表示。嵌套实现的示例如下:

{
    class: "Contact",
    first_name: "John",
    last_name: "Doe",
    contact_type: {
        class: "ContactType",
        type: "some value"
    },
    department: {
        class: "Department",
        name: "Department of Transportation"
    }
}

如果您有一个简单的数据库,没有关系循环,那么这是首选方法。

或者,您可以使用平面表示:

{
    class: "Contact",
    id: 1,
    first_name: "John",
    last_name: "Doe",
    contact_type_id: 15,
    department_id: 34
}

{
    class: "ContactType",
    id: 15,
    type: "some value"
}

{
    class: "Department",
    id: 34,
    name: "Department of Transportation"
}

然后您必须在设备上使用 contact_type_id 和 Department_id 手动解析关系。

最好测试这两种方法,看看哪一种更适合您的特定情况。就我个人而言,我建议使用嵌套方法(如果您的数据库布局允许),因为它速度更快,并且关系解析是在服务器上完成的(您可能负担得起),而不是在设备上完成(您可能负担得起)如果您有一个大型数据库,则负担不起)。

A popular approach is to convert your server-side objects to JSON, and then send the JSON string to the device. On the device, decode JSON into NSDictionary/NSArray values using some JSON framework (I suggest JSONKit since it's very simple and very fast).

Once you have your decoded JSON, you can use (shameless plug warning) this technique to turn your NS* objects into CoreData objects, and save them onto your phone.

As for maintaining relationships, you can either use a nested representation or a flat representation. An example nested implementation would be:

{
    class: "Contact",
    first_name: "John",
    last_name: "Doe",
    contact_type: {
        class: "ContactType",
        type: "some value"
    },
    department: {
        class: "Department",
        name: "Department of Transportation"
    }
}

This is a preferred approach if you have a simple database, with no relationship cycles.

Alternatively, you can use a flat representation:

{
    class: "Contact",
    id: 1,
    first_name: "John",
    last_name: "Doe",
    contact_type_id: 15,
    department_id: 34
}

{
    class: "ContactType",
    id: 15,
    type: "some value"
}

{
    class: "Department",
    id: 34,
    name: "Department of Transportation"
}

Then you would have to resolve the relationships manually using contact_type_id and department_id, on the device.

It's best to test both of these approaches and see which one works better in your particular case. Personally, I'd recommend the nested approach (if your DB layout allows it), since it's much faster and relationship resolution is done on the server (where you can probably afford it), instead of on the device (where you probably can't afford it if you have a large database).

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