มันเป็นวิธีปฏิบัติที่ไม่ถูกต้องหรือไม่ในการจัดเก็บข้อมูลเมตาดาต้าในชื่อไฟล์? ทางออกที่ดีกว่า


13

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

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

ถือว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่?

โซลูชั่นอื่น ๆ ที่ได้รับการยอมรับสำหรับการดึงไฟล์จากระบบไฟล์โดยยึดตามข้อมูลเมตาบางประเภทคืออะไร?


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

คำตอบ:


14

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

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

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


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

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

1
@wobbily_col ขึ้นอยู่กับระบบที่คุณใช้อาจจะมีการสนับสนุนสำหรับไฟล์ขยายแอตทริบิวต์ใช้ได้
Hellion

@AxelKemper มีข้อมูลมากมายที่คุณสามารถใส่ชื่อได้ มีข้อมูลเมตามากกว่าชื่อและผู้แต่ง
Tulains Córdova

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

5

อย่างแรกเมตาดาต้าคือแนวคิดที่พร่ามัว

ที่กล่าวมาหลายกรณีของข้อมูลเมตาในไฟล์มีอยู่แล้ว:

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

อย่างไรก็ตามรายการสั้นนั้นไม่ได้เป็นข้อโต้แย้งในทางปฏิบัติ

ทางเลือกคือ:

  • จัดการข้อมูลเมตาในระดับ FS เช่น HFS เก่าของ Apple เป็นต้น
  • ใส่ข้อมูลเมตาลงในไฟล์เช่น Exif สำหรับภาพหรือ ID3 สำหรับเสียง
  • ใส่ข้อมูลเมตาในไฟล์อื่นหรือในฐานข้อมูลเช่นผู้จัดการสื่อส่วนใหญ่

5
ทุกอย่างเป็นแนวคิดที่พร่ามัว แม้แต่ "พร่ามัว", "แนวคิด" และ "ทุกอย่าง" ก็เป็นแนวคิดที่พร่ามัว
Tulains Córdova

3

ดูเหมือนว่าคุณต้องการฐานข้อมูล

มีปัญหาด้านความปลอดภัยมากมายในการใส่ข้อมูลผู้ใช้ในชื่อไฟล์ สมมติว่าคุณมีไฟล์สำหรับผู้ใช้แต่ละคน ("username.txt") เกิดอะไรขึ้นกับสิ่งที่บางคนลงทะเบียนชื่อผู้ใช้ "../../../../etc/passwd" ขึ้นอยู่กับว่าคุณกรองข้อมูลของผู้ใช้อย่างไร

กรอบงานฐานข้อมูลบางครั้งจะช่วยคุณในการฆ่าเชื้ออินพุตของผู้ใช้


อันที่จริงระบบปฏิบัติการจำนวนมากจัดเก็บชื่อผู้ใช้ชื่อไดเรกทอรีซึ่งเรียกว่าไดเรกทอรีบ้าน
mouviciel

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

1
@mouviciel ฉันไม่ทราบว่าระบบปฏิบัติการใดที่แยกวิเคราะห์ชื่อผู้ใช้ออกจากชื่อโฮมไดเรกทอรีของผู้ใช้ ทั้งระบบ Windows และ Unix จะเก็บชื่อของไดเรกทอรีในฐานข้อมูลบางประเภทและโหลดเข้าสู่สภาพแวดล้อมเมื่อผู้ใช้ลงชื่อเข้าใช้ภายใต้ระบบทั้งสองคุณสามารถจบลงด้วยชื่อไดเรกทอรีบ้านที่แตกต่างกับชื่อผู้ใช้ ( เช่นการเปลี่ยนชื่อผู้ใช้หรือคุณมีสองหน้าต่างติดตั้งในพาร์ติชันระบบเดียวกัน)
จูลส์

2

ไม่ ... ไม่จำเป็น

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

ยกตัวอย่างระบบการจัดการบรรจุภัณฑ์และการพึ่งพา (Maven, NuGet และไลค์) แม้ว่าหลายคนจะใช้ไฟล์เฉพาะสำหรับข้อมูลเมตาเพื่อจัดเก็บข้อมูลขั้นสูง แต่ข้อมูลพื้นฐานมักเป็นส่วนหนึ่งของชื่อไฟล์เอง การใช้ข้อตกลงที่เข้มงวดชื่อไฟล์สามารถมีข้อมูลที่เกี่ยวข้องมากที่สุดเกี่ยวกับแพคเกจ: มันเป็นผู้ขายมันเป็นชื่อมันเป็นเวอร์ชั่นมันเป็นประเภท บางครั้งนั่นคือทั้งหมดที่คุณต้องการ ... 4 หรือ 5 ข้อมูลสั้น ๆ

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

ถ้าไม่มีอะไรออกไปทำสิ่งที่คุณต้องการและความต้องการของคุณก็ง่ายฉันจะเริ่มจากสิ่งนี้

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

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

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

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


อย่าประมาทพลังของความเฉื่อย การเปลี่ยนโซลูชันเทคโนโลยีต่ำให้เป็นสิ่งที่มีประสิทธิภาพยิ่งขึ้นนั้นต้องใช้ความพยายามมากกว่าที่จะไม่เริ่มต้นด้วยวิธีนั้น
Berin Loritsch

1
@BerinLoritsch อาร์กิวเมนต์เดียวกันนี้ใช้กับโซลูชันทั้งหมดเทคโนโลยีขั้นต่ำหรือไฮเทค ... ใคร ๆ ก็เถียงว่าไฮเทคต้องการระบบมากขึ้นระหว่างการพึ่งพาจริงทำให้สถานการณ์นี้เลวร้ายที่สุดไม่ใช่เรื่องง่าย ที่กล่าวว่ามีขีด จำกัด ที่โซลูชันที่ใช้เทคโนโลยีต่ำง่าย ๆ จะมีความซับซ้อนมากกว่าโซลูชันที่ใช้เทคโนโลยีชั้นสูง
Newtopian

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

0

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

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

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

ดังนั้นชื่อไฟล์จะมองเห็นได้พกพาและจัดการได้ นี่ไม่ใช่เรื่องเลวร้ายสำหรับการจัดเก็บข้อมูลเมตา

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


0

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

ชื่อไฟล์เป็นข้อมูลเมตา - เป็นข้อมูลเกี่ยวกับข้อมูลในไฟล์โดยไม่ขึ้นกับข้อมูลไฟล์ ในความเป็นจริงชื่อไฟล์มีอายุมากจนอาจเป็นตัวอย่างที่ยอมรับได้ของข้อมูลเมตา

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.