นับตั้งแต่สร้าง Android ขึ้นเรานักพัฒนาแอปได้ใช้ SQLite เพื่อจัดเก็บข้อมูลในเครื่องของเรา บางครั้งใช้คำสั่ง SQL โดยตรงบางครั้งใช้ Object-Relational Mapper (ORM) เป็นเลเยอร์นามธรรม แต่ไม่ว่าจะด้วยวิธีใดเราได้ใช้ SQLite ในตอนท้ายของวัน
แม้จะมีข้อดีทั้งหมดของ SQLite แต่ก็มีหลายครั้งที่เราต้องการให้เรามีทางเลือกอื่นสำหรับโมเดลเชิงสัมพันธ์: สิ่งที่สามารถช่วยเราไม่ให้ต้องเพิ่มโค้ดสำเร็จรูปเพื่อแปลงค่าไปและกลับจากฐานข้อมูลหรือทำให้เราสามารถข้ามการตั้งค่าการแมปได้ ระหว่างคลาสและตารางฟิลด์และคอลัมน์คีย์ต่างประเทศ ฯลฯ
กล่าวอีกนัยหนึ่งคือฐานข้อมูลที่มีโครงสร้างข้อมูลคล้ายกับที่เราใช้จริงในระดับแอปพลิเคชัน ยังดีกว่าถ้ามันอาจเป็นหน่วยความจำที่มีประสิทธิภาพโดยการออกแบบทำให้ได้รับประสบการณ์ที่ดีขึ้นในอุปกรณ์ที่มีข้อ จำกัด ด้านทรัพยากรนั่นจะยอดเยี่ยมมาก
อันที่จริงแล้วสิ่งเหล่านี้คือประโยชน์บางประการที่เราได้รับจากกล่อง อาณาจักร ซึ่งเป็นแพลตฟอร์มฐานข้อมูลที่มีสถาปัตยกรรมที่แตกต่างกันซึ่งได้กลายมาเป็นทางเลือกใหม่สำหรับ SQLite
บทความนี้นำเสนอสาเหตุหลักบางประการที่ทำให้ Realm ได้รับความสนใจเป็นอย่างมากและทำไมคุณอาจต้องการลองใช้ เนื้อหานี้กล่าวถึงข้อดีที่สำคัญบางประการที่ Realm มอบให้ นักพัฒนา Android บน SQLite
เนื่องจาก Realm มีให้บริการในหลายแพลตฟอร์มสิ่งที่จะกล่าวถึงในบทความนี้จึงมีความเกี่ยวข้องกับแพลตฟอร์มมือถืออื่น ๆ ด้วยเช่น iOS , Xamarin และ React Native
นักพัฒนาอุปกรณ์เคลื่อนที่ส่วนใหญ่อาจคุ้นเคยกับ SQLite มีมาตั้งแต่ปี 2000 และเป็นเนื้อหาของ ใช้มากที่สุด เครื่องมือฐานข้อมูลเชิงสัมพันธ์ในโลก
SQLite มีประโยชน์หลายประการที่เราทุกคนรับทราบซึ่งหนึ่งในนั้นคือการสนับสนุนดั้งเดิมบน Android
ความจริงที่ว่ามันเป็นฐานข้อมูลเชิงสัมพันธ์ SQL มาตรฐานยังช่วยลดเส้นโค้งการเรียนรู้สำหรับผู้ที่มาจากพื้นหลังฐานข้อมูลเชิงสัมพันธ์ นอกจากนี้ยังให้ประสิทธิภาพที่ดีพอสมควรหากใช้อย่างเต็มศักยภาพ (ใช้ประโยชน์จากคุณสมบัติเช่นงบที่เตรียมไว้การดำเนินการกับธุรกรรมจำนวนมาก ฯลฯ ) แม้ว่า SQLite อาจปรับขนาดได้ไม่ดีนักสำหรับทุกความต้องการของคุณ
การจัดการโดยตรงกับคำสั่ง SQL มีข้อเสียอยู่หลายประการ
ให้เป็นไปตาม เอกสารอย่างเป็นทางการของ Android ต่อไปนี้เป็นขั้นตอนที่จำเป็นในการเริ่มอ่าน / เขียนไปยัง SQLite:
SQLiteOpenHelper
เพื่อเรียกใช้สร้างคำสั่งและจัดการการอัปเกรด / ดาวน์เกรดเมื่อคุณทำเสร็จแล้วคุณก็พร้อมที่จะอ่านและเขียนลงในฐานข้อมูลของคุณ อย่างไรก็ตามคุณจะต้องแปลงไปมาระหว่างวัตถุในแอปพลิเคชันของคุณและค่าในฐานข้อมูล เรื่องสั้นขนาดยาว: มีโค้ดสำเร็จรูปมากมาย!
อีกประเด็นหนึ่งคือการบำรุงรักษา เมื่อโปรเจ็กต์ของคุณมีขนาดใหญ่ขึ้นและจำเป็นต้องเขียนแบบสอบถามที่ซับซ้อนมากขึ้นคุณจะพบกับคิวรี SQL ดิบจำนวนมากในสตริง หากในภายหลังคุณจำเป็นต้องเปลี่ยนตรรกะของข้อความค้นหาเหล่านั้นอาจเป็นเรื่องยุ่งยาก
แม้จะมีข้อเสีย แต่ก็มีบางกรณีที่การใช้ SQL ดิบเป็นตัวเลือกที่ดีที่สุดของคุณ ตัวอย่างหนึ่งคือเมื่อคุณกำลังพัฒนาไลบรารีซึ่งประสิทธิภาพและขนาดเป็นปัจจัยสำคัญและควรหลีกเลี่ยงการเพิ่มไลบรารีของบุคคลที่สามหากเป็นไปได้
เพื่อช่วยเราจากการจัดการกับ SQL ดิบ ORM จึงเข้ามาช่วย
ORM Android ที่มีชื่อเสียงที่สุดบางตัว ได้แก่ DBFlow , เขียวดาว และ 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 ดังนั้นปัจจุบันจึงมีอายุ 2 ปีครึ่ง (ใหม่มาก!)
ในขณะที่เทคโนโลยีฐานข้อมูลเซิร์ฟเวอร์กำลังเกิดการปฏิวัติตั้งแต่ปี 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 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
เพื่อสร้างแบบจำลองความสัมพันธ์
ช่องสามารถมีระดับการเข้าถึงใดก็ได้ (ส่วนตัวสาธารณะป้องกัน ฯลฯ ) ช่องทั้งหมดจะคงอยู่โดยค่าเริ่มต้นและคุณเพียงแค่ต้องใส่คำอธิบายประกอบช่อง 'พิเศษ' (เช่น @PrimaryKey
สำหรับฟิลด์คีย์หลักของคุณ @Ignore
เพื่อตั้งค่าฟิลด์ที่ไม่อยู่ต่อไป ฯลฯ )
สิ่งที่น่าสนใจเกี่ยวกับแนวทางนี้คือทำให้ชั้นเรียนมี 'คำอธิบายประกอบที่เป็นมลพิษ' น้อยลงเมื่อเทียบกับ ORM เนื่องจากส่วนใหญ่คุณต้องใช้คำอธิบายประกอบเพื่อแมปชั้นเรียนกับตารางช่องปกติไปยังคอลัมน์ฐานข้อมูลช่องคีย์นอกไปยังตารางอื่น ๆ เป็นต้น บน.
ปัญญาประดิษฐ์กับเศรษฐกิจ
เมื่อพูดถึงความสัมพันธ์มีสองทางเลือก:
เพิ่มโมเดลเป็นฟิลด์จากโมเดลอื่น ในตัวอย่างของเรา Contact
คลาสประกอบด้วย Address
ฟิลด์และกำหนดความสัมพันธ์ของพวกเขา ผู้ติดต่ออาจมีที่อยู่ แต่ไม่มีสิ่งใดหยุดไม่ให้เพิ่มที่อยู่เดียวกันนี้ไปยังรายชื่อติดต่ออื่น ๆ ที่อนุญาตให้มีความสัมพันธ์แบบหนึ่งต่อหนึ่งและหนึ่งต่อหลาย
เพิ่ม RealmList
ของโมเดลที่อ้างอิง RealmLists
ทำตัวเหมือน Java เก่า ๆ Lists
ทำหน้าที่เป็นคอนเทนเนอร์ของวัตถุ Realm เราจะเห็นว่า Contact
ของเรา โมเดลมี RealmList
ของผู้ติดต่อซึ่งเป็นเพื่อนของเธอในตัวอย่างนี้ ความสัมพันธ์แบบหนึ่งต่อกลุ่มและแบบกลุ่มต่อกลุ่มสามารถจำลองได้ด้วยวิธีนี้
ฉันชอบวิธีการแสดงความสัมพันธ์แบบนี้เพราะรู้สึกเป็นธรรมชาติมากสำหรับพวกเรานักพัฒนา Java การเพิ่มวัตถุเหล่านี้ (หรือรายการของวัตถุเหล่านี้) โดยตรงเป็นช่องของชั้นเรียนของเราเช่นเดียวกับที่เราทำกับคลาสอื่น ๆ ที่ไม่ใช่โมเดลเราไม่จำเป็นต้องจัดการกับการตั้งค่า SQLite สำหรับคีย์ต่างประเทศ
ข้อแม้: ไม่มีการสนับสนุนการสืบทอดโมเดล วิธีแก้ปัญหาในปัจจุบันคือการใช้องค์ประกอบ ตัวอย่างเช่นหากคุณมี Animal
และหวังว่าจะสร้าง Dog
รูปแบบขยายจาก Animal
คุณจะต้องเพิ่ม Animal
อินสแตนซ์เป็นฟิลด์ใน Dog
มีการถกเถียงกันอย่างมากเกี่ยวกับองค์ประกอบเทียบกับมรดก หากคุณกำลังใช้การสืบทอดนี่เป็นสิ่งที่คุณต้องรู้เกี่ยวกับ Realm ด้วย SQLite สิ่งนี้สามารถใช้งานได้โดยใช้สองตาราง (หนึ่งตารางสำหรับพาเรนต์และอีกตารางสำหรับเด็ก) ที่เชื่อมต่อด้วยคีย์นอก ORM บางรายการไม่ได้กำหนดข้อ จำกัด นี้เช่น DBFlow
นี่คือคุณสมบัติของนักฆ่า
Realm ใช้แนวคิดของการออกแบบศูนย์สำเนาซึ่งหมายความว่าข้อมูลจะไม่ถูกคัดลอกไปยังหน่วยความจำ ผลลัพธ์ที่คุณได้รับจากแบบสอบถามเป็นเพียงตัวชี้ไปยังข้อมูลจริง ข้อมูลเองจะถูกโหลดอย่างเกียจคร้านเมื่อคุณเข้าถึง
ตัวอย่างเช่นคุณมีโมเดลที่มี 10 ฟิลด์ (คอลัมน์ใน SQL) หากคุณค้นหาออบเจ็กต์ของโมเดลนี้เพื่อแสดงรายการบนหน้าจอและคุณต้องการเพียงสามจาก 10 ฟิลด์เพื่อเติมเต็มรายการสิ่งเหล่านี้จะเป็นฟิลด์เดียวที่ถูกเรียก
ด้วยเหตุนี้การสืบค้นจึงรวดเร็วอย่างเห็นได้ชัด (ดู ที่นี่ และ ที่นี่ สำหรับผลการเปรียบเทียบ)
นี่เป็นข้อได้เปรียบที่ยิ่งใหญ่เหนือ ORM ซึ่งโดยปกติจะโหลดข้อมูลทั้งหมดจากแถว SQL ที่เลือกไว้ล่วงหน้า
การโหลดหน้าจอจะมีประสิทธิภาพมากขึ้นอย่างมากโดยไม่ต้องใช้ความพยายามใด ๆ จากนักพัฒนาเพิ่มเติมนั่นเป็นเพียงพฤติกรรมเริ่มต้นของ Realm
นอกจากนี้ยังหมายความว่าแอปใช้หน่วยความจำน้อยลงและเนื่องจากเรากำลังพูดถึงสภาพแวดล้อมที่ จำกัด ทรัพยากรเช่นอุปกรณ์เคลื่อนที่ซึ่งสามารถสร้างความแตกต่างได้มาก
ผลที่ตามมาอีกประการหนึ่งของวิธีการคัดลอกเป็นศูนย์คือวัตถุที่จัดการโดย Realm จะได้รับการอัปเดตโดยอัตโนมัติ
ข้อมูลจะไม่ถูกคัดลอกไปยังหน่วยความจำ หากคุณมีผลลัพธ์จากแบบสอบถามและเธรดอื่นได้อัปเดตข้อมูลนี้บนฐานข้อมูลหลังจากการสืบค้นของคุณผลลัพธ์ที่คุณมีจะแสดงถึงการเปลี่ยนแปลงเหล่านี้แล้ว ผลลัพธ์ของคุณเป็นเพียงตัวชี้ไปยังข้อมูลจริงเท่านั้น ดังนั้นเมื่อคุณเข้าถึงค่าจากฟิลด์ข้อมูลที่เป็นปัจจุบันที่สุดจะถูกส่งกลับ
หากคุณได้อ่านข้อมูลจากวัตถุ Realm แล้วและแสดงข้อมูลเหล่านี้บนหน้าจอและต้องการรับการอัปเดตเมื่อข้อมูลพื้นฐานเปลี่ยนแปลงคุณสามารถเพิ่มผู้ฟังได้:
final RealmResults johns = realm.where(Contact.class).beginsWith('name', 'John ').findAll(); johns.addChangeListener(new RealmChangeListener() { @Override public void onChange(RealmResults results) { // UPDATE UI } });
แม้ว่าเราจะมีตัวเลือกมากมายสำหรับ ORM แต่ก็เป็นเครื่องห่อหุ้มและทั้งหมดลงมาที่ SQLite ด้านล่างซึ่งจะ จำกัด ว่าจะไปได้ไกลแค่ไหน ในทางตรงกันข้าม Realm ไม่ได้เป็นเพียงตัวห่อ SQLite อื่น มีอิสระในการนำเสนอคุณลักษณะที่ ORM ไม่สามารถนำเสนอได้
การเปลี่ยนแปลงพื้นฐานอย่างหนึ่งของ Realm คือความสามารถในการจัดเก็บข้อมูลเป็นที่เก็บกราฟวัตถุ
ซึ่งหมายความว่า Realm คือออบเจ็กต์ตั้งแต่ระดับภาษาโปรแกรมไปจนถึงฐานข้อมูล ดังนั้นจึงมีการแปลงกลับไปกลับมาน้อยลงเมื่อคุณเขียนและอ่านค่าเมื่อเปรียบเทียบกับฐานข้อมูลเชิงสัมพันธ์
โครงสร้างฐานข้อมูลสะท้อนถึงโครงสร้างข้อมูลที่ใกล้ชิดมากขึ้นที่นักพัฒนาแอปพลิเคชันใช้ อันที่จริงนี่เป็นสาเหตุสำคัญประการหนึ่งที่ทำให้มีการเคลื่อนตัวออกจากการสร้างแบบจำลองเชิงสัมพันธ์และไปสู่โมเดลรวมในการพัฒนาฝั่งเซิร์ฟเวอร์ ในที่สุด Realm ก็นำแนวคิดเหล่านี้มาสู่โลกแห่งการพัฒนาอุปกรณ์เคลื่อนที่
หากเรานึกถึงส่วนประกอบในสถาปัตยกรรมของ Realm ที่ด้านล่างสุดจะเป็นแกนหลักของการใช้งานแพลตฟอร์มที่เป็นพื้นฐานที่สุด ยิ่งไปกว่านั้นเราจะมีไลบรารีที่เชื่อมโยงกับแต่ละแพลตฟอร์มที่รองรับ
เมื่อใช้กระดาษห่อหุ้มสำหรับเทคโนโลยีบางอย่างคุณไม่สามารถควบคุมได้ในที่สุดคุณจะต้องจัดเตรียมเลเยอร์นามธรรมไว้รอบ ๆ
ขอบเขตการผูกขอบเขตถูกออกแบบมาให้บางที่สุดเพื่อตัดความซับซ้อนของนามธรรมออกไป ส่วนใหญ่เผยแพร่แนวคิดการออกแบบจาก Core ด้วยการควบคุมสถาปัตยกรรมทั้งหมดส่วนประกอบเหล่านี้จึงทำงานร่วมกันได้ดีขึ้น
ตัวอย่างที่ใช้ได้จริงอย่างหนึ่งคือการเข้าถึงอ็อบเจ็กต์อื่น ๆ ที่อ้างอิง (คีย์ต่างประเทศใน SQL) โครงสร้างไฟล์ของ Realm ขึ้นอยู่กับลิงก์เนทีฟดังนั้นเมื่อคุณค้นหาความสัมพันธ์แทนที่จะต้องแปลสิ่งที่เป็นนามธรรม ORM เป็นเชิงสัมพันธ์และ / หรือเข้าร่วมหลายตารางคุณจะได้รับลิงก์ดิบไปยังออบเจ็กต์ในระดับระบบไฟล์ในรูปแบบไฟล์
นั่นคือวัตถุที่ชี้ไปยังวัตถุอื่น ๆ โดยตรง ดังนั้นการสอบถามความสัมพันธ์จึงเหมือนกับการสืบค้นคอลัมน์จำนวนเต็มเป็นต้น ไม่จำเป็นต้องดำเนินการราคาแพงในการข้ามคีย์ต่างประเทศ ทุกอย่างเกี่ยวกับคำแนะนำต่อไปนี้
Realm อยู่ระหว่างการพัฒนาและมีการปล่อยเวอร์ชันอัปเดตบ่อยครั้ง
ส่วนประกอบทั้งหมดจาก Realm Mobile Database คือ โอเพ่นซอร์ส . พวกเขาตอบสนองได้ดีมาก ติดตามปัญหา และ Stack Overflow ดังนั้นคุณสามารถคาดหวังการสนับสนุนที่ดีและรวดเร็วสำหรับช่องเหล่านี้
นอกจากนี้ข้อเสนอแนะจากชุมชนจะถูกนำมาพิจารณาเมื่อจัดลำดับความสำคัญของปัญหา (ข้อบกพร่องการปรับปรุงการร้องขอคุณสมบัติ ฯลฯ ) เป็นเรื่องดีเสมอที่ทราบว่าคุณสามารถมีส่วนร่วมในการพัฒนาเครื่องมือที่คุณใช้
ฉันเริ่มใช้ Realm ในปี 2015 และตั้งแต่นั้นมาฉันก็ได้พบกับโพสต์ต่างๆบนเว็บพร้อมกับความคิดเห็นที่หลากหลายเกี่ยวกับ Realm เราจะพูดถึงข้อ จำกัด ในเร็ว ๆ นี้ แต่สิ่งหนึ่งที่ฉันสังเกตเห็นก็คือการร้องเรียนจำนวนมากในขณะที่โพสต์ได้รับการแก้ไขแล้ว
ตัวอย่างเช่นเมื่อฉันได้รับทราบเกี่ยวกับ Realm ยังไม่มีการสนับสนุนสำหรับวิธีการที่กำหนดเองในแบบจำลองและการโทรแบบอะซิงโครนัส สิ่งเหล่านี้เป็นตัวแบ่งข้อตกลงสำหรับหลาย ๆ คนในเวลานั้น แต่ปัจจุบันทั้งสองได้รับการสนับสนุน
ความเร็วในการพัฒนาและการตอบสนองดังกล่าวทำให้เรามั่นใจมากขึ้นว่าเราจะไม่รอนานสำหรับคุณสมบัติที่สำคัญ
เช่นเดียวกับทุกสิ่งในชีวิต Realm ไม่ใช่กุหลาบทั้งหมด นอกเหนือจากข้อ จำกัด ด้านมรดกที่กล่าวไว้ก่อนหน้านี้ยังมีข้อบกพร่องอื่น ๆ ที่ต้องคำนึงถึง:
แม้ว่าจะเป็นไปได้ที่จะมีหลายเธรดที่อ่านและเขียนไปยังฐานข้อมูลในเวลาเดียวกัน ไม่สามารถย้ายวัตถุขอบเขตข้ามเธรดได้ . ตัวอย่างเช่นหากคุณดึงวัตถุขอบเขตโดยใช้ doInBackground()
ของ AsyncTask ซึ่งทำงานในเธรดพื้นหลังคุณจะไม่สามารถส่งอินสแตนซ์นี้ไปยัง onPostExecute()
วิธีการเนื่องจากสิ่งเหล่านี้ทำงานบนเธรดหลัก วิธีแก้ปัญหาที่เป็นไปได้สำหรับสถานการณ์นี้คือการทำสำเนาของออบเจ็กต์แล้วส่งต่อหรือส่งรหัสของอ็อบเจ็กต์และเรียกข้อมูลอีกครั้งบน onPostExecute()
Realm เสนอวิธีการซิงโครนัสและอะซิงโครนัสสำหรับการอ่าน / เขียน
มี ไม่รองรับคีย์หลักแบบเพิ่มอัตโนมัติ ดังนั้นคุณจะต้องจัดการกับคนรุ่นนี้ด้วยตัวคุณเอง
มันคือ ไม่สามารถเข้าถึงฐานข้อมูลจากกระบวนการที่แตกต่างกันในเวลาเดียวกัน . ตามเอกสารของพวกเขาการสนับสนุนแบบหลายกระบวนการกำลังจะมาเร็ว ๆ นี้
SQLite เป็นเอ็นจิ้นฐานข้อมูลที่มั่นคงแข็งแกร่งและได้รับการพิสูจน์แล้วและฐานข้อมูลเชิงสัมพันธ์จะไม่หายไปในเร็ว ๆ นี้ มี ORM ดีๆมากมายที่จะทำเคล็ดลับสำหรับหลาย ๆ สถานการณ์เช่นกัน
อย่างไรก็ตามสิ่งสำคัญคือต้องติดตามแนวโน้มปัจจุบันอยู่เสมอ
ในเรื่องนี้ฉันคิดว่า Realm เป็นหนึ่งในเทรนด์ที่กำลังจะเกิดขึ้นในช่วงไม่กี่ปีที่ผ่านมาเมื่อพูดถึงการพัฒนาฐานข้อมูลมือถือ
Realm นำเสนอวิธีการที่ไม่เหมือนใครในการจัดการกับข้อมูลที่มีคุณค่าต่อนักพัฒนาไม่เพียงเพราะมันอาจเป็นตัวเลือกที่ดีกว่าโซลูชันที่มีอยู่ แต่ยังช่วยขยายขอบเขตของเราในแง่ของความเป็นไปได้ใหม่ ๆ และเพิ่มขีดความสามารถของเทคโนโลยีฐานข้อมูลมือถือ
คุณมีประสบการณ์กับ Realm แล้วหรือยัง? โปรดอย่าลังเลที่จะแบ่งปันความคิดของคุณ