はじめに｜図解 DB インデックス
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
最適なデータベースを選択するために考慮するべきこと - Qiita
こんにちは！少し前までProgateでエンジニアのインターンをさせていただいておりました、chisatonと申します。 Progateのアドベントカレンダーに参加させてもらえるだなんて思ってもみなかったので、とても嬉しい限りです。 今私はエンジニアとして別の会社で働かせていただいているのですが、今の部署とProgateではAWSを使用しているという点で共通点があるため、今回はAWSのサービス紹介も兼ねて、どんな時にどのデータベースを選択すべきなのか、についてまとめてみようかと思います。 元ネタは、最近参加させていただいたラスベガスでのAWS re:Inventの"Which Database to Use When?"というセッションになります。 こちらに動画が既にアップされていますので、興味がある方はこちらを見てみてください。 DB選択においてまず考慮すべき3つの項目 Shape Siz
DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
ITエンジニアはSQLアンチパターンを読むべし！ 軽いまとめ
もうこれだけでBad smellしかしませんね。検索とか考えると頭が痛いです。重複考慮した更新や削除とかも同じくきついですね。 従属テーブル作って対応しましょう。 8. メタデータトリブル（メタデータ大増殖） 全く同じテーブルなのに年や月で分かれていたり、同じような列が連続しているやつです。 CREATE TABLE LOG_2013 ( ... ); CREATE TABLE LOG_2014 ( ... ); CREATE TABLE LOG_2015 ( ... ); データが多すぎるから分けた、というケースが多いと思います。古いデータは使わないし、かといってテーブル１つにするとクエリが遅くなるし、みたいな。 上記のようなケースならOKだし、実際そういう経験はありますが。LOG_2014テーブルの2014/12/31のデータが間違ってたので、UPDATEして2015年のデータにしよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヤフー社内でやってるMySQLチューニングセミナー大公開
データベースオブジェクトの命名規約 - Qiita