สถานที่ที่ดีที่สุดสำหรับการจัดเก็บภาพที่อัพโหลดฐานข้อมูล SQL หรือระบบไฟล์ดิสก์คืออะไร?

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

• จัดเก็บภาพเป็นไฟล์ในระบบไฟล์และสร้างบันทึกในตารางที่มีเส้นทางที่แน่นอนไปยังภาพนั้น

• หรือเก็บรูปภาพไว้ในตารางโดยใช้ชนิดข้อมูล "รูปภาพ" หรือ "ข้อมูลไบนารี" ของเซิร์ฟเวอร์ฐานข้อมูล

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

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

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

เกี่ยวกับความปลอดภัย - ฉันมักจะจัดเก็บไฟล์ในไดเรกทอรีที่อยู่นอกรูทเอกสาร (ไม่สามารถเข้าถึงได้ผ่านการร้องขอ http) และให้บริการผ่านสคริปต์ที่ตรวจสอบการอนุญาตที่เหมาะสมก่อน

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

นอกจากว่าคุณจะมีตัวพิมพ์เล็ก:

• ตรรกะทางธุรกิจอยู่ในรหัส
• ข้อมูลที่มีโครงสร้างอยู่ในฐานข้อมูล (สัมพันธ์หรือไม่สัมพันธ์)
• ข้อมูลจำนวนมากอยู่ในที่จัดเก็บข้อมูล (ระบบไฟล์หรืออื่น ๆ )

ไม่จำเป็นต้องใช้ระบบไฟล์เพื่อเก็บไฟล์ แต่คุณสามารถใช้ที่เก็บข้อมูลบนคลาวด์ (เช่นAmazon S3 ) หรือ Infrastructure-as-a-service ที่อยู่ด้านบน (เช่นUploadcare ):

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

แต่การจัดเก็บไฟล์ในฐานข้อมูลเป็นความคิดที่ไม่ดี

Flickr ใช้ระบบไฟล์ - พวกเขาหารือถึงเหตุผลที่นี่

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

วิธีอัปโหลดและเก็บรูปภาพหรือไฟล์ในเว็บไซต์ของเรา:

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

1. รูปภาพมาจากผู้ดูแลระบบสำหรับบล็อกแบบไดนามิก โดยทั่วไปแล้วรูปภาพเหล่านี้ได้รับการปรับให้เหมาะสมก่อนที่จะอัปโหลด

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

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

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

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

ตอนนี้เป็นเพียงชั่วคราว สำหรับการแก้ปัญหาขั้นสุดท้ายคำถามจะถูกทำซ้ำ:

• วิธีจัดการกับที่เก็บภาพขนาดใหญ่?
• ปรับขนาดหรือเปลี่ยนนามสกุล
• เว็บไซต์หรืออีคอมเมิร์ซขนาดใหญ่หรือขนาดกลางจัดการกับที่เก็บไฟล์สำหรับภาพของพวกเขาอย่างไร

เราจะทำอะไรได้บ้าง:

1. โอนย้ายจากการแชร์โฮสติ้ง VPS ไม่พอ? มากกว่านั้นโดยการอัปเกรดเป็น Dedicated

2. สร้างเซิร์ฟเวอร์ของคุณเองสำหรับจัดเก็บไฟล์ Googling ทำเช่นนั้น นี่ไม่ใช่เรื่องยากอย่างที่คุณคิด บางคนทำเพื่อเว็บไซต์ของพวกเขา

3. วิธีที่ง่ายคือใช้บริการจัดเก็บไฟล์ CDN

โอเค 1 และ 2 แพงไปหน่อย แต่ไม่มี 3 ฉันคิดว่าเป็นทางออกที่ดีที่สุด

บริการ CDN บางบริการอนุญาตให้คุณจัดเก็บไฟล์บนเว็บได้มากเท่าที่คุณต้องการ

คำถาม "วิธีอัปโหลดไฟล์ไปยัง CDN จากเว็บไซต์ของเรา"

ไม่ต้องกังวลเมื่อคุณลงทะเบียนฟรีคุณจะได้รับคำแนะนำวิธีอัปโหลดไฟล์และรับลิงก์จาก / ไปยังเว็บไซต์ของคุณ คุณจะได้รับ API และอีกมากมาย มันเป็นเรื่องง่าย.

ผู้ให้บริการบางรายให้บริการฟรี 14 วันกับพื้นที่จัดเก็บและแบนด์วิดท์ จำกัด แต่นั่นจะไม่เป็นไรสำหรับจุดเริ่มต้น ปัญหาเดียวก็คือเพราะ 'คนไม่เคยลอง'

หวังว่ามันจะช่วยให้มือใหม่

เรามีลูกค้ายืนยันในตัวเลือก B (ที่เก็บฐานข้อมูล) สองสามครั้งในแบ็กเอนด์ที่แตกต่างกันสองสามครั้งและเรามักจะกลับไปที่ตัวเลือก A (ที่เก็บข้อมูลระบบไฟล์) ในที่สุด

BLOB ขนาดใหญ่เช่นนั้นไม่ได้รับการจัดการที่ดีพอแม้แต่โดย SQL Server 2005 ซึ่งเป็นรุ่นล่าสุดที่เราลองใช้

โดยเฉพาะเราเห็นการขยายตัวที่รุนแรงและฉันคิดว่าอาจล็อคปัญหา

หมายเหตุอื่น ๆ : ถ้าคุณใช้ที่เก็บข้อมูลแบบ NTFS (เซิร์ฟเวอร์ windows ฯลฯ ) คุณอาจพิจารณาหาวิธีวางไฟล์หลายพันไฟล์ในไดเรกทอรีเดียว ฉันไม่แน่ใจว่าทำไม แต่บางครั้งระบบไฟล์ไม่สามารถรับมือกับสถานการณ์นั้นได้ดี หากใครรู้เพิ่มเติมเกี่ยวกับเรื่องนี้ฉันชอบที่จะได้ยินมัน

แต่ฉันมักจะพยายามใช้ไดเรกทอรีย่อยเพื่อแยกสิ่งเล็กน้อย วันที่สร้างมักจะทำงานได้ดีสำหรับสิ่งนี้:

images / 2008/12/17 / .jpg

... สิ่งนี้มีระดับการแยกที่เหมาะสมและช่วยเล็กน้อยในระหว่างการดีบัก ไคลเอนต์ Explorer และ FTP เหมือนกันสามารถทำให้หายใจไม่ออกเมื่อมีไดเรกทอรีขนาดใหญ่อย่างแท้จริง

แก้ไข:เพียงแค่บันทึกย่อสำหรับปี 2017 ใน SQL Server รุ่นล่าสุดมีตัวเลือกใหม่สำหรับการจัดการ BLOB จำนวนมากที่ควรหลีกเลี่ยงข้อเสียที่ฉันกล่าวถึง

แก้ไข:บันทึกย่อในปี 2020 Blob Storage ใน AWS / Azure / etc ก็เป็นตัวเลือกสำหรับปีนี้เช่นกัน สิ่งนี้เหมาะอย่างยิ่งสำหรับโครงการบนเว็บจำนวนมากเนื่องจากราคาถูกและมักจะทำให้ปัญหาบางอย่างง่ายขึ้นเกี่ยวกับการปรับใช้การปรับขนาดไปยังเซิร์ฟเวอร์หลายเครื่องการดีบักสภาพแวดล้อมอื่น ๆ เมื่อจำเป็นเป็นต้น

ฉันเพิ่งสร้างแอพ PHP / MySQL ที่เก็บไฟล์ PDF / Word ไว้ในตาราง MySQL (ใหญ่เป็น 40MB ต่อไฟล์จนถึงตอนนี้)

ข้อดี:

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

จุดด้อย:

• mysqldump ใช้เวลา looooong เนื่องจากมีข้อมูลไฟล์ 500MB ในตารางใดตารางหนึ่ง
• โดยรวมแล้วหน่วยความจำ / ซีพียูไม่ค่อยมีประสิทธิภาพเมื่อเปรียบเทียบกับระบบไฟล์

ฉันจะเรียกใช้การประสบความสำเร็จของฉันมันจะดูแลข้อกำหนดการสำรองข้อมูลและทำให้เค้าโครงของโครงการง่ายขึ้น ประสิทธิภาพดีสำหรับผู้ใช้งานแอป 20-30 คน

ฉันใช้ภาพที่อัปโหลดบนเว็บไซต์ของฉันและฉันจะบอกว่าตัวเลือกก)

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

นอกจากนี้ยังช่วยตัดชื่อไฟล์ของผู้ใช้อักขระแปลก ๆ เพื่อหลีกเลี่ยงภาวะแทรกซ้อนในอนาคต

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

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

มีวิธีการไฮบริดใน SQL Server 2008 ที่เรียกว่าประเภทข้อมูล filestreamที่ถูกกล่าวถึงในRunAs Radio # 74ซึ่งเป็นประเภทที่ดีที่สุดของทั้งสองโลก คนส่วนใหญ่ไม่มี otion 2008 แต่ถ้าคุณทำตัวเลือกนี้ดูดีมาก

นี่เป็นพื้นฐานที่ฉันทำ

1. จัดเก็บภาพที่อัปโหลดไว้ในไดเรกทอรีชั่วคราวหรือหน่วยความจำ
2. ประมวลผลภาพนั้นก่อนเก็บไว้อย่างถาวร 2.1 การแก้ไขสี 2.2 บีบอัด 2.3 สร้างสำเนาหลายชุดตามขนาดภาพ 2.4 เปลี่ยนชื่อด้วยคำต่อท้าย. xl, .lg, .md, .sm ฯลฯ
3. แพ็คไฟล์ภาพที่ประมวลผลทั้งหมด (จากไฟล์เดียว) ภายในโฟลเดอร์ที่มีชื่อโฟลเดอร์idซึ่งจะถูกเก็บไว้ในฐานข้อมูลสำหรับแถว / เอกสารใด ๆ พร้อมกับimage file name(หรืออาจเป็นชื่อแบบสุ่มเป็นชื่อรูปภาพ)
4. สร้างโฟลเดอร์yyyy / mm / d pathหากไม่มีอยู่ ตัวอย่างเช่น 2016/08/21 จำเส้นทางนั้นและเก็บไว้ในฐานข้อมูลสำหรับเอกสารและแถวเดียวกัน
5. ย้ายidโฟลเดอร์รูปภาพไปยังpathโฟลเดอร์ (โฟลเดอร์เส้นทางอาจอยู่ใน / var / โฟลเดอร์เนื้อหาของเว็บ)
6. ล้างบัฟเฟอร์หน่วยความจำหรือลบไฟล์ชั่วคราว

เมื่อคุณต้องการเข้าถึงภาพใด ๆ ที่กล่าวถึงในเอกสารคุณมีเส้นทางและรหัสของโฟลเดอร์มากกว่าที่มีภาพ ตัวอย่างเช่น/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg

วิธีนี้ถ้าคุณต้องลบไฟล์ภาพที่ประมวลผลทั้งหมดเพียงแค่ลบโฟลเดอร์และเนื้อหาซ้ำ

การใช้งานส่วนใหญ่เป็นตัวเลือก A.

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

ฉันไม่คิดว่าพื้นที่ว่างมีปัญหามากเกินไป ... ไดรฟ์เทราไบต์เป็นสองร้อยเหรียญในขณะนี้

เรากำลังดำเนินการกับตัวเลือก A เนื่องจากเราไม่มีเวลาหรือทรัพยากรที่จะทำตัวเลือก B

สำหรับการปรับขนาดอัตโนมัติลองใช้ imagemagick ... มันถูกใช้สำหรับระบบจัดการเนื้อหา / รูปถ่ายโอเพ่นซอร์สที่สำคัญหลายแห่ง ... และฉันเชื่อว่ามีส่วนขยาย. net บางส่วน

เราใช้ A. ฉันจะวางไว้ในไดรฟ์ที่ใช้ร่วมกัน (ยกเว้นว่าคุณไม่ได้วางแผนที่จะใช้เซิร์ฟเวอร์มากกว่าหนึ่งเครื่อง)

หากเวลานั้นมาถึงเมื่อสิ่งนี้ไม่ได้ปรับขนาดให้คุณคุณสามารถตรวจสอบกลไกการแคชได้

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

ข้อได้เปรียบอีกประการหนึ่งคือการสำรองข้อมูล / จำลองแบบฐานข้อมูลของคุณจะน่ากลัว

ตัวเลือก A.

เมื่อโหลดภาพแล้วคุณสามารถตรวจสอบรูปแบบและปรับขนาดก่อนบันทึกได้ มีจำนวนของตัวอย่างโค้ดสุทธิเพื่อปรับขนาดภาพบนhttp://www.codeproject.com ตัวอย่างเช่น: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

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

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

ฉันหวังว่านี่จะช่วยคุณได้

หากเป็นไฟล์ขนาดเล็กที่ไม่จำเป็นต้องแก้ไขตัวเลือก B ไม่ใช่ตัวเลือกที่ไม่ดี ฉันชอบสิ่งนี้เพื่อเขียนตรรกะเพื่อจัดเก็บไฟล์และจัดการกับปัญหาโครงสร้างไดเรกทอรีที่บ้าคลั่ง การมีไฟล์จำนวนมากในไดเรกทอรีเดียวนั้นไม่ดี Emkay?

หากไฟล์มีขนาดใหญ่หรือต้องมีการแก้ไขอย่างต่อเนื่องโดยเฉพาะจากโปรแกรมเช่น office ตัวเลือก A คือทางออกที่ดีที่สุดของคุณ

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

ขึ้นอยู่กับข้อกำหนดของคุณปริมาณพิเศษผู้ใช้และความถี่ในการค้นหา แต่สำหรับสำนักงานขนาดเล็กหรือขนาดกลางทางเลือกที่ดีที่สุดคือการใช้แอปพลิเคชั่นเช่น Apple Photos หรือ Adobe Lighroom พวกเขามีความเชี่ยวชาญในการจัดเก็บแคตตาล็อกดัชนีและจัดการทรัพยากรประเภทนี้ แต่สำหรับองค์กรขนาดใหญ่ที่มีความต้องการด้านการจัดเก็บที่แข็งแกร่งและผู้ใช้จำนวนมากขอแนะนำให้ยกตัวอย่างการจัดการเนื้อหาด้วย Digital Asset Management เช่น Nuxeo หรือ Alfresco ทั้งสองมีทรัพยากรที่ดีมากจัดการปริมาณข้อมูลจำนวนมากด้วยวิธีที่ง่ายขึ้นเพื่อเรียกคืน และที่สำคัญมาก: มีตัวเลือกฟรี (โอเพ่นซอร์ส) สำหรับทั้งสองแพลตฟอร์ม