Apakah praktik yang buruk untuk menyimpan informasi metadata dalam nama file? Solusi yang lebih baik?


13

Saya perhatikan di mana saya bekerja orang tertarik untuk menyimpan informasi dalam nama file, dan parsing nama file.

Bagi saya ini sepertinya bukan latihan yang bagus. Saya sudah melihat masalah sesekali dengan skrip menggumpal untuk file, dan mendapatkan yang salah karena file lain cocok terlebih dahulu. Kami juga membahas bagaimana mengatasi masalah dengan pemisah untuk bidang.

Apakah itu dianggap praktik yang buruk atau tidak?

Apa solusi lain yang diterima untuk mengambil file dari sistem file berdasarkan beberapa jenis metadata?


Itu sangat tergantung pada apa sebenarnya yang disimpan pada nama file. Bisakah Anda memberi kami beberapa contoh?
T. Sar

Jawaban:


14

Ya saya pikir itu praktik buruk. Ini tunduk pada semua jenis masalah - misalnya batas panjang, masalah penyandian dan konflik karena data duplikat.

Lebih baik menggunakan "file master" (kadang-kadang disebut manifes atau indeks) yang berisi metadata dan path ke file. Atau sesuatu yang serupa dalam database, daftar atau yang lainnya. Atau untuk meletakkan meta data di dalam file aktual, di tingkat atas beberapa struktur data yang terkandung dalam file misalnya JSON atau XML.

Ini agak analog dengan konsep meletakkan informasi, atau menempatkan kunci nama di penyimpanan nilai kunci. Saya pikir ini ok selama Anda menggunakannya hanya untuk namespace dan melakukan pencarian cepat - komponen kunci tidak ada untuk memberikan informasi yang dapat diuraikan. Jika Anda membutuhkan informasi itu, duplikat ke dalam nilai (file dalam kasus di atas).


3
Anda meningkatkan poin usus. Tetapi ada beberapa situasi ketika masuk akal untuk memasukkan informasi ke dalam nama file. Pikirkan lampiran surat yang harus dirutekankan atau diproses dengan cara berbasis aturan. Jika banyak proses paralel harus mengubah file master, itu mungkin menjadi hambatan.
Axel Kemper

Sebagai pengembang basis data, saya secara alami berpikir untuk menggunakan basis data alih-alih file manifes (salah satu alasan saya bertanya di sini untuk metode alternatif). Itu akan memecahkan masalah akses bersamaan, tetapi merupakan solusi yang lebih kompleks.
wobbily_col

1
@wobbily_col, tergantung pada sistem yang Anda gunakan, mungkin ada dukungan untuk atribut file tambahan yang tersedia.
Hellion

@ AlexKemper Hanya ada begitu banyak info yang bisa Anda masukkan dalam sebuah nama. Ada lebih banyak metadata daripada nama dan penulis.
Tulains Córdova

Belum lagi nama file dapat diubah oleh seseorang di luar sistem Anda, melanggar format yang diharapkan. Bahkan ketika Anda memiliki izin file yang sesuai ditegakkan, itu akhirnya menjadi solusi rapuh.
Berin Loritsch

5

Pertama, metadata adalah konsep yang buram.

Yang mengatakan, banyak kasus metadata dalam file sudah ada:

  • nomor versi perpustakaan
  • tanggal dan waktu gambar, atau setidaknya indeks urutan
  • jenis file, yang memicu aplikasi apa yang harus membuka file
  • nama direktori rumah Anda, yang harus menjadi nama pengguna sesi Anda

Namun demikian, daftar pendek itu bukan argumen yang mendukung praktik tersebut.

Alternatifnya adalah:

  • menangani metadata di level FS, seperti HFS lama Apple misalnya
  • masukkan metadata ke dalam file itu sendiri, seperti Exif untuk gambar atau ID3 untuk suara
  • letakkan metadata di file lain atau dalam database, seperti kebanyakan manajer media.

5
Semuanya adalah konsep yang buram. Bahkan "buram", "konsep" dan "semuanya" adalah konsep yang buram.
Tulains Córdova

3

Sepertinya Anda membutuhkan database.

Ada banyak masalah keamanan dengan menempatkan data pengguna dalam nama file. Katakanlah Anda memiliki file untuk setiap pengguna ("username.txt"). Apa yang terjadi ketika seseorang mendaftarkan nama pengguna "../../../../etc/passwd" tergantung pada bagaimana Anda memfilter input pengguna.

Kerangka kerja basis data terkadang akan membantu Anda membersihkan input pengguna.


Sebenarnya, banyak sistem operasi menyimpan nama pengguna dalam nama direktori, yang disebut direktori home .
mouviciel

Itu karena perangkat lunak somebodies harus di bagian bawah tumpukan. Itu tidak berarti bahwa setiap orang harus bekerja pada level itu. Saya tidak akan berdebat tentang keunggulan database, karena programmer telah menggunakannya selama lebih dari 50 tahun.
Eric Wimberley

1
@ mouviciel Saya tidak mengetahui adanya sistem operasi yang mem-parsing nama pengguna dari nama direktori home pengguna. Sistem Windows dan seperti Unix keduanya menyimpan nama direktori dalam beberapa jenis database dan memuatnya ke lingkungan ketika pengguna login. Di bawah kedua sistem, Anda dapat berakhir dengan nama direktori rumah yang berbeda dengan nama pengguna ( mis. mengganti nama pengguna, atau jika Anda memiliki dua instal windows pada partisi sistem yang sama).
Jules

2

Tidak ... yah .. belum tentu.

Selama Anda memiliki konvensi yang ketat dan sarana parsing dan validasi umum (skrip, perpustakaan, dll.) Tersedia, Anda siap melakukannya.

Ambil contoh pengemasan dan sistem manajemen ketergantungan (Maven, NuGet dan sejenisnya). Meskipun banyak yang akan menggunakan file spesifik untuk metadata untuk menyimpan informasi yang lebih lanjut, informasi dasar seringkali merupakan bagian dari nama file itu sendiri. Bergantung pada konvensi yang ketat, nama file dapat berisi informasi yang paling relevan tentang paket: itu vendor, itu nama, itu versi, itu tipe. Terkadang hanya itu yang Anda butuhkan ... 4 atau 5 informasi singkat.

Jika metadata sederhana maka konvensi penamaan file masuk akal tidak memerlukan apa-apa untuk menempatkannya. Ini dapat diperkuat dengan alat dan skrip yang sangat sederhana, tidak perlu database, tidak ada infrastruktur khusus hanya beberapa skrip dan konvensi penamaan.

Jika tidak ada yang cukup melakukan apa yang Anda butuhkan dan kebutuhan Anda sederhana saya akan mulai dengan ini.

persyaratan Anda melebihi konvensi ini? lanjutkan dengan file metadata yang tepat. Anda nanti perlu pencarian yang lebih baik untuk ini? Sudah ada solusi bagus di luar sana untuk mencari file yang membawa Anda ke tempat yang Anda butuhkan.

Bukannya saya tidak suka basis data, justru sebaliknya mereka benar-benar kuat dan berguna tetapi mereka membutuhkan sejumlah biaya tambahan untuk bisa berjalan. Mereka perlu diinstal, didukung, dipelihara, Anda akan membutuhkan staf yang, jika tidak sepenuhnya berdedikasi, perlu mendedikasikan sebagian waktu mereka untuk infrastruktur ini. Mereka juga lebih kompleks dan samar untuk orang awam, kehilangan dev yang mengatur Anda dan sistem Anda akan terjebak dalam waktu sampai Anda menemukan penggantinya.

Jangan pernah meremehkan kekuatan teknologi rendah dengan pengawasan yang tepat, itu bisa membuat Anda jauh.

Dan pada saat Anda melebihi solusi berteknologi rendah Anda, Anda akan telah mengumpulkan semua pengalaman dan persyaratan untuk menerapkan sistem yang sempurna untuk kebutuhan Anda.


Jangan pernah meremehkan kekuatan kelembaman. Mengubah solusi berteknologi rendah menjadi sesuatu yang lebih tangguh membutuhkan lebih banyak upaya daripada tidak melakukannya sejak awal.
Berin Loritsch

1
@BerinLoritsch argumen yang sama berlaku untuk semua solusi, teknologi rendah atau hitech ... orang bisa berpendapat bahwa hitech yang membutuhkan lebih banyak sistem antar ketergantungan sebenarnya membuat situasi ini lebih buruk, bukan lebih mudah. Yang mengatakan, ada ambang batas di mana solusi sederhana berteknologi rendah menjadi lebih berbelit-belit daripada itu mitra teknologi tinggi penuh sesak nafas.
Newtopian

1
Yap, dan saya melepaskan beberapa contoh pada proyek sekarang. Intinya adalah bahwa tidak perlu ada antarmuka yang lebih ketat daripada sistem file lebih banyak daripada tidak. Sayangnya, sebagian besar sistem teknologi rendah yang saya warisi tidak memiliki pemikiran atau desain yang sesuai untuk diterapkan. Jumlah pengecualian yang dapat saya andalkan di satu tangan.
Berin Loritsch

0

Pertama, mari kita setuju apa file adalah . File adalah data paket dengan nama yang dapat ditransmisikan, diterima, dibuat dan dihapus dengan operasi atom (sangat dekat dengan).

Banyak sistem file (Mac OS, dan sistem file Linux yang lebih baru) menerapkan "garpu", sering digunakan untuk menyimpan sumber daya dan metadata. Pendekatan untuk menyimpan metadata ini bermasalah karena metode transfer jaringan tradisional, metode cadangan dan pemulihan, serta metode menyalin file tidak konsisten, terutama ketika sistem file sumber dan tujuan memahami garpu file secara berbeda.

Nama file digunakan untuk menyimpan metadata karena a) selalu ada, b) metadata selalu ada dalam nama file (setidaknya dalam penggunaan ekstensi file), dan c) nama file mengalami terjemahan yang sangat sedikit saat memindahkan antar sistem (perbedaan case, batasan set karakter, batasan karakter).

Jadi, nama file terlihat, portabel, dan dapat dikelola. Ini bukan hal yang buruk untuk menyimpan beberapa metadata.

Mungkin solusi terbaik untuk mengatasi metadata file umum adalah dengan menggunakan repositori konten , di mana repositori konten dapat dikonfigurasi dengan skema metadata yang akan digunakan untuk file. Dalam banyak kasus ini berlebihan, tetapi, IMHO, adalah cara untuk pergi untuk manajemen metadata yang serius.


0

Menurut saya ini adalah bahwa Anda mungkin telah melihat beberapa kode di suatu tempat yang melakukan hal-hal yang ceroboh atau rapuh dengan nama file, tetapi itu tidak berarti bahwa "menyimpan metadata dalam nama file" secara umum buruk.

Nama file adalah metadata - mereka adalah data tentang data dalam file, terlepas dari data file itu sendiri. Bahkan, nama file sudah sangat tua sehingga mereka mungkin adalah contoh kanonik dari metadata.

Jika Anda menganggap bahwa ekstensi file hanyalah bagian akhir dari nama file, maka konsep nama file-sebagai-metadata menjadi semakin tak terhindarkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.