Realm คือโซลูชันฐานข้อมูล Android ที่ดีที่สุด

เผยแพร่แล้ว: 2022-03-11

ตั้งแต่สร้าง Android ขึ้นมา นักพัฒนาแอปของเราก็ใช้ SQLite เพื่อจัดเก็บข้อมูลในเครื่องของเรา บางครั้งใช้คำสั่ง SQL โดยตรง บางครั้งใช้ Object-Relational Mapper (ORM) เป็นเลเยอร์นามธรรม แต่ไม่ว่าอย่างไรก็ตาม เราใช้ SQLite เมื่อสิ้นสุดวัน

แม้จะมีข้อดีของ SQLite ทั้งหมด แต่ก็มีบางครั้งที่เราอยากให้เรามีทางเลือกอื่นแทนโมเดลเชิงสัมพันธ์: สิ่งที่สามารถช่วยเราไม่ต้องเพิ่มรหัสสำเร็จรูปเพื่อแปลงค่าเป็นและจากฐานข้อมูล หรือทำให้เราข้ามการตั้งค่าการแมป ระหว่างคลาสและตาราง ฟิลด์และคอลัมน์ คีย์นอก ฯลฯ

กล่าวคือ ฐานข้อมูลที่มีโครงสร้างข้อมูลคล้ายกับที่เราใช้จริงในระดับแอปพลิเคชัน ยังดีกว่าถ้ามันสามารถเป็นหน่วยความจำที่มีประสิทธิภาพโดยการออกแบบที่ช่วยให้ประสบการณ์ที่ดีขึ้นในอุปกรณ์ที่มีข้อ จำกัด ทรัพยากรที่จะน่ากลัว

อันที่จริงแล้ว ประโยชน์บางส่วนที่พร้อมใช้งานทันทีที่เราได้รับจาก Realm ซึ่งเป็นแพลตฟอร์มฐานข้อมูลที่มีสถาปัตยกรรมที่แตกต่างออกไป ซึ่งกลายเป็นทางเลือกใหม่สำหรับ SQLite

บทความนี้นำเสนอสาเหตุหลักบางประการที่ทำให้ Realm ได้รับความสนใจอย่างมากและทำไมคุณจึงอาจต้องการลองใช้มัน กล่าวถึงข้อดีหลักบางประการที่ Realm มอบให้กับนักพัฒนา Android ผ่าน SQLite

เนื่องจาก Realm มีให้บริการในหลายแพลตฟอร์ม สิ่งที่จะกล่าวถึงในบทความนี้บางส่วนจึงมีความเกี่ยวข้องกับแพลตฟอร์มมือถืออื่นๆ เช่น iOS, Xamarin และ React Native

SQLite: ใช้งานได้แต่ไม่ใช่สิ่งที่คุณต้องการตลอดเวลา

นักพัฒนามือถือส่วนใหญ่คงคุ้นเคยกับ SQLite มีมาตั้งแต่ปี 2000 และถือเป็นเครื่องมือฐานข้อมูลเชิงสัมพันธ์ที่ใช้มากที่สุดในโลก

SQLite มีประโยชน์มากมายที่เราทุกคนยอมรับ หนึ่งในนั้นคือการรองรับแบบเนทีฟบน Android

ความจริงที่ว่ามันเป็นฐานข้อมูลเชิงสัมพันธ์ SQL มาตรฐานยังช่วยลดเส้นโค้งการเรียนรู้สำหรับผู้ที่มาจากพื้นหลังฐานข้อมูลเชิงสัมพันธ์ นอกจากนี้ยังให้ประสิทธิภาพที่ดีพอสมควรหากใช้จนเต็มศักยภาพ (ใช้ประโยชน์จากคุณลักษณะ เช่น ข้อความที่เตรียมไว้ การดำเนินการจำนวนมากกับธุรกรรม ฯลฯ) แม้ว่า SQLite อาจไม่ปรับขนาดได้ดีมากสำหรับความต้องการของคุณทั้งหมด

การจัดการโดยตรงกับคำสั่ง SQL มีข้อเสียหลายประการ

ตามเอกสารทางการของ Android ต่อไปนี้เป็นขั้นตอนที่จำเป็นในการเริ่มอ่าน/เขียนไปยัง SQLite:

  1. อธิบายสคีมาของคุณในแง่ของคลาสสัญญา
  2. กำหนดคำสั่งสร้าง/วางตารางของคุณในสตริง
  3. ขยาย SQLiteOpenHelper เพื่อเรียกใช้คำสั่งสร้างและจัดการการอัปเกรด/ดาวน์เกรด

เมื่อคุณทำเสร็จแล้ว คุณก็พร้อมที่จะอ่านและเขียนไปยังฐานข้อมูลของคุณ อย่างไรก็ตาม คุณจะต้องแปลงไปมาระหว่างอ็อบเจ็กต์ในแอปพลิเคชันของคุณและค่าในฐานข้อมูล เรื่องสั้นสั้น: มันเป็นรหัสสำเร็จรูปมากมาย!

ปัญหาอีกประการหนึ่งคือการบำรุงรักษา เมื่อโปรเจ็กต์ของคุณมีขนาดใหญ่ขึ้นและจำเป็นต้องเขียนการสืบค้นที่ซับซ้อนมากขึ้น คุณจะจบลงด้วยการสืบค้น SQL ดิบจำนวนมากในสตริง หากในภายหลังคุณจำเป็นต้องเปลี่ยนตรรกะของข้อความค้นหาเหล่านั้น อาจเป็นเรื่องยุ่งยากทีเดียว

แม้จะมีข้อเสีย แต่ก็มีบางกรณีที่การใช้ raw SQL เป็นตัวเลือกที่ดีที่สุดของคุณ ตัวอย่างหนึ่งคือเมื่อคุณกำลังพัฒนาไลบรารีที่ประสิทธิภาพและขนาดเป็นปัจจัยสำคัญ และควรหลีกเลี่ยงการเพิ่มไลบรารีของบุคคลที่สามหากเป็นไปได้

Object-Relational Mapper: The Band-aid for SQL Challenges

เพื่อช่วยเราจากการจัดการกับ SQL แบบดิบ ORM ได้เข้ามาช่วยเหลือ

Android ORM ที่มีชื่อเสียงที่สุดบางตัว ได้แก่ DBFlow, greenDAO และ OrmLite

คุณค่าที่ยิ่งใหญ่ที่สุดที่พวกเขานำมาคือการสร้างนามธรรมของ SQLite ทำให้เราสามารถแมปเอนทิตีฐานข้อมูลกับอ็อบเจกต์ Java ได้ค่อนข้างง่าย

ท่ามกลางประโยชน์อื่นๆ นักพัฒนาแอปพลิเคชันสามารถทำงานกับอ็อบเจ็กต์ ซึ่งเป็นโครงสร้างข้อมูลที่คุ้นเคยมากขึ้น นอกจากนี้ยังช่วยในการบำรุงรักษา เนื่องจากขณะนี้เรากำลังจัดการออบเจ็กต์ระดับสูงด้วยการพิมพ์ที่รัดกุมยิ่งขึ้น และปล่อยให้งานสกปรกไปที่ไลบรารี มีปัญหาน้อยลงกับการสร้างคิวรีโดยการต่อสตริงหรือจัดการการเชื่อมต่อกับฐานข้อมูลด้วยตนเอง พิมพ์ผิดน้อยลง

แม้ว่า ORM เหล่านี้จะยกระดับมาตรฐานบนฐานข้อมูล Android ก็ตาม แต่ก็มีข้อเสียอยู่เช่นกัน ในหลายกรณี คุณลงเอยด้วยการโหลดข้อมูลที่ไม่จำเป็น

นี่คือตัวอย่าง

สมมติว่าคุณมีตารางที่มี 15 คอลัมน์ และในบางหน้าจอของแอป รายชื่อของอ็อบเจ็กต์จากตารางนี้จะแสดงขึ้น รายการนี้แสดงค่าจากสามคอลัมน์เท่านั้น ดังนั้น เมื่อโหลดข้อมูลทั้งหมดจากแถวของตาราง คุณจะนำข้อมูลมามากกว่าที่คุณต้องการจริงๆ สำหรับหน้าจอนั้นถึงห้าเท่า

ตามจริงแล้ว ในบางไลบรารีเหล่านี้ คุณสามารถระบุคอลัมน์ที่คุณต้องการดึงข้อมูลล่วงหน้าได้ แต่สำหรับสิ่งที่คุณต้องเพิ่มโค้ดเพิ่มเติม และถึงกระนั้น นั่นจะไม่เพียงพอในกรณีที่คุณสามารถรู้ได้อย่างแน่ชัดว่าคอลัมน์ใดที่คุณจะ ใช้หลังจากที่คุณดูข้อมูลแล้ว: ข้อมูลบางอย่างอาจโหลดโดยไม่จำเป็นอยู่แล้ว

นอกจากนี้ มักมีสถานการณ์ที่คุณมีการสืบค้นข้อมูลที่ซับซ้อน และไลบรารี ORM ของคุณไม่ได้เสนอวิธีอธิบายการสืบค้นเหล่านี้ด้วย API ที่สามารถทำให้คุณเขียนแบบสอบถามที่ไม่มีประสิทธิภาพซึ่งทำการคำนวณมากกว่าที่คุณต้องการเป็นต้น

ผลที่ตามมาคือการสูญเสียประสิทธิภาพ ทำให้คุณหันไปใช้ SQL แบบดิบ แม้ว่านี่จะไม่ใช่ตัวทำลายข้อตกลงสำหรับพวกเราหลายคน แต่ก็กระทบต่อจุดประสงค์หลักของการทำแผนที่เชิงวัตถุและนำเรากลับไปที่ปัญหาที่กล่าวถึงข้างต้นเกี่ยวกับ SQLite

อาณาจักร: ทางเลือกที่สมบูรณ์แบบ

Realm Mobile Database เป็นฐานข้อมูลที่ออกแบบมาสำหรับอุปกรณ์พกพาตั้งแต่เริ่มต้น

ความแตกต่างที่สำคัญระหว่าง Realm และ ORM คือ Realm ไม่ใช่สิ่งที่เป็นนามธรรมที่สร้างขึ้นบน SQLite แต่เป็นเอ็นจิ้นฐานข้อมูลใหม่ทั้งหมด แทนที่จะเป็นโมเดลเชิงสัมพันธ์ มันขึ้นอยู่กับที่เก็บอ็อบเจ็กต์ แกนกลางประกอบด้วยไลบรารี C ++ ในตัว ปัจจุบันรองรับ Android, iOS (Objective-C และ Swift), Xamarin และ React Native

Realm เปิดตัวในเดือนมิถุนายน 2014 ดังนั้นตอนนี้จึงมีอายุสองปีครึ่ง (ใหม่มาก!)

ในขณะที่เทคโนโลยีฐานข้อมูลเซิร์ฟเวอร์กำลังผ่านการปฏิวัติมาตั้งแต่ปี 2550 โดยมีเทคโนโลยีใหม่เกิดขึ้นมากมาย เทคโนโลยีฐานข้อมูลสำหรับอุปกรณ์พกพายังคงติดอยู่กับ SQLite และตัวห่อหุ้ม นี่เป็นหนึ่งในแรงจูงใจหลักในการสร้างบางสิ่งตั้งแต่เริ่มต้น ยิ่งไปกว่านั้น ดังที่เราจะได้เห็นกัน ฟีเจอร์บางอย่างของ Realm จำเป็นต้องมีการเปลี่ยนแปลงขั้นพื้นฐานในลักษณะที่ฐานข้อมูลทำงานในระดับต่ำ และนั่นก็เป็นไปไม่ได้ที่จะสร้างบางสิ่งบน SQLite

แต่ Realm คุ้มค่าจริงหรือ? นี่คือเหตุผลหลักว่าทำไมคุณจึงควรพิจารณาเพิ่ม Realm ให้กับสายพานเครื่องมือของคุณ

การสร้างแบบจำลองอย่างง่าย

ต่อไปนี้คือตัวอย่างโมเดลบางรุ่นที่สร้างด้วย Realm:

 public class Contact extends RealmObject { @PrimaryKey String id; protected String name; String email; @Ignore public int sessionId; //Relationships private Address address; private RealmList<Contact> friends; //getters & setter left out for brevity }
 public class Address extends RealmObject { @PrimaryKey public Long id; public String name; public String address; public String city; public String state; public long phone; }

โมเดลของคุณขยายจาก RealmObject Realm ยอมรับประเภทดั้งเดิมและประเภทกล่องทั้งหมด (ยกเว้น char ), String , Date และ byte[] นอกจากนี้ยังรองรับคลาสย่อยของ RealmObject และ RealmList<? extends RealmObject> RealmList<? extends RealmObject> ไปยังความสัมพันธ์ของโมเดล

ฟิลด์สามารถมีระดับการเข้าถึงใดก็ได้ (ส่วนตัว สาธารณะ การป้องกัน ฯลฯ) ฟิลด์ทั้งหมดจะคงอยู่โดยค่าเริ่มต้น และคุณเพียงแค่ต้องใส่คำอธิบายประกอบให้กับฟิลด์ "พิเศษ" (เช่น @PrimaryKey สำหรับฟิลด์คีย์หลักของคุณ @Ignore เพื่อตั้งค่าฟิลด์ที่ไม่ต่อเนื่อง ฯลฯ)

สิ่งที่น่าสนใจเกี่ยวกับวิธีการนี้คือทำให้คลาสมี "คำอธิบายประกอบเสีย" น้อยกว่าเมื่อเปรียบเทียบกับ ORM เนื่องจากส่วนใหญ่คุณต้องการคำอธิบายประกอบเพื่อจับคู่คลาสกับตาราง ฟิลด์ปกติกับคอลัมน์ฐานข้อมูล ฟิลด์คีย์ภายนอกไปยังตารางอื่น ๆ เป็นต้น บน.

ความสัมพันธ์

เมื่อพูดถึงความสัมพันธ์ มีสองตัวเลือก:

  • เพิ่มโมเดลเป็นฟิลด์จากโมเดลอื่น ในตัวอย่างของเรา คลาสผู้ Contact มีฟิลด์ Address และที่กำหนดความสัมพันธ์ของพวกเขา ผู้ติดต่ออาจมีที่อยู่ แต่ไม่มีอะไรหยุดการเพิ่มที่อยู่เดียวกันนี้ในผู้ติดต่อรายอื่น ที่ช่วยให้มีความสัมพันธ์แบบหนึ่งต่อหนึ่งและหนึ่งต่อกลุ่ม

  • เพิ่ม RealmList ของโมเดลที่กำลังอ้างอิง RealmLists ทำงานค่อนข้างเหมือนกับ Java Lists แบบเก่าซึ่งทำหน้าที่เป็นคอนเทนเนอร์ของวัตถุ Realm เราจะเห็นว่ารูปแบบการ Contact ของเรามีรายชื่อผู้ติดต่อ RealmList ซึ่งเป็นเพื่อนของเธอในตัวอย่างนี้ ความสัมพันธ์แบบหนึ่งต่อกลุ่มและแบบกลุ่มต่อกลุ่มสามารถสร้างแบบจำลองได้ด้วยวิธีนี้

ฉันชอบวิธีการแสดงความสัมพันธ์นี้เพราะนักพัฒนา Java รู้สึกเป็นธรรมชาติมาก โดยการเพิ่มอ็อบเจ็กต์เหล่านี้ (หรือรายการของอ็อบเจ็กต์เหล่านี้) โดยตรงเป็นฟิลด์ของคลาสของเรา เช่นเดียวกับที่เราทำกับคลาสอื่นที่ไม่ใช่โมเดล เราไม่จำเป็นต้องจัดการกับการตั้งค่า SQLite สำหรับคีย์ภายนอก

คำ เตือน: ไม่มีการรองรับการสืบทอดแบบจำลอง วิธีแก้ปัญหาปัจจุบันคือการใช้องค์ประกอบ ตัวอย่างเช่น ถ้าคุณมีโมเดล Animal และหวังว่าจะสร้างโมเดล Dog ที่ขยายจาก Animal คุณจะต้องเพิ่มอินสแตนซ์ Animal เป็นฟิลด์ใน Dog แทน มีการถกเถียงกันอย่างมากเกี่ยวกับองค์ประกอบและมรดก หากคุณกำลังใช้มรดก นี่คือสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับอาณาจักรอย่างแน่นอน ด้วย SQLite สิ่งนี้สามารถนำไปใช้ได้โดยใช้สองตาราง (ตารางหนึ่งสำหรับพาเรนต์และอีกตารางสำหรับรายการย่อย) ที่เชื่อมต่อด้วยคีย์ภายนอก ORM บางตัวไม่ได้กำหนดข้อจำกัดนี้ เช่น DBFlow

ดึงเฉพาะข้อมูลที่คุณต้องการ! การออกแบบ Zero-copy

นี่คือคุณสมบัตินักฆ่า

Realm ใช้แนวคิดของการออกแบบ Zero-copy ซึ่งหมายความว่าข้อมูลจะไม่ถูกคัดลอกไปยังหน่วยความจำ ผลลัพธ์ที่คุณได้รับจากการสืบค้นเป็นเพียงตัวชี้ไปยังข้อมูลจริงเท่านั้น ข้อมูลนั้นโหลดอย่างเกียจคร้านเมื่อคุณเข้าถึง

ตัวอย่างเช่น คุณมีโมเดลที่มี 10 ฟิลด์ (คอลัมน์ใน SQL) หากคุณสอบถามวัตถุของแบบจำลองนี้เพื่อแสดงรายการบนหน้าจอ และคุณเพียงแค่ต้องการสามใน 10 ฟิลด์เพื่อเติมข้อมูลในรายการ ฟิลด์เหล่านั้นจะเป็นฟิลด์เดียวที่ดึงข้อมูล

ด้วยเหตุนี้ ข้อความค้นหาจึงรวดเร็วอย่างเห็นได้ชัด (ดูที่นี่และที่นี่สำหรับผลการเปรียบเทียบบางส่วน)

นี่เป็นข้อได้เปรียบเหนือ ORM ซึ่งมักจะโหลดข้อมูลทั้งหมดจากแถว SQL ที่เลือกไว้ล่วงหน้า

การโหลดหน้าจอมีประสิทธิภาพมากขึ้นอย่างมาก ส่งผลให้ไม่ต้องพยายามเพิ่มเติมจากนักพัฒนา: มันเป็นเพียงพฤติกรรมเริ่มต้นของ Realm

นอกจากนี้ยังหมายความว่าแอปใช้หน่วยความจำน้อยลง และเมื่อพิจารณาว่าเรากำลังพูดถึงสภาพแวดล้อมที่มีข้อจำกัดด้านทรัพยากร เช่น อุปกรณ์เคลื่อนที่ ซึ่งสามารถสร้างความแตกต่างได้อย่างมาก

ผลที่ตามมาอีกประการของแนวทาง Zero-copy คืออ็อบเจ็กต์ที่จัดการโดย Realm จะได้รับการอัปเดตอัตโนมัติ

ข้อมูลจะไม่ถูกคัดลอกไปยังหน่วยความจำ หากคุณมีผลลัพธ์จากการสืบค้น และเธรดอื่นได้อัปเดตข้อมูลนี้ในฐานข้อมูลหลังจากการสืบค้นของคุณ ผลลัพธ์ที่คุณมีจะสะท้อนถึงการเปลี่ยนแปลงเหล่านี้แล้ว ผลลัพธ์ของคุณเป็นเพียงตัวชี้ไปยังข้อมูลจริง ดังนั้นเมื่อคุณเข้าถึงค่าจากฟิลด์ ข้อมูลล่าสุดจะถูกส่งกลับ

ภาพประกอบ: การเข้าถึงข้อมูล Realm จากหลายอ็อบเจ็กต์และเธรด

หากคุณได้อ่านข้อมูลจากออบเจ็กต์ Realm แล้วและแสดงข้อมูลดังกล่าวบนหน้าจอ เป็นต้น และต้องการรับการอัปเดตเมื่อข้อมูลพื้นฐานเปลี่ยนแปลง คุณสามารถเพิ่ม Listener ได้:

 final RealmResults<Contact> johns = realm.where(Contact.class).beginsWith("name", "John ").findAll(); johns.addChangeListener(new RealmChangeListener<RealmResults<Contact>>() { @Override public void onChange(RealmResults<Contact> results) { // UPDATE UI } });

ไม่ใช่แค่กระดาษห่อ

แม้ว่าเราจะมีตัวเลือกมากมายสำหรับ ORM แต่ก็เป็น wrapper และทั้งหมดนั้นขึ้นอยู่กับ SQLite ซึ่งจำกัดว่าจะไปได้ไกลแค่ไหน ในทางตรงกันข้าม Realm ไม่ได้เป็นเพียงตัวห่อหุ้ม SQLite ตัวอื่น มีอิสระในการจัดเตรียมคุณลักษณะที่ ORM ไม่สามารถนำเสนอได้

การเปลี่ยนแปลงพื้นฐานอย่างหนึ่งของ Realm คือการสามารถจัดเก็บข้อมูลเป็นที่เก็บกราฟอ็อบเจ็กต์ได้

ซึ่งหมายความว่า Realm เป็นวัตถุตั้งแต่ระดับภาษาการเขียนโปรแกรมไปจนถึงฐานข้อมูล ดังนั้นจึงมีการแปลงกลับไปกลับมาน้อยลงเมื่อคุณเขียนและอ่านค่า เมื่อเปรียบเทียบกับฐานข้อมูลเชิงสัมพันธ์

โครงสร้างฐานข้อมูลสะท้อนถึงโครงสร้างข้อมูลที่นักพัฒนาแอปพลิเคชันใช้อย่างใกล้ชิดยิ่งขึ้น อันที่จริง นี่เป็นหนึ่งในสาเหตุหลักที่ทำให้มีการเคลื่อนไหวออกจากการสร้างแบบจำลองเชิงสัมพันธ์และไปสู่แบบจำลองรวมในการพัฒนาฝั่งเซิร์ฟเวอร์ ในที่สุด Realm ก็นำแนวคิดเหล่านี้มาสู่โลกของการพัฒนาอุปกรณ์พกพา

หากเรานึกถึงส่วนประกอบในสถาปัตยกรรมของ Realm ที่ด้านล่างสุดมีแกนหลักพร้อมการใช้งานแพลตฟอร์มพื้นฐานที่สุด ยิ่งไปกว่านั้น เราจะมีการเชื่อมโยงไลบรารีกับแต่ละแพลตฟอร์มที่รองรับ

ภาพประกอบ: สถาปัตยกรรม Realm จากแกนหลักไปยังไลบรารีต่างๆ

เมื่อใช้ wrapper สำหรับเทคโนโลยีบางอย่างที่คุณไม่สามารถควบคุมได้ ในที่สุดคุณจะต้องจัดเตรียมเลเยอร์ที่เป็นนามธรรมรอบๆ ตัวมัน

Realm Binding libs ได้รับการออกแบบมาให้บางที่สุดเท่าที่จะเป็นไปได้ เพื่อลดความซับซ้อนของนามธรรม พวกเขาส่วนใหญ่เผยแพร่แนวคิดการออกแบบจาก Core ด้วยการควบคุมสถาปัตยกรรมทั้งหมด ส่วนประกอบเหล่านี้จึงทำงานร่วมกันได้ดีขึ้น

ตัวอย่างหนึ่งที่ใช้งานได้จริงคือการเข้าถึงวัตถุอ้างอิงอื่น ๆ (กุญแจต่างประเทศใน SQL) โครงสร้างไฟล์ของ Realm อิงตามลิงก์ดั้งเดิม ดังนั้นเมื่อคุณค้นหาความสัมพันธ์ แทนที่จะต้องแปล ORM abstraction เป็นเชิงสัมพันธ์และ/หรือรวมหลายตาราง คุณจะได้รับลิงก์ดิบไปยังอ็อบเจ็กต์ที่ระดับระบบไฟล์ในรูปแบบไฟล์

นั่นคือวัตถุที่ชี้ตรงไปยังวัตถุอื่น ดังนั้น การสอบถามความสัมพันธ์จึงเหมือนกับการสอบถามคอลัมน์จำนวนเต็ม เป็นต้น ไม่จำเป็นต้องใช้การดำเนินการที่มีราคาแพงในการข้ามคีย์ต่างประเทศ มันคือทั้งหมดที่เกี่ยวกับตัวชี้ต่อไปนี้

ชุมชนและการสนับสนุน

Realm อยู่ระหว่างการพัฒนาอย่างแข็งขันและมีการเผยแพร่เวอร์ชันที่อัปเดตค่อนข้างบ่อย

ส่วนประกอบทั้งหมดจาก Realm Mobile Database เป็นโอเพ่นซอร์ส พวกเขาตอบสนองอย่างมากกับตัวติดตามปัญหาและ Stack Overflow ดังนั้นคุณสามารถคาดหวังการสนับสนุนที่ดีและรวดเร็วจากช่องทางเหล่านี้

นอกจากนี้ ข้อเสนอแนะจากชุมชนจะถูกนำมาพิจารณาเมื่อจัดลำดับความสำคัญของปัญหา (ข้อบกพร่อง การปรับปรุง คำขอคุณลักษณะ ฯลฯ) เป็นเรื่องดีเสมอที่รู้ว่าคุณสามารถพูดได้ในการพัฒนาเครื่องมือที่คุณใช้

ฉันเริ่มใช้ Realm ในปี 2015 และตั้งแต่นั้นเป็นต้นมา ฉันก็เจอโพสต์ต่างๆ บนเว็บที่มีความคิดเห็นต่างๆ เกี่ยวกับ Realm เราจะพูดถึงข้อจำกัดในเร็วๆ นี้ แต่สิ่งหนึ่งที่ฉันสังเกตเห็นคือการร้องเรียนจำนวนมาก ณ เวลาที่โพสต์นั้นได้รับการแก้ไขแล้ว

ตัวอย่างเช่น เมื่อฉันได้รู้เกี่ยวกับ Realm ยังไม่มีการรองรับเมธอดแบบกำหนดเองในโมเดลและการโทรแบบอะซิงโครนัส สิ่งเหล่านี้เป็นตัวทำลายข้อตกลงสำหรับหลาย ๆ คนในขณะนั้น แต่ทั้งคู่ได้รับการสนับสนุนในปัจจุบัน

ความเร็วและการตอบสนองของการพัฒนาดังกล่าวทำให้เรามั่นใจมากขึ้นว่าเราจะไม่รอนานสำหรับคุณสมบัติที่สำคัญ

ข้อจำกัด

เช่นเดียวกับทุกสิ่งทุกอย่างในชีวิต Realm ไม่ใช่ดอกกุหลาบทั้งหมด นอกจากข้อจำกัดการรับมรดกที่กล่าวไว้ก่อนหน้านี้ ยังมีข้อบกพร่องอื่นๆ ที่ต้องคำนึงถึง:

  • แม้ว่าจะเป็นไปได้ที่จะมีหลายเธรดที่อ่านและเขียนไปยังฐานข้อมูลพร้อมกัน แต่ วัตถุ Realm ก็ไม่สามารถย้ายข้ามเธรด ได้ ตัวอย่างเช่น หากคุณดึงข้อมูลวัตถุ realm โดยใช้ doInBackground doInBackground() ของ AsyncTask ซึ่งทำงานในเธรดพื้นหลัง คุณจะไม่สามารถส่งผ่านอินสแตนซ์นี้ไปยัง onPostExecute() ได้ เนื่องจากสิ่งเหล่านี้ทำงานบนเธรดหลัก วิธีแก้ปัญหาที่เป็นไปได้สำหรับสถานการณ์นี้คือการทำสำเนาของอ็อบเจ็กต์แล้วส่งต่อหรือส่ง id ของอ็อบเจ็กต์และดึงข้อมูลอ็อบเจ็กต์อีกครั้งบน onPostExecute() Realm นำเสนอวิธีการแบบซิงโครนัสและแบบอะซิงโครนัสสำหรับการอ่าน/เขียน

  • ไม่มีการสนับสนุนสำหรับคีย์หลักที่เพิ่มค่าอัตโนมัติ ดังนั้น คุณจะต้องจัดการการสร้างคีย์เหล่านี้ด้วยตนเอง

  • ไม่สามารถเข้าถึงฐานข้อมูลจากกระบวนการที่แตกต่างกันในเวลาเดียวกัน ตามเอกสารของพวกเขา การสนับสนุนหลายกระบวนการกำลังจะมาในเร็วๆ นี้

อาณาจักรคืออนาคตของโซลูชั่นฐานข้อมูลมือถือ

SQLite เป็นกลไกจัดการฐานข้อมูลที่แข็งแกร่ง แข็งแกร่ง และผ่านการพิสูจน์แล้ว และฐานข้อมูลเชิงสัมพันธ์จะไม่หายไปในเร็วๆ นี้ มี ORM ที่ดีจำนวนหนึ่งที่จะช่วยแก้ปัญหาในสถานการณ์ต่างๆ ได้เช่นกัน

อย่างไรก็ตาม การติดตามแนวโน้มปัจจุบันเป็นสิ่งสำคัญ

ในเรื่องนี้ ฉันคิดว่า Realm เป็นหนึ่งในแนวโน้มที่ยิ่งใหญ่ที่สุดที่จะเกิดขึ้นในช่วงไม่กี่ปีที่ผ่านมา เมื่อพูดถึงการพัฒนาฐานข้อมูลบนมือถือ

Realm นำเสนอแนวทางที่ไม่เหมือนใครในการจัดการกับข้อมูลที่มีคุณค่าสำหรับนักพัฒนา ไม่เพียงเพราะมันเป็นตัวเลือกที่ดีกว่าโซลูชันที่มีอยู่ แต่ยังเพราะมันขยายขอบเขตอันไกลโพ้นของเราในแง่ของความเป็นไปได้ใหม่ๆ และยกระดับเทคโนโลยีฐานข้อมูลบนมือถือ

คุณมีประสบการณ์กับ Realm แล้วหรือยัง? โปรดอย่าลังเลที่จะแบ่งปันความคิดของคุณ