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

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

ตัวอย่างของแอปพลิเคชันคือ Amarok (เครื่องเล่นเพลงยอดนิยมบน Linux) ฉันไม่รู้ว่าพวกเขายังคงทำเช่นนี้หรือไม่ แต่ฉันจำได้ว่ามีเวลาที่การติดตั้ง Amarok หมายความว่าคุณต้องติดตั้งเซิร์ฟเวอร์ MySQL และให้มันทำงานในพื้นหลังตลอดเวลา

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

SQLite เสนอบทสรุปที่ดีเมื่อใช้หรือไม่กับทางเลือกอื่น:

https://www.sqlite.org/whentouse.html

บรรทัดสรุปนี้รวบรวมกรณีการใช้ SQLite อย่างมากในประสบการณ์ของฉัน:

SQLite ไม่แข่งขันกับฐานข้อมูลลูกค้า / เซิร์ฟเวอร์ SQLite แข่งขันกับ fopen ()

บทความขยายที่ความยาวในจุดนี้ นอกจากนี้ยังมีส่วนที่ชื่อ "สถานการณ์ที่ลูกค้า / เซิร์ฟเวอร์ RDBMS อาจทำงานได้ดีขึ้น" สรุปพวกเขาคือ:

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

แม้สำหรับระบบเดียวที่มีผู้ใช้คนเดียวเซิร์ฟเวอร์ฐานข้อมูล "ของจริง" ก็สมเหตุสมผล:

1. มันใช้ภาษาที่คุ้นเคย ( SQL ) SQLiteไม่ใช้ SQL แต่บางฐานข้อมูลที่ฝังตัว (เช่นวัตถุฐานข้อมูล , NoSQL ) ไม่ได้ใช้ SQL ผู้ที่มักจะมีช่วงการเรียนรู้ที่สูงขึ้นเพราะพวกเขาเป็นเรื่องธรรมดาน้อย
2. มันให้ความสมบูรณ์ของการอ้างอิงข้อ จำกัด ทริกเกอร์ ฯลฯ ว่าผลิตภัณฑ์เช่น SQLite อาจไม่ได้ให้หรืออย่างน้อยก็ไม่ได้ให้เต็ม
3. โดยการกำหนดเป้าหมายผู้ใช้หลายจริงกรดฐานข้อมูลเครือข่ายที่สอดคล้องกับโปรแกรมประยุกต์ที่มีตัวเลือกในการทำงานในผู้ใช้คนเดียว / สถานการณ์เวิร์กสเตชันเดียวหรือเป็นผู้ใช้หลายเจ้าภาพแอพลิเคชันโดยใช้codebase เดียวกัน
4. ผู้ใช้มีความสามารถในการตรวจสอบข้อมูลออฟไลน์โดยใช้เครื่องมือมาตรฐาน (เช่น SQL Developer, MySQL Workbench, SQL Server Management Studio), โหลดหรือสำรองข้อมูลโดยใช้เครื่องมือเหล่านั้น ฯลฯ ในขณะที่มันเป็นไปได้ที่จะทำเช่นนั้น ประเภทคนอาจคุ้นเคยกับเครื่องมือเหล่านั้นจากโลกของฐานข้อมูล C / S

ข้อเสียเปรียบหลักคือจำเป็นต้องติดตั้งและบำรุงรักษาซอฟต์แวร์เซิร์ฟเวอร์ฐานข้อมูลซึ่งค่อนข้างซับซ้อนสำหรับผู้ใช้ที่ไม่ใช้เทคนิค (และผู้ใช้ทางเทคนิคจำนวนมาก) ระบบปฏิบัติการเช่น Linux ทำให้ง่ายขึ้น: ฉันมี PostgreSQL และ MySQL ทำงานบนระบบ Linux ฉันได้ติดตั้งแอปพลิเคชั่นที่เชื่อมต่อกับพวกเขาโดยไม่มีการโต้ตอบกับส่วนของฉัน

ฉันคิดว่ามันเกี่ยวข้องกับความเฉื่อย

Amarok มาจาก XMMS ซึ่งมาจากปี 1997 เพื่อให้มีความสามารถในฐานข้อมูลที่ดีคุณต้องใช้เซิร์ฟเวอร์เพราะมันมีประสิทธิภาพมากกว่านั้นคือโซลูชันที่ใช้ไฟล์ซึ่งไม่มีความสามารถในฐานข้อมูลที่ดี

ความนิยมที่กำลังมาถึงและกำลังได้รับความนิยมของฐานข้อมูลแบบฝังในตัวที่ดีเช่น SQLlite เป็นสิ่งที่ค่อนข้างเร็ว

คุณลักษณะเหยียดที่สำคัญที่สุดคือการเห็นพ้อง

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

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

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

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

ฉันไม่รู้ว่าตัวอย่างที่ให้มาใช้ประโยชน์จากสิ่งนี้หรือไม่

ถ้าคุณใช้ระบบฝังตัวที่มีหน่วยความจำต่ำและ cpu ฉันไม่คิดว่าการใช้เซิร์ฟเวอร์บนพื้นหลังกำลังทำอันตรายคุณ

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

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

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

หากคุณต้องการให้แน่ใจว่าฐานข้อมูลที่รวมเข้ากับแอ็พพลิเคชันที่ไม่ต้องการการเข้าถึงจากแอพพลิเคชั่นอื่นให้สร้างเกาะของฐานข้อมูลแบบฝัง ตัวอย่างการใช้งาน Mozilla Firefox Web Storage พร้อม SQLite เป็นตัวอย่าง

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

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

สำหรับกรณี Amarok ฉันคิดว่ามันเป็นตัวเลือกของโอเพนซอร์ส DBMS ในเวลานั้นก่อนที่พวกเขาจะเลือกเส้นทางของฐานข้อมูลแบบฝัง

หากมีคำจำกัดความของระบบที่เฉพาะเจาะจงในมือของคุณมันจะง่ายต่อการเสียน้ำหนักและข้อดี

V / r, Umut