两个内容提供商访问同一个数据库
大家好！
我想知道如果一个人希望两个完全不同的 Android 应用程序访问和操作同一个数据库，是否有一个普遍首选的实现范例值得尊重？是否建议甚至技术上可以这样做？这样的架构会是什么样子？
截至目前，我正在考虑让两个应用程序实现自己的 ContentProvider （两个 ContentProvider 将访问同一个数据库，但保证不会同时访问）。我还考虑过构建一个通用的内容提供程序，并让两个应用程序在访问数据库时都使用该内容提供程序。我更喜欢第一个例子，但还没有完全放弃后面的例子。
基本原理：
我有两个需要访问公共数据库的应用程序。数据库本身存储数据的同时也描述了数据行之间的关系，通常描述一组“表单”，其中表单内容； UI 元素（如文本框、按钮和不同类型的列表）是可定制的。两个应用程序都使用数据库中的“描述数据”在运行时生成相应应用程序 UI 的一部分。
因此，这两个应用程序有两个方面：一是“管理”方面（管理数据结构和数据行之间的关系），二是“通用用户”方面（读取/修改实际数据值）。将这两个方面分离到不同的应用程序中是经过深思熟虑的选择。
注意！数据值与数据结构分开，即值存储在一个单独的表中，而结构在另一个表中描述。这意味着这两个应用程序本质上将修改同一数据库中的两个不同表，并且可以这么说，它们永远不会修改“另一个表”。
任何想法都将不胜感激。该应用程序尚处于规划阶段，因此，现在是做出根本性改变的时候了。
Hi all!
I wonder if there is a generally preferred implementation paradigm to respect if one want's two completely different Android applications to access and operate on the same database? Is it recommended or even technically possible to do this at all? What would such an architecture look like?
As of now I'm considering to let the two applications implement their own ContentProviders (both ContentProviders will access the same database, guaranteed never simultaneously, though). I have also thought of building one common content provider and let both applications use that one when accessing the database. I prefer the first example but haven't completely discarded the later.
RATIONALE:
I have two applications which need to access a common database. The database itself stores data but also describes the relationship between the data rows, typically describing a set of "forms" where the form content; UI elements like text boxes, buttons and different kinds of lists, is customizable. Both applications use this "description data" in the database to generate parts of the respective application UI during runtime.
Hence, there are two aspects of the two applications: one "administrative" aspect (managing the data structure and relationship between the data rows) and one "generic user" aspect (reading/modifying the actual data values). It's a deliberate choice to separate these two aspects in separate applications.
NOTE! The data values are separated from the data structure, i.e. the values are stored in one separate table and the structure is described in another table. This means that the two applications will essentially modify two different tables in the same database and they will never modify "the other table", so to speak.
Any thoughts are greatly appreciated. The application is yet on a planning stage, so, now is the time to make fundamental changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Dbm，
是的，它被接受、鼓励并且可以在 Android 上进行。你确实有第三个选择（这无疑会给我带来一些激烈的评论），那就是把 ContentProvider (1) 放在一个它自己的 APK 中。但是，鉴于您只有 2 种类型，您可以翻转四分之一的 apk 托管。我会选择管理应用程序，但这对我来说是主观的。
如果您要麻烦地创建两个应用程序，那么您就“先验”了解每个应用程序将做什么，以及每个应用程序可以操作什么类型的数据。因此，我会得出一个单一的 CP 接口，并根据您所描述的行为来限制每个应用程序调用的内容。
坦率
Dbm,
Yes, it is accepted, encouraged and possible to do on Android. You do have a 3rd option (that will no doubt get me some burning commentary) and that's to put the ContentProvider (1) in an APK all of it's own. But, given that you only have 2 types, you can flip a quarter over which apk it is hosted by. I would choose the admin app, but that is subjective on my part.
If you are going to the trouble of creating two applications then you have "a priori" knowledge of what the behavior of each will do, and what kind of data that each can operate. Therefore I would conclude a single CP interface and just constrain what each app calls given the behavior you've described.
Frank