Android: ContentProvider para cada tabla/manipulación relaciones uno-a-muchos

Question

Cuando se utiliza un proveedor de contenidos para el acceso de base de datos SQLite

1. ¿Es mejor la práctica de tener un proveedor de contenidos para cada tabla o utilizar uno para todos ¿mesas?
2. ¿Cómo manejar las relaciones de uno a muchos al crear nuevos registros?

Answer 1

A ContentProvider no es una base de datos

A ContentProvider es una manera de públicamente (o semi-público) datos de acceso como el contenido. Esto se puede hacer de varias maneras, a través de acceso a archivos, SQLite o incluso acceso a la web. Un ContentProvider en sí mismo no es una base de datos, pero puede programar una base de datos para ello. También puede tener múltiples ContentProviders accediendo a la misma base de datos, pero distribuyendo diferentes niveles de acceso, o el mismo contenido de diferentes maneras según el solicitante. Lo que realmente está preguntando no es una pregunta de ContentProvider, sino una pregunta de base de datos "Cómo manejar relaciones en una base de datos SQLite" porque ContentProvider no usa ningún código de base de datos a menos que lo diga clases Entonces, simplemente tiene que programar su acceso a la base de datos correctamente y su base de datos SQLite funcionará como lo desee.

Una base de datos es una base de datos

En los viejos tiempos, las bases de datos eran simplemente archivos planos, donde cada mesa era a menudo su propia entidad para permitir el crecimiento. Ahora, con DBMS, hay muy pocas razones para hacer eso alguna vez. SQLite es como cualquier otra plataforma de base de datos en este aspecto y puede albergar tantas tablas como espacio tenga para guardarlas.

SQLite

hay ciertas características que SQLite se maneja bien, algunos que se maneja - pero no está bien, y algunos que no maneja en absoluto. Las relaciones son una de esas cosas que quedaron fuera de algunas versiones de SQLite de Android, ya que se enviaron sin soporte de clave externa. Esta fue una característica muy solicitada y se agregó en SQLite 3.6.22, que no se envió hasta Android 2.2. Sin embargo, todavía hay muchos errores reportados con él en sus primeras encarnaciones.

Android pre 2.2

siendo Afortunadamente SQL compatible y un DBMS sencilla (no RDBMS en este momento), hay algunas maneras fáciles de trabajar alrededor de esto, después de todo, una clave externa es sólo un campo en otra mesa

1. Puede aplicar base de datos INSERT y UPDATE declaraciones de crear CONSTRAINT s cuando se utiliza el extracto CREATE TABLE.
2. Puede consultar la otra tabla para obtener el _id apropiado para obtener su clave externa.
3. Puede consultar su tabla de origen con cualquier declaración SELECT adecuada utilizando un INNER JOIN, imponiendo así una pseudo relación.

Dado que la versión de SQLite de Android no hace cumplir las relaciones directamente, si desea CASCADE ON DELETE tendría que hacerlo manualmente. Pero esto se puede hacer a través de otra instrucción SQL simple. Básicamente, he escrito mi propia biblioteca para hacer cumplir este tipo de relaciones, ya que todo debe hacerse de forma manual. Debo decir, sin embargo, que la eficacia de SQLite y SQL en conjunto hace que esto sea muy rápido y fácil.

En esencia, el proceso para cualquier relación exigida es la siguiente:

• En una consulta que requiere una clave externa, utilice un JOIN.
• En una INSERT utilizar un CONSTRAINT en el campo de clave externa de NOT NULL
• En una UPDATE en el campo de clave principal que es una clave externa en otro TABLE, ejecute una segunda UPDATE en la relacionada TABLE que tiene la clave externa. (ACTUALIZACIÓN CASCADE)
• Para una DELETE con los mismos parámetros, hacer otra DELETE con el donde ser foreign_key = _id (asegúrese de obtener el _id antes de DELETE la fila, en primer lugar).

Android 2.2 +

Las claves externas se soporta, pero está desactivada por defecto. En primer lugar usted tiene que encenderlos:

db.execSQL("PRAGMA foreign_keys=ON;"); 

siguiente que tiene que crear la relación TRIGGER. Esto se hace cuando crea el TABLE, en lugar de una declaración TRIGGER por separado. Vea a continuación:

// Added at the end of CREATE TABLE statement in the MANY table 
FOREIGN KEY(foreign_key_name) REFERENCES one_table_name(primary_key_name) 

Para más información sobre SQLite y sus capacidades, echa un vistazo a SQLite official site. Esto es importante ya que no tiene todos los JOIN que hace en otros RDBMS. Para obtener información específica sobre las clases de SQLite en Android, lea the documentation.

Answer 2

En cuanto a la primera pregunta: no es necesario crear un proveedor de contenido para cada tabla. Puede usar con varias tablas, pero la complejidad del proveedor aumentó con cada tabla.

Answer 3

Un proveedor de contenido es más o menos equivalente al concepto de una base de datos. Tendría varias tablas en una base de datos, por lo que tener múltiples tablas en su proveedor de contenido tiene mucho sentido.

Las relaciones de uno a muchos se pueden manejar como en cualquier otra base de datos. Use referencias y claves externas como lo haría con cualquier otra base de datos. Puede usar cosas como CASCADE ON DELETE para asegurarse de que los registros se eliminen cuando los registros a los que hacen referencia en otras tablas también se eliminan.