انواع رابطه بین اشیا را انتخاب کنید

از آنجایی که SQLite یک پایگاه داده رابطه ای است، می توانید روابط بین موجودیت ها را تعریف کنید. اما در حالی که اکثر کتابخانه‌های نگاشت شی-رابطه‌ای به اشیاء موجودیت اجازه می‌دهند به یکدیگر ارجاع دهند، Room به صراحت این کار را ممنوع می‌کند. برای آشنایی با استدلال فنی پشت این تصمیم، به درک اینکه چرا اتاق به ارجاعات اشیا اجازه نمی دهد مراجعه کنید.

انواع روابط

اتاق از انواع روابط زیر پشتیبانی می کند:

  • یک به یک : رابطه ای را نشان می دهد که در آن یک موجودیت واحد با موجودیت واحد دیگری مرتبط است.
  • یک به چند : رابطه ای را نشان می دهد که در آن یک موجودیت واحد می تواند با چندین موجودیت از نوع دیگر مرتبط باشد.
  • Many-to-Many : نشان دهنده رابطه ای است که در آن چندین موجودیت از یک نوع می توانند به چندین موجودیت از نوع دیگر مرتبط شوند. این معمولا به یک میز اتصال نیاز دارد.
  • روابط تودرتو (با استفاده از اشیاء تعبیه شده) : رابطه ای را نشان می دهد که در آن موجودیت دارای موجودیت دیگری به عنوان یک فیلد است و این موجودیت تودرتو می تواند موجودیت های دیگری را نیز در بر گیرد. این از حاشیه نویسی @Embedded استفاده می کند.

بین دو رویکرد انتخاب کنید

در Room دو راه برای تعریف و پرس و جو رابطه بین موجودیت ها وجود دارد. می توانید از یکی از این دو استفاده کنید:

  • یک کلاس داده میانی با اشیاء تعبیه شده یا
  • یک روش پرس و جو رابطه‌ای با نوع بازگشت چند نقشه.

اگر دلیل خاصی برای استفاده از کلاس های داده متوسط ​​ندارید، توصیه می کنیم از رویکرد نوع بازگشت چند نقشه استفاده کنید. برای کسب اطلاعات بیشتر در مورد این رویکرد، به بازگشت یک نقشه چندگانه مراجعه کنید.

رویکرد کلاس داده متوسط ​​به شما امکان می دهد از نوشتن پرس و جوهای پیچیده SQL اجتناب کنید، اما همچنین می تواند منجر به افزایش پیچیدگی کد شود زیرا به کلاس های داده اضافی نیاز دارد. به طور خلاصه، رویکرد نوع بازگشتی چند نقشه ای به درخواست های SQL شما برای انجام کارهای بیشتر نیاز دارد، و رویکرد کلاس داده متوسط ​​به کد شما برای انجام کارهای بیشتر نیاز دارد.

از رویکرد کلاس داده متوسط ​​استفاده کنید

در رویکرد کلاس داده میانی، شما یک کلاس داده تعریف می کنید که رابطه بین موجودیت های اتاق شما را مدل می کند. این کلاس داده جفت‌ها را بین نمونه‌های یک موجودیت و نمونه‌های موجودیت دیگر به‌عنوان اشیاء تعبیه‌شده نگه می‌دارد. سپس روش‌های درخواست شما می‌توانند نمونه‌هایی از این کلاس داده را برای استفاده در برنامه شما برگردانند.

به عنوان مثال، می توانید یک کلاس داده UserBook را برای نمایش کاربران کتابخانه با کتاب های خاص بررسی شده تعریف کنید، و یک روش پرس و جو برای بازیابی لیستی از نمونه های UserBook از پایگاه داده تعریف کنید:

کاتلین 

@Dao
interface UserBookDao {
    @Query(
        "SELECT user.name AS userName, book.name AS bookName " +
        "FROM user, book " +
        "WHERE user.id = book.user_id"
    )
    fun loadUserAndBookNames(): LiveData<List<UserBook>>
}

data class UserBook(val userName: String?, val bookName: String?)

جاوا 

@Dao
public interface UserBookDao {
   @Query("SELECT user.name AS userName, book.name AS bookName " +
          "FROM user, book " +
          "WHERE user.id = book.user_id")
   public LiveData<List<UserBook>> loadUserAndBookNames();
}

public class UserBook {
    public String userName;
    public String bookName;
}

از رویکرد انواع بازگشت چند نقشه استفاده کنید

در رویکرد نوع بازگشت چند نقشه، نیازی به تعریف هیچ کلاس داده اضافی ندارید. در عوض، شما یک نوع بازگشت چند نقشه را برای روش خود بر اساس ساختار نقشه ای که می خواهید تعریف می کنید و رابطه بین موجودیت های خود را مستقیماً در پرس و جوی SQL خود تعریف می کنید.

به عنوان مثال، روش پرس و جو زیر نقشه‌ای از نمونه‌های User و Book برای نمایش کاربران کتابخانه با کتاب‌های خاص بررسی شده برمی‌گرداند:

کاتلین 

@Query(
    "SELECT * FROM user" +
    "JOIN book ON user.id = book.user_id"
)
fun loadUserAndBookNames(): Map<User, List<Book>>

جاوا 

@Query(
    "SELECT * FROM user" +
    "JOIN book ON user.id = book.user_id"
)
public Map<User, List<Book>> loadUserAndBookNames();

ایجاد اشیاء تعبیه شده

گاهی اوقات، شما می خواهید یک موجودیت یا شی داده را به عنوان یک کل منسجم در منطق پایگاه داده خود بیان کنید، حتی اگر شی حاوی چندین فیلد باشد. در این مواقع، می‌توانید از حاشیه‌نویسی @Embedded برای نشان دادن شی‌ای که می‌خواهید به زیر فیلدهای آن در یک جدول تجزیه کنید، استفاده کنید. سپس می‌توانید فیلدهای تعبیه‌شده را پرس و جو کنید، درست همانطور که برای ستون‌های دیگر انجام می‌دهید.

به عنوان مثال، کلاس User شما می‌تواند شامل فیلدی از نوع Address باشد که ترکیبی از فیلدهایی به نام‌های street ، city ، state و postCode را نشان می‌دهد. برای ذخیره ستون های تشکیل شده به طور جداگانه در جدول، یک فیلد Address قرار دهید. این باید در کلاس User با حاشیه نویسی @Embedded ظاهر شود. قطعه کد زیر این را نشان می دهد:

کاتلین 

data class Address(
    val street: String?,
    val state: String?,
    val city: String?,
    @ColumnInfo(name = "post_code") val postCode: Int
)

@Entity
data class User(
    @PrimaryKey val id: Int,
    val firstName: String?,
    @Embedded val address: Address?
)

جاوا 

public class Address {
    public String street;
    public String state;
    public String city;

    @ColumnInfo(name = "post_code") public int postCode;
}

@Entity
public class User {
    @PrimaryKey public int id;

    public String firstName;

    @Embedded public Address address;
}

سپس جدولی که یک شی User را نشان می‌دهد شامل ستون‌هایی با نام‌های زیر است: id ، firstName ، street ، state ، city و post_code .

اگر یک موجودیت دارای چندین فیلد جاسازی شده از یک نوع باشد، می توانید با تنظیم ویژگی prefix ، هر ستون را منحصر به فرد نگه دارید. سپس Room مقدار ارائه شده را به ابتدای نام هر ستون در شی جاسازی شده اضافه می کند.

منابع اضافی

برای کسب اطلاعات بیشتر در مورد تعریف روابط بین موجودات در اتاق، به منابع اضافی زیر مراجعه کنید.

ویدیوها

وبلاگ ها