アカウント名:
パスワード:
ボリュームシャドウコピーでよくない?
あるいは、gitつかうとか。
xls使ってるような(そんなしょぼい仕事受けてる)ところがそんなもの知ってるわけないだろ
と言うより、#3902491 [srad.jp]自体、VSSもVCSも知らなさそうに見えるね。
上書きするファイルじゃないと思うが。日別に受信したものを全部残しとけという話でgit使っても意味ないだろ。
個人的にはそれなりのDBMS使えとは思うけど。
日別に受信したものを全部残しとけという話でgit使っても意味ないだろ。
そう言う前提で、「日付フォルダにぶち込んで一定期間取ってお」けばいい、程度のもんなら、gitでも構わんのじゃないか。
逆にDBMSで安心できるのか、って気もするな。DBを何世代かバックアップを取っておけば安心できるのかもしれんね。
よくわからんのだけど、オリジナルのデータを手を加えずしばらくの間保管していらなくなったら捨てるという用途にgitが向いてんの?
目的的には、普通にバックアップをとればいいんじゃないかな。
その「普通にバックアップ」って、具体的にはどういう方法?バックアップツールで定期増分バックアップを取るとか? それが今回の「目的的」にVSSより使い勝手が良いとは思えないけどなあ。もちろん、データ保全という意味では優れてると思うけど。
>データ保全という意味では優れてると思うけど。結論が出ましたね。
データ保全に優れている、ってのはたとえば、専用のバックアップツールを使って、定期増分バックアップを別メディアに取る場合とかだよ。キミ、解ってないでしょ? キミが言うような、日付ファイル名を使う方法では、データ保全性は、保証できないよ。
そういっても空間は有限なんだから
なんでそんなに貧乏くさい前世紀的発想から逃れられないんだい?そのデータ、XLSだかCSVだかは知らんけど、何MiBあるって話?全部取っておいたって、百年以上保存し続けることができるレベルでは?
ふさわしい期限を付けて消すルールを決める。
そのルールの運用が破綻するだろう。そんな例はたくさんある。そして、その削除を人手に頼る限り、間違って消しちゃダメなものを消してしまうことは有り得る。そんな前時代的な日付ファイル名+人力管理に頼るよりは、VSSの方がいいだろ。
もしかして、新しい技術に付いていきたくない人?そう言う人を受け入れざるを得ない残念な現場なら、キミの言うような方法で仕方ないと思うよ。実際、私もそう言う現場に当たることもある。
まさにそういう臭いがプンプンする現場のケースだろこれ
この現場もっとヒドくて、間違って大切なファイルを削除しちゃったりする。だから、信用ならない人手の操作に頼らず、自動化できる仕組みの方が良い。VSSなら、今回の様な操作ミスはすぐに救えたのは解るよな?
この事例でファイル名に日付がついているのはバックアップ目的じゃないだろ。ファイルなるフォルダに日付がついていたらバックアップと思い込むのやめたら。
ファイルなるフォルダに日付がついていたらバックアップと思い込むのやめたら。
スレッドをざっと見まわした限り、日付パス名がバックアップだ、と言う趣旨のことを書いた人は、キミだけの様だよ。少なくとも私はそんなことは書いてない。
ちなみに、私が提案したVSSもVCSも、バックアップではない。リモートリポジトリに保存するVCSは、バックアップと考えることもできるけど、そう言う趣旨で言っているわけでも無い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
xlsの問題じゃなくて、組み方だよね (スコア:0)
だいたい、送られてきたデータはその日付フォルダにぶち込んで一定期間取っておかないと怖い気がする。
別にサーバー上の集計bookだけ2007形式「xlsm」とかでつくれば、解決する案件かな
Re: (スコア:1)
ボリュームシャドウコピーでよくない?
あるいは、gitつかうとか。
Re: (スコア:0)
xls使ってるような(そんなしょぼい仕事受けてる)ところがそんなもの知ってるわけないだろ
Re: (スコア:1)
と言うより、#3902491 [srad.jp]自体、VSSもVCSも知らなさそうに見えるね。
Re: (スコア:0)
上書きするファイルじゃないと思うが。
日別に受信したものを全部残しとけという話でgit使っても意味ないだろ。
個人的にはそれなりのDBMS使えとは思うけど。
Re: (スコア:1)
日別に受信したものを全部残しとけという話でgit使っても意味ないだろ。
そう言う前提で、「日付フォルダにぶち込んで一定期間取ってお」けばいい、程度のもんなら、gitでも構わんのじゃないか。
逆にDBMSで安心できるのか、って気もするな。
DBを何世代かバックアップを取っておけば安心できるのかもしれんね。
Re: (スコア:0)
よくわからんのだけど、オリジナルのデータを手を加えずしばらくの間保管していらなくなったら捨てるという用途にgitが向いてんの?
Re: (スコア:0)
無理に使う必要は無いと思う
スナップショットツール。任意の時点のスナップショットを取り出せるのはいいことかしれないけど、目的的には、普通にバックアップをとればいいんじゃないかな。
Re:xlsの問題じゃなくて、組み方だよね (スコア:1)
目的的には、普通にバックアップをとればいいんじゃないかな。
その「普通にバックアップ」って、具体的にはどういう方法?
バックアップツールで定期増分バックアップを取るとか? それが今回の「目的的」にVSSより使い勝手が良いとは思えないけどなあ。
もちろん、データ保全という意味では優れてると思うけど。
Re: (スコア:0)
結論が出ましたね。
単純さは無難だから。無理にオーバースペックである必要はない。
教育しなくても、誰でもやりたいことが操作が出きるしね。
そういっても空間は有限なんだから、ふさわしい期限を付けて消すルールを決める。
間違って操作してもOS レベルで救済がある。その程度の話じゃないかな。
Re:xlsの問題じゃなくて、組み方だよね (スコア:1)
>データ保全という意味では優れてると思うけど。
結論が出ましたね。
データ保全に優れている、ってのはたとえば、専用のバックアップツールを使って、定期増分バックアップを別メディアに取る場合とかだよ。
キミ、解ってないでしょ? キミが言うような、日付ファイル名を使う方法では、データ保全性は、保証できないよ。
そういっても空間は有限なんだから
なんでそんなに貧乏くさい前世紀的発想から逃れられないんだい?
そのデータ、XLSだかCSVだかは知らんけど、何MiBあるって話?
全部取っておいたって、百年以上保存し続けることができるレベルでは?
ふさわしい期限を付けて消すルールを決める。
そのルールの運用が破綻するだろう。そんな例はたくさんある。
そして、その削除を人手に頼る限り、間違って消しちゃダメなものを消してしまうことは有り得る。
そんな前時代的な日付ファイル名+人力管理に頼るよりは、VSSの方がいいだろ。
もしかして、新しい技術に付いていきたくない人?
そう言う人を受け入れざるを得ない残念な現場なら、キミの言うような方法で仕方ないと思うよ。
実際、私もそう言う現場に当たることもある。
Re: (スコア:0)
まさにそういう臭いがプンプンする現場のケースだろこれ
Re:xlsの問題じゃなくて、組み方だよね (スコア:1)
まさにそういう臭いがプンプンする現場のケースだろこれ
この現場もっとヒドくて、間違って大切なファイルを削除しちゃったりする。
だから、信用ならない人手の操作に頼らず、自動化できる仕組みの方が良い。
VSSなら、今回の様な操作ミスはすぐに救えたのは解るよな?
Re: (スコア:0)
この事例でファイル名に日付がついているのはバックアップ目的じゃないだろ。
ファイルなるフォルダに日付がついていたらバックアップと思い込むのやめたら。
Re:xlsの問題じゃなくて、組み方だよね (スコア:1)
ファイルなるフォルダに日付がついていたらバックアップと思い込むのやめたら。
スレッドをざっと見まわした限り、日付パス名がバックアップだ、と言う趣旨のことを書いた人は、キミだけの様だよ。
少なくとも私はそんなことは書いてない。
ちなみに、私が提案したVSSもVCSも、バックアップではない。
リモートリポジトリに保存するVCSは、バックアップと考えることもできるけど、そう言う趣旨で言っているわけでも無い。