ファイル書き込みをするプログラムで気をつけた方がよいこと | IIJ Engineers Blog
この記事について この記事では、ファイルに書き込みを行うプログラムを実装する時の注意点について説明します。 ファイル書き込みは、プログラミングにおいて比較的よく利用される機能でありながら、実装時に注意していないと、システムクラッシュ（意図しない電源の喪失や OS のクラッシュ等）後にファイル上のデータが整合性を失う可能性、平たく言えば、データが破損する場合があります。 今回の主な内容はトランザクションに関連する事柄で、ご存知の方からすると当たり前と思われることだと思われますが、執筆者がプログラミングの勉強を始めて以降知らない期間が長かったことと、他にもご存知ない方がある程度いらっしゃるのではないかと思ったため、このように記事にさせていただきました。 また、ここで説明する注意点は、クラッシュ後にデータの整合性が重要でない場合は、気を付ける必要がないものであることを先に書いておきます。 先にこ
プログラム内のデータベース処理高速化TIPS:phpspot開発日誌
10 sql tips to speed up your database プログラム内のデータベース処理高速化TIPSが10個紹介されているエントリのご紹介です。 SQLが適切に設計されていないとすぐにデータベース処理がCPUを圧迫してしまいますので可能な限り知っておきたいですね。 基本的な事から応用的な事まで参考になりそうだったのでメモ程度にご紹介。 explainでインデックスが使われているかを調べる 最も速いクエリは、クエリを発行しないこと、ということでデータをキャッシュしよう Memcached, CSQL Cache, AdoDB などでそれが可能 必要じゃないモノをselect しないようにする select * from table; ↓ select id from table; limit を使って取得する結果を少なくする foreach ループなどの中でsqlクエリを
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者:奥野 幹也技術評論社Amazon 積ん読に入っていたので読んだ。 この本はリレーショナルモデルを理解することによってRDBの知識を深めようというような本。RDBを実践で使っている人がさらに知識を深めるための本という感じ。内容としては重要な理論がRDBと紐付けられて解説されていて面白かった。一方で、専門用語が文章中に多く使われていて、個人的には何か頭に入ってこなかった点は残念だった。 この本を読みながらわからないところを調べていて見つけたのだけど、この本の著者の昔の発表資料である「データベース設計徹底指南！！」がこの本の端的なまとめになっていて、しかも非常に良い資料なので本当におすすめ。本で紹介されているリレーショナルモデルや正規化理論などがわずか15分程度で理解できる
イミュータブルデータモデル(入門編)
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)