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

ฉันค้นหาบนเว็บวิธีการเข้าถึงอย่างมีประสิทธิภาพในฐานข้อมูลกลางที่สถานที่ห่างไกลและฉันได้พบกับข้อเสนอแนะในการใช้บริการเว็บแทนการเข้าถึงโดยตรง (เช่น JDBC เป็นต้น) ไปยังฐานข้อมูลฉันสงสัยว่าเหตุผลนั้นและคำแนะนำอื่น ๆ .

database android web-services

— yesildal
แหล่งที่มา

คำตอบ:

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

การใช้ CPU ให้น้อยลงจะช่วยเพิ่มอายุการใช้งานแบตเตอรี่
การใช้แบนด์วิดท์น้อยลงช่วยลดการชำระเงินรายเดือนสำหรับผู้ใช้ที่มีแผนแบบมิเตอร์

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

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

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

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

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

— dasblinkenlight
แหล่งที่มา

"ทั้งในแง่ของพลังงาน CPU ที่ต้องการและแบนด์วิดท์ที่ใช้ในระหว่างการประมวลผล" เป็นประเด็นสำคัญที่ฉันกำลังมองหาขอบคุณ

— yesildal

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

— Earlz

@Earlz: ไม่ใช่ว่าฉันจะทำเว็บแอพด้วยความเต็มใจ แต่เซิร์ฟเวอร์ฐานข้อมูลส่วนใหญ่มีสิทธิ์ที่ค่อนข้างแน่นหนา ไม่มีข้อแก้ตัวสำหรับผู้ใช้เว็บที่มีสิทธิ์ในการปล่อยตาราง

— ไวแอตต์บาร์เน็ตต์

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

— Earlz

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

— ไวแอตต์บาร์เน็ตต์

มันทำให้ชั้นของสิ่งที่เป็นนามธรรมระหว่างแอพและฐานข้อมูล สิ่งนี้ให้ประโยชน์มากมายเช่น:

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

— ระบบหยุดทำงาน
แหล่งที่มา

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

— TMN

@TMN - จุดดี!

— ระบบปิด

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

— ใช่

@yesildal - ใช่พวกเขายังคงใช้ได้ ในความเป็นจริงมันถูกต้องสำหรับการใช้งานทุกประเภท อย่างไรก็ตามในเว็บแอปคุณไม่จำเป็นต้องใช้บริการเว็บและสามารถแยกฟังก์ชั่นเหล่านี้ออกเป็นแอสเซมบลีของตัวเองได้ (เช่น) เหตุผลในการใช้บริการเว็บสำหรับแอพระยะไกล (เช่นแอพโทรศัพท์) คือเซิร์ฟเวอร์ DB ไม่ได้อยู่ใกล้

— ระบบดาวน์

@yesildal - ประสิทธิภาพการทำงาน: ไม่จริงถ้าคุณมี 1 ผู้ใช้แล้วใช่จะมีความล่าช้าเป็นพิเศษในการส่งคืนผลลัพธ์ แต่ถ้าคุณมีผู้ใช้นับล้านสิ่งที่แตกต่างกันและการแยกรหัสออกเป็น 2 เซิร์ฟเวอร์สามารถทำให้ ประสิทธิภาพโดยรวมเร็วขึ้น

— gbjbaanb

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

มีฐานข้อมูลที่ใหม่กว่าบางประเภทที่พูด HTTP และอาจเหมาะกับสิ่งเหล่านี้ พวกเขายังมีแนวโน้มที่จะมีวิธีการใส่รหัสแอปพลิเคชันแปลก ๆ ในฐานข้อมูล คุณอาจต้องการดู CouchDb หรือ RavenDb - ทั้งคู่เป็น dbs เอกสารที่มีความสามารถในแผนที่ / ลดความสามารถในการทำงานกับ json และ http เช่นเดียวกับบริการเว็บที่ทันสมัยมากมาย

— ไวแอตต์บาร์เน็ตต์
แหล่งที่มา