リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
表示順という属性を別テーブルに分ける - そーだいなるらくがき帳
最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順
【Rails】範囲オブジェクト(Range)を使ったActiveRecordのwhere比較、範囲検索のコードの書き方 - Simple minds think alike
ActiveRecordのwhereを使って、色々な書き方で比較演算(>, >=, <, <=)・範囲抽出(Beetween、◯以上□未満)を実装できますが、最近では範囲オブジェクト (Range (例: 10..30)) を使ってほとんど実装することができるようになっています。 ただ、範囲オブジェクトを使った実装は Ruby2.7から導入されたbeginless range 範囲オブジェクトの開始の値を省略できる書き方(例: ..30) Ruby 2.6から導入されたendless range 範囲オブジェクトの終わりの値を省略できる書き方(例: 10..) を使うと綺麗に書けるので、可能であれば対応したRuby, Railsバージョンにすると良いと思います。 範囲オブジェクトを使った書き方のメリット 範囲オブジェクトを使った書き方 範囲オブジェクトを使わない書き方 範囲オブジェクトを使
Railsの生SQL概要：execute, select_all, find_by_sqlの使い方を覚える - Qiita
Railsの生SQL概要：execute, select_all, find_by_sqlの使い方を覚えるRailsActiveRecordSQL Railsで使用する生SQL Railsにおいて、ActiveRecordのwhere等では表現できない複雑なクエリを使用してDBのデータを取得する場合、生でSQLを書く必要が出てくると思います。 しかし、AcitiveRecordで生sqlを実行するメソッドは数多くあり、用途によってどれを使用すべきか分からないという方もいるのではないでしょうか。 そこで今回はよく使用されるであろう、execute/select_all/find_by_sqlについて、どのように呼び出すのか、戻り値はなにか、どのような用途で使用すべきかについて説明します。 先に結論を書いておくと execute -> クエリの実行 select_all -> セレクト文の結果
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
SQLアンチパターンon Rails Ⅰ部（論理設計） - Qiita
はじめに SQLアンチパターンをRailsの文脈で読み解いていきます。 この記事では、Ⅰ部 データベース論理設計のアンチパターン（1~8章）を取り上げます。 リンク SQLアンチパターンon Rails Ⅱ部（物理設計） SQLアンチパターンon Rails Ⅲ部（クエリ） SQLアンチパターンon Rails Ⅳ部（アプリケーション開発） 本文 1. ジェイウォーク（信号無視） class CreateProducts < ActiveRecord::Migration[5.1] def change create_table :products do |t| t.string :name, null: false t.string :account_ids end end end
CockroachDB から覗く形式手法の世界 #CNDT2020 / CloudNative Days Tokyo 2020
CloudNative Days Tokyo 2020 で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか？ この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要：https://event.cloudnativedays.jp/cndt2020 ブログ記事：https://ccvanishing.hateblo.jp/entry/2020/09/10/044848
【Ruby on Rails】重複しているレコードを取得する【MySQL】 - きゃまなかのブログ
概要 はじめに 重複しているレコードを取得 MySQL の場合 Ruby on Rails の場合 重複しているレコードを全て取得 MySQL の場合 Ruby on Rails の場合 おまけ 条件を満たさない重複レコードを削除する MySQL の場合 Ruby on Rails の場合 まとめ 概要 Ruby on Rails で DB から重複しているレコードを取得したい時がありました。 MySQL で重複しているレコードを取得する方法は分かるのですが、Ruby on Rails で同じ処理を書く場合、どうしたら良いのか分からなかったので調べて見ました。 MySQL で書く場合と、Ruby on Rails で書く場合の 2 パターン用意しています。 はじめに 今回利用するテーブルの中身を確認します。 ユーザ名 aaa が 3 件重複、bbb が 2 件重複、ccc が重複無しとなっ
MySQLのAUTO_INCREMENTについて色々と調べてみた。 - Qiita
AUTO_INCREMENTとは カラムに値が指定されなかった場合、MySQLが自動的に値を割り当てる。 データ型は整数。 値は1ずつ増加して連番になる。 基本的なこと。 テストテーブル作成 mysql> CREATE TABLE fruit(id INT AUTO_INCREMENT NOT NULL PRIMARY KEY, name VARCHAR(50), price INT); mysql> DESC fruit; +-------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+----------------+ | id | in
イミュータブルデータモデル(世代編)
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。Read less
関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
履歴を持ったテーブルの設計 - Qiita
概要 データベースの設計や不具合の調査をしていて、ふと思ったことは無いでしょうか？ ログやバックアップに頼らずに、データベースに全ての変更履歴が残るようにできないだろうか、と。 試しに、設計してみるとFOREIGN KEY制約を保ちながら履歴を持ったテーブルを設計するというのは、なかなか厄介なことに気づきます。 しかし、突飛なアイディアという訳ではなく、ネット検索してみると結構ヒットします。 変更履歴を持つテーブルの設計 履歴テーブルからデータを取得するSQL リレーショナルデータベースでは履歴の管理をすべきでない？ データベース設計 ～ マスタデータを含めて、全ての履歴を残したいという要望 先人の試行錯誤を自分なりに咀嚼して、設計してみた方法を文章として残して置こうかと思います。（※実際のプロジェクトに適用してみた気付きを加筆しました） 設計方針 履歴を持つことに意味のあるテーブルのみを
DBの正規化されていない例 - Qiita
顧客番号 が決まれば 営業社員番号 が決まるとき、第二正規形ではない。 1. 顧客番号はキーの真部分集合である 2. 営業社員番号はキーの構成要素ではない つまり、キーの一部から（候補）キーではない項目に従属性があったらダメ。 A002 の行で営業社員番号だけ変更すると、顧客番号1001 => S0010 の関連が崩れる。 通常、第三正規形にするまでの中間形式として表れる。第二正規形にあまり意味はない。 第三正規形 X → A のとき、次のどちらかを満たす Xはキー Aがキーの構成要素 第三正規形ではない例 顧客番号 届け先ラベル 郵便番号 都道府県 住所
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テーブル設計の考え方とやり方 [入門編]![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
GitHub - sue445/plant_erd: ERD exporter with PlantUML and mermaid format
あなたが知らない リレーショナルモデル
イミュータブルデータモデル(入門編)
