![]() |
PCDVD數位科技討論區
(https://www.pcdvd.com.tw/index.php)
- 儲存媒體討論區
(https://www.pcdvd.com.tw/forumdisplay.php?f=20)
- - [心得]資料的管理
(https://www.pcdvd.com.tw/showthread.php?t=899239)
|
---|
我還是靠速效的everything就好
|
小弟的分類方式也與開版大類似。
主要先以各式硬碟分類再以母、子資料夾做細分 資料夾命名時考量軟體及救援等因素,皆以英文命名。 額外分享一個我常用的小技巧,在分類音樂或電影時我習慣設定"資料夾圖片" 這樣的好處是,找專輯時直接看歌手的大頭照,然後"看"專輯封面,很快就能找到; 電影也是,直接找縮圖上的電影海報,連資料夾名稱都幾乎不用看了。 一般設定方式是:資料夾上點右鍵->內容->自訂->選擇圖片 可是這樣偶爾設定會跑掉,或是一些奇怪錯亂的問題 後來解決的方式是,直接將你要設為縮圖的圖片取名為"folder.jpg",錯亂的狀況就幾乎不再。 另外在這請教一下,不知道有什麼技巧或軟體能使"windows檔案總管"左邊的樹狀瀏覽 顯示"資料夾圖片"。 |
引用:
是指左邊樹狀圖小小的黃色資料夾能套用顯示內含的圖片嗎@@? 抱歉,看不大懂 ^^" ============================== 原來要設成folder.jpg呀....之前看過有設cover.jpg的....似乎是對應不同軟體 感謝您的分享,又學到一招^^ |
我的檔案還沒到分這麼細
不過板大的文收下參考,以後可以來用參考 好文往上推 --- 個人 4個硬碟 --- 1.本機磁碟-----作業系統以及所有軟體安裝 2.遊戲&軟體----常用檔案&程式,重灌軟體,遊戲安裝處 3.資料儲存-----遊戲原檔保存,PS2 Wii PC 等等... 4.資料儲存2----影片檔保存 --- 2.遊戲&軟體下的音樂我是用年分排序... 幾年幾月幾日的專輯,偶爾會偷懶只填上年份 ---如下所表示--- 2004-4-29-F.I.R 2005-周杰倫-十一月的蕭邦 2006-6-14-Angela Aki-Home 2007-8-22 中島美嘉 - LIFE 2008-1-8-鴉-KARAS- OST 2008-2-10-震驚世界的完美剛琴CD(Dreaming) 2009-4-20-極致立體聲-絕對人聲 2010-3-18-機動戰士 獨角獸 OST-GundamUnicorn +++ 3.遊戲原檔保存分為 PC,XBOX 360 ,PS2,Wii,4種 一樣按照年分排序 +++ 4.影片保存的話,會分春夏秋冬來分 像2009...的影片會分為 2009-冬季-日劇-旋愛 2009-春季-日劇- MR.BRAIN 2009-夏季-公主戀人 2009-秋季-科學超電磁炮 等類似排序... |
引用:
:) 大致上如您所述,我覺得用Freecommander或是Q-Dir就能設定出來,只是還蠻雞肋的所以就沒繼續求解。 |
引用:
這裡提到二個重點: 1.檔案[數量&種類&特性]的多寡決定資料庫分支[數目/細度]及[深度] 以最常見的歌曲收藏及分類來說 不分大類,全放在同一資料夾下的好處是: 靠關鍵字搜尋過濾即可找到目標,不用在層層目錄下搜尋 缺點是單層子資料夾數澎漲極快,大於一定數量會影響系統回應速度 另,領域混雜,不易掌握資料庫規模,增加備份難度 且大幅增加使用鍵盤keyin關鍵字搜尋之仰賴性 搜尋起來也不若滑鼠點選,或搖控器控制來得直覺 ex.以人名分類,較容易掌握有多少位歌手,以DVD 4GB為單位來備份 且方便檢視是否重複收藏。 不分類容易變成僅知專輯總數,不易分開備份,且重複收藏 2.影音檔案以發表日期做為開頭命名是相當理想的做法 但相較於文件與照片來說,日期對於影音檔案的[必要性]較低 加上屬於需要額外花費心力尋找的資訊 實務上容易增加維護建構的困難性,碰上不可考或難尋出處時間之作品 反而造成格式缺漏,不整齊(嚴重時造成維護廢弛也是常見的事) 個人傾向將日期往後放,為次要標籤,減輕維護的負擔 倘若維護人力充足,日期為首的做法,將在資料庫龐大時展現極大的功效 |
引用:
如果如我想的是同一個東西.. 在那麼小的空間顯示圖片的功能的確...蠻雞肋的 :jolin: 因為辨識度不高(太小),而且容易造成雜亂的反效果 |
引用:
最早之前做法是,依西洋,東洋,國語來分類 之後就索性把影音類檔統一方式日期放置... --- 您的建議收下!~想到要重新整理就...:( 不過下台主機,這種方式可以減少歌曲重覆的情形 感謝^Q^~ |
資料的管理 Part2
既然有人提到桌面搜尋工具,及檔案系統tag標籤的概念
就順著寫來 前文主題雖然是[資料管理],其實此系統已將備份;轉移的需求考量進去 於有限的空間,設定有限的項目,進行分類、存放, 對於資料庫規模的掌握,載體轉移,備份,有很大的幫助。 相較於仰靠桌面搜尋工具,不進行分類的做法 有點像是在無限的空間,無限的項目,堆放資料 然而實務上,空間不是無限的,在資料必須備份,轉移時便會造成一定程度的困擾 較適用於資料量小,同質性低,種類單純的環境 ======================================================================== <實務上分類的做法及好處> (一)以粗分大類[文件;音樂;圖片;影片;程式....]立即得到的優點為: 1.容易掌握各類別檔案所佔容量,推估成長速度,進而規畫載體容量 2.在空間不敷使用時、整塊轉移至新硬碟,舊硬碟留做其它類別擴充使用 或是異地備份,以實體硬碟(或光碟)為單位管理, 檔案性質單純,可大幅減少實務操作的手續與難度 3.群聚/整齊的檔案,便於滑鼠/搖控器.等較直覺的點選方式,增加瀏覽的流暢度 降低關鍵字的記憶,及鍵盤的仰賴性,對於檔案系統不熟悉的使用者也可快速找到目標 或瀏覽其它相關物件 (二)粗分大類[文件;音樂;圖片;影片;程式....]實務上的參考做法為: 1.以檔案大小考量:文件,MP3音樂檔,JPEG/PNG圖片檔屬小型零粹檔案,且成長速度較慢 分類後放同一硬碟,視情況分出獨立硬碟 1GB左右之電影/動畫等中型檔案,放同一硬碟,或獨立硬碟 10GB~40GB之影像檔,使用大容量硬碟存放 2.以執行速度考量:裝機程式、遊戲、Program資料夾、系統image檔,可考慮使用高速磁碟獨立存放 增加存取效率,及減少與系統碟之間相互干擾牽制 3.以重要性考量:論文,家人照片,底搞...不容閃失的任何重要檔案,可考慮存放於獨立磁碟 減少中毒、mft毀損..等風險 外加定期異地備份(硬碟或光碟),或即時Raid1備份 ============================================================================= 分類的好處因人而異,資料量真的很少,分什麼類?浪費時間,直接桌面搜尋搞定 但若是資料量龐大,下面談到的tag標籤概念除了增加搜尋效率,還有利於備份的效果 最常見的tag應用於mp3上,註記歌名,曲目,歌手,年代,曲風,便於歸類,尋找,及播放 基於同樣的需求,把它套用在資料夾的命名上 曾聽說某作業系統將導入全新的磁碟系統,導入tag制度,打破資料夾之間的距離 不用辛苦的層層搜尋,分類,感覺一片美好,可惜還沒導入目前的windows中 不過,以目前的樹狀目錄,加上自製的標籤,其實蠻好用的 比較困難的應該是[拿捏] 拿捏什麼? 1.該放入哪些資訊 2.tag的順序(或資料夾命名的格式) 感覺好像沒什麼,但若格式底定,累積成千上萬資料夾後,發現當初設定不夠周詳,就是場大災難 不是忍受前後期格式不一,就是逐行逐列手動更改的大工程 雖然不大一樣,但千禧年危機就是預留欄位不足,導至日期重覆、錯誤、錯亂的問題 但又不能極期詳盡地把所有資訊都列上去,徒增人力/空間浪費, 太長的檔名/資料夾也會造成OS、燒錄軟體、壓縮軟體的相容性問題 所以頡取適當、符合個人使用習慣,資訊做為標籤是很重要的,另外,能具有延展性的格式更為理想 ------------------------------------------------------------------------------------------- <tag標籤的實做> 以搜尋羅輯來分: 1.照片類(同文件類): 照片-電腦相關-[20080725]資展-主機板 -顯示卡 -ShowGirl [20090728]資展-主機板 -顯示卡 -ShowGirl -家庭旅遊-[20070728]北投 [20070813]花蓮 說明: 通常找照片會以成員、地點、及時間為搜尋標的 假如只有分類[家庭、自拍、寵物..],底下依類存放,資料夾一多,還是不易尋找及管理 加上數位相機拍照檔名容易重覆,更需要分開存放避免覆蓋 [20080725] =>[]符號有置頂功能,與未整理資料夾有所區隔 =>20080725,日期有排序功能,使用完整4碼西元年則是為了標籤一致性及直覺性 因為網路流傳檔案通常使用西元年,使用4碼則是為了不與民國年及年、月、日順序搞混 --------------------------------------------------------------------------------------------- 2.影片類: 電影-搶救伯恩大兵[700M] -赤必[4G][ISO] -目光之城1[1.2G] 高畫質電影-搶救伯恩大兵[42GB][1080P] -阿凡答[10GB][1080P] -阿凡答[43GB][1080P] 動畫-青花[Aoihana][11全] -化物語[Bakemonogatari][13未完] 說明: 其實標出容量有點多餘,若是XP能自動顯示出資料夾容量,就不必自己key(可換OS,或加外掛軟體解決) 但當備份的影片數量很多,順手標上的容量及格式,在檔案增刪/備份 或是判斷畫質時,一目了然,還算有用 動畫則是因應日文輸入為主,加上假名拼音,方便搜尋資料,加上集數提醒自己買/備份到第幾集 與照片tag明顯的差別是:照片tag是為了好找好整理 影片tag比較偏重迅速瞭解品質、集數,不用一個個資料夾點下去察看 ------------------------------------------------------------------------------------------- 3.音樂類: 音樂-男歌手-周杰倫-周杰倫-范特西[19990909][192K][MP3] 周杰倫-范特西[APE] 周杰倫-不能說的秘密[320K][MP3] 周杰倫-不能說的秘密[APE] -女歌手-芭菈芭菈芭.. 說明: tag選用模式與影片類似,標上格式與品質除了方便辨識,還有分類備份的功能 把原版CD轉成MP3放車上聽,APE在房間聽,若硬碟爆滿要刪歌暫時清出空間,又不想重新轉檔怎辦? MDIE輸入APE過濾,拉出來燒成一片DVD,再過濾MP3燒成一片,分類備份很簡單 聽起來好像沒什麼,但若套上多產歌手-濱崎步,或是涼宮春日/福音戰士原聲帶動輒2~30片CD 是把CD翻出來一片一片轉,還是燒成幾片DVD再讀回去..熟優熟劣,相信很好選擇 至於流行歌要不要加入日期標籤,見人見智 有能力每張專輯都找得到出版日期,就加在字首,作排序用 沒把握每張都找得到日期,就放在格式前面,作參考用,以保持格式一致性及整齊 小建議:盡量只使用-[]符號,(){}<>.逗點空白鍵少使用,維護起來會輕鬆很多.. 除了減少按鍵的使用,點號與空白鍵容易造成誤判,或資料夾重覆而沒察覺 ------------------------------------------------------------------------------------------- 4.漫畫類: 漫畫-未完結-SIDOOH士道[高橋努][注目中][11未完][缺] -真月譚月姬[佐佐木少年][18X][6未完] 漫畫-完結-H2 好逑雙物語[安達充][34全] -D.N.A2[桂正和][5全] 說明: 除了第一篇說明過的,補充說明如下 分成[完�***[未完�***二大類,可有效減少單層子目錄數量,降低磁碟系統回應的負擔 標出[作者][集數][18X][少女][未完/全/缺][恐怖] 善用MDIE可迅速找出同一作者的作品、 女朋友來時過濾出少女漫畫讓她打發時間 想看又暫時沒時間看的標上[注目中]...(個人是簡單標個[L]代表喜歡啦..) 各式各樣的標籤在不同的狀況發揮意想不到的功能 只是漫畫同質性低(一般來說,一位作家不會有太多套作品),不易縮減、整合資料夾 檔案大小不一且雜亂,實務上較難整理成4GB為單位做DVD備份,建議以整顆硬碟定期備份 ------------------------------------------------------------------------------------------- 以上,是比較常見,的tag應用 簡單的說,tag可用在: 1.同質性高,快速分類(人名,格式..) 2.排序(日期,常用性..) 3.內容成份提要(容量大小,品質,格式,狀態..) 4.特殊註記 桌面搜尋工具,有著高速,免整理的方便特性,但對於檔案不含關鍵字(如僅有曲目的MP3歌曲) 還是得對資料夾做最低限度的命名整理(尤其很多壓縮檔本身就是簡中/日文檔名) 及檔案系統引進tag標籤概念,猜想仍然得對個別檔案或資料夾做定義 (如mp3tag,除了套用網路現成的,還是得手動KEY) 所以還是那句老話,能超是你命..... 啊不~是各自有適合的應用 ------------------------------------------------------------------------------------------- 本篇其實與上篇有不少重覆之處, 但本篇加強了"why"的部份,把不同角度的考量補齊 並將實務案例做更詳細的描寫 希望這樣語焉不詳的胡言亂語能多少讓人看懂一些 ====================================================== 話說....那些手中動輒2~30顆硬碟的魔人都跑哪去啦 我好想知道他們是怎樣管理/備份他們的收藏 一個人摸索很漫長艱辛兼沒效率說 >"< |
所有的時間均為GMT +8。 現在的時間是06:03 PM. |
vBulletin Version 3.0.1
powered_by_vbulletin 2025。