Обычно (из того, что я узнал), если у вас есть объект, который сам содержит список других объектов, это будет отношение 1 ко многим (или, возможно, ко многим). Для хранения этих данных вы хотели бы использовать другую таблицу. В другой таблице у вас будет ваш первичный ключ для объекта, а затем внешний ключ, ссылающийся на родительский объект, к которому он принадлежит. См. эту ссылку для лучшего объяснения.
Пример:
CREATE TABLE User (
_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
name TEXT
);
CREATE TABLE UserPicture(
_id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
userId INTEGER,
path TEXT
FOREIGN KEY(userId) REFERENCES User(_id)
);
Теперь скажите, что у вас есть пользовательский объект со списком пользовательских изображений, когда вы сохраняете в базу данных
захочет перебрать каждое изображение и вставить каждое в таблицу UserPicture, используя
userId как ссылка обратно на таблицу User.
В случае отношения «многие ко многим» каждый объект будет иметь список своих дочерних объектов.
Лучшим примером этого была бы система членства / роли. Пользователь будет иметь список ролей и роль
будет иметь список пользователей, так как пользователь может (как правило) быть в нескольких ролях, и роль, конечно, может иметь
несколько пользователей. Для этого просто потребовалось бы то, что называется таблицей соединений. UserInRole будет иметь два столбца, UserID и RoleID, чтобы показать, что пользователь X принадлежит роли Y.
Что касается того, как его реализовать, поищите «учебник по Android sqlite». Здесь и здесь - это две ссылки с руководствами по настройке приложения базы данных sqlite для Android.