由於考慮到資料過多的問題,所以想請教一下通常資料庫備份是寫一個應用程式(用

easygoing, 您好 說實話，我是比較懶惰的工程師， 可以叫系統做的事，我就不會再寫程式另外做， 除非系統的功能不符合客戶的需求， 所以，如果只是要做備份的話， 我個人會叫系統做，不會再另外寫程式。 因為您使用的是MS-SQL，而MS-SQL本身就可以做備份了， 當然懶惰的工程師當然就不會再另外寫程式囉！ 以上是個人的意見，僅供參考！ ================================= <>涵養怒中氣。謹防順口言。留心忙裡錯。珍惜有時錢。 <>是非終日有，不聽自然無 <>天下本無事，庸人自擾之

那再請問一下喔!如果是考慮到某些table的資料筆數可能過多,想要將時間較久的資料轉到另一個table作為歷史檔,請問有沒辦法寫程式去完成? 還是只能直接開SQL的視窗將資料匯出然後刪除? 請問實務上外面的系統是如何做這種備份工作的呀? 謝謝~~

這個問題牽扯的範圍很廣, 做法也有很多種, 基本上, 若是資料都會查用的話, 不建議將歷史資料放另一個 db 中, 因為查詢的內容可能會查到, 但若是想增加速度的話, 是以增加 index 為查詢條件. 若將資料做橫向的切割, 比較簡單, 就是如 mydata, mydata_his 兩個資料表的schema 都一樣, 將資料 < 2000 年的放在 mydata_his 中, >2000年的放在 mydata 中, 但這是以資料中有時間的欄位來切割, 若是查詢條件不是該時間欄位的話, 又必須將這兩個資料表合併再下 query 來查, 最後還是一樣地慢, 甚至更慢, 若是考量備份問題的話, 又有更複雜的處理方式, 所以建議你非 log 性的資料, 儘量不要去切割 table, 否則查詢起來更難處理, 應該是規劃更好的 table schema 來處理才是正確的解決之道! 至於備份的問題, 可以使用 mssql 內建的 backup 來進行即可, 不需要自己寫程式, 利用系統的備份, 不僅資料量比較小, 而且也比較完整, 再加上可以 full backup 及 differential backup 很有彈性, 需要這方面的資料, 建議你找一些資料庫管理的書來看看就明白了!

easygoing, 您好 如果是要作為歷史檔的話， 那就要寫程式囉！ timhuang前輩不建議將歷史資料放另一個 db 中， 大體上我也同意這句話， 不過我還是要提醒一下， 有時候還是要視情形而定的。    有些進銷存或是pos系統就會將每日的資料存在一個table， 而所有的歷史資料存在一個table， 遇到要查詢時就直接查詢歷史資料， 我也見過有些系統是把歷史資料再細分許多的table。    總歸一句，每個人遇到的情形不同， 所以解決方法也不同。    如同timhuang前輩說的問題牽扯的範圍很廣，做法也有很多種。< > 所以大家給的都是方法，而您得自行找一個適合您的方法。< > ================================= 涵養怒中氣。謹防順口言。留心忙裡錯。珍惜有時錢。 是非終日有，不聽自然無 天下本無事，庸人自擾之

謝謝兩位前輩的幫忙~~已經有小小的頭緒了,謝謝嚕.....