Primera asignar a cada mesa de un único id - Clave principal (PK)
tabla de preguntas - muchos a uno la relación con el Usuario
mesa respuesta - relación uno a uno con la pregunta
tabla de usuario - uno a muchos con la pregunta
Question
+--------------+------------+------------------+
| int | Id | PK |
| varchar(max) | question | |
| int | userId | FK (Foreign Key) |
| bool | answered | |
| bool | correct | |
+--------------+------------+------------------+
Answer
+--------------+------------+----+
| int | Id | PK |
| int | questionId | FK |
| varchar(max) | reason | |
+--------------+------------+----+
User
+---------------+-------------+--------------------------------------------+
| int | Id | PK |
| varchar (250) | deviceToken | (UUiD) // some unique identifier per phone |
+---------------+-------------+--------------------------------------------+
// other relevant stuff
Cuando la aplicación se descarga, el usuario puede registrarse de forma silenciosa, utilizando el UUID del dispositivo. La base de datos central tendrá que hacer un seguimiento de estas y las preguntas que se responden, en lugar de borrar todo y comenzar de nuevo. 100 filas no son muchas, pero los usuarios podrían potencialmente alcanzar los 1000 o más. En una actualización no es relevante que sea lento repoblar la base de datos local en el teléfono (aunque no necesariamente sería lenta con estas filas, una base de datos con millones de filas llevaría tiempo) ya que se espera que las actualizaciones tomen hora.
Si el usuario cambia de dispositivo, esta información no se transfiere al nuevo dispositivo. Cada dispositivo se trata como un nuevo usuario. Me parece que esto funciona bien si no quieres que las personas se registren, pero desean conservar los datos durante las actualizaciones, o si la aplicación se desinstala y vuelve a instalar en un dispositivo. Tiene sus limitaciones al igual que pedirle a la gente que se registre. Si los usuarios quieren un nuevo comienzo en el juego con el mismo dispositivo, siempre pueden proporcionar una opción "Restablecer estadísticas" y luego borrar esos datos.
Las preferencias compartidas también se pueden usar para guardar la configuración del usuario para la aplicación, creo que puede ser exagerado para un centenar de preguntas, sería mejor almacenar esta información en una base de datos SQLite; la información se mantiene en el servidor. No puede borrar los datos cada vez que hay una actualización, debe mantener registros actuales del progreso del consumidor. No puede confiar en que el dispositivo del consumidor retenga la información. Si hay alguna información que desea realizar un seguimiento, debe asumir la responsabilidad para ello.
Esto se puede almacenar localmente en el teléfono y sincronizar con el servidor regularmente.
En nuestras aplicaciones, así es como lo hacemos y los datos sobreviven a las actualizaciones y tenemos millones de filas. No dude en hacer más preguntas, sin embargo, dar un tutorial real (o el código) de cómo funciona todo esto es una respuesta un poco amplia para Stack Overflow.
Las respuestas deben tener una restricción referencial en las preguntas. la tabla de respuestas tiene questionid. Entonces no puedes romperlo cambiando las preguntas. – danny117
@Anne ¿Intentó utilizar la cláusula update with where para eliminar preguntas que no satisfacen su creteria? –