SQL ServerよりOracleの方が優れてるなと思った話 - 情シスは何度でも甦るさ。
Oracle社は好きじゃないんだが、OracleDBは好きです。前職では、なんちゃってDBAみたいな役割だったこともあり、Oracle Master Goldも取得した。 ですが、今の会社で昨年基幹システムのリプレースがあり、そのシステムがSQL Serverだったのですが、運用フェーズに入ってSQL Serverと戯れることが多くなりました。 で、改めてOracleの方が優れてるなぁ。という話。コスト的には断然安いからその点は置いとくとして、あくまで運用担当者目線。あと、今回導入したERPのソフトに起因するのもあるけれども、つらつらと書いてみる。 基本機能 読み取り一貫性とロック よく言われるやつなんですが、Oracleの読み取り一貫性がSQL Serverにはない。ということで、色々挙動が変わるのですが、最も影響がでたとこでいうと、SQL ServerのSELECTはデフォルトで、SE
年金データ再委託「SAY企画」従業員が証言「入力ミスは日本でやったもの、中国業者は正確だった」 | AERA dot. (アエラドット)
年金情報の入力業務を委託された「SAY企画」が、中国の業者に事業を再委託して個人情報が渡っていたことが問題となっている。入力作業もずさんで、86万件のミスがあった。 続きを読む
ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
