アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
MySQLパーティショニングの設定、追加、削除、再構成 - Qiita
まずこんなテーブルを作るとします。ここに毎月10万件以上のレコードが入ってくる予定です。 1レコードが57byteなので、月に5.7Mbyte、プライマリーキーを入れると60Mbyteくらいが入ってきます。 年間にすると720Mbyteなので、まぁデータ量的には余裕だと思うのですが、 100万レコードを超えるとレスポンスが鈍化するという印象があります。 というわけで、MySQLにあるパーティショニング機能を使い、データを振り分けたいと思います。 【参考】DB設計時のサイズ見積もり | よねのはてな テーブル作成 注意する点として、パーティショニングのキーにしたいカラムを、プライマリーキーに含める必要があるようです。 なので、オートインクリメントのカラムがあるテーブルだと辛い。構成を考えなおした方がいいかも。 CREATE TABLE `list_rtx` ( `member_id` var
オートナンバー型のカラムを含むテーブルをパーティショニング化する方法
非パーティショニングテーブルを後から、パーティショニングする際にかならずハマるのが”オートインクリメント列を含む”テーブルに関する、パーティショニングの時です その回避策について、以下にまとめました。ご参考になればと思います。 例えば以下のようなテーブルの、updated_at をレンジパーティションキーとして、変更したいなんていう場合に 現在のテーブル定義 CREATE TABLE `test_ptable` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `updated_at` datetime DEFAULT NULL COMMENT 'UTC-DATE', `domain` varchar(128) DEFAULT NULL COMMENT 'ex: www.yourdomain.com', PRIMARY KEY (`id
【MySQL】パーティショニングをやってみた - Qiita
とあるポータルサイトにて膨大なデータ数（約1,000万）のテーブルにアクセスする必要性が出てきた。そのままではDBの負荷が上がることが想定されるため、とりあえず負荷を減らすためにもパーティショニングでデータを小分けにして負荷を上げない対策を講じる。その時の備忘録。 パーティショニングを既存テーブルに追加する時の注意点 対象となるカラムをprimary keyに含める 最初、パーティショニングをするために使用するカラム（日付型）を主キーに含めていなかった。 それで実行しようとするとエラーが発生。 そもそもの主キーのカラムがオートインクリメントされるカラムなので、まずはこれを削除して、主キーに追加した。 ここで使ったSQL
MySQL パーティショニングで高速クエリーを実現！！ - Database JUNKY
MySQL(MariaDB)には、レンジパーティションってものがありまして、うーなんでしょ？ある規則にしがったデータをおのおののデータファイルに振り分けてくれるストレージエンジン的なものです。 データ領域が分割されるため、大量のデータを処理することによる性能上のボトルネックの発生を抑えられる MyISAMなど、テーブルサイズに上限がある場合でもそれ以上のデータを格納することが可能になる といった点です。 MySQLでもMariaDBでも、古いバージョンからある機能ではありますが、数百万規模のデータですとSQLの条件によって、読み込む分母のレコード数が少なくなるため、パフォーマンスは向上するわけですね。 サンプルテーブル こんなテーブルを作ってみました。非パーティショニングテーブルですね。つまり普通のテーブルです。これをベースにパーティショニング化を検証してみます。 | sample_tab
初心者でもDB設計やデータモデリングについて学べる7つのサイトと本 - paiza times
Photo by Samuel Mann こんにちは。谷口です。 「SQLは何となく書けるけど、DB設計はしたことない…」「DB設計について一度ちゃんと学んでおきたい…」という人は多いですよね。 DB設計とは、DBのデータモデル（DBの構成など）を作成する作業です。 DBを一から作ったり、テーブルを追加したりする際は、当然ですが「今あるデータが何となく格納できればそれでOK」ではありません。 テーブルは正規化できていないといけませんし、データの整合性も取れないといけません。また、効率よくデータが取れる構造になっているかどうかも重要です。 一から設計に取りかかるようなケースは少ないかもしれませんが、DBを取り扱うことがあるなら、こうしたDB設計の基本は知っておいて損はありません。むしろ自分が扱うDBの構造はきちんと知っておかないと、「なんか適当にSQL投げたらデータ取れたけど、正しく取れてる
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
PostgreSQLマニュアルのトランザクション分離レベル表を参照する際の注意点 - ぱと隊長日誌
はじめに PostgreSQLマニュアル「13.2. トランザクションの分離」にはトランザクション分離レベルの表が記載されています。この表の記載は9.4以前と9.5以降で変わっており、PostgreSQLの挙動が変わったと勘違いしてしまうかもしれません。ですが、マニュアルを注意深く読み解けば挙動に違いの無いことが分かります。本エントリではこれを解説します。 トランザクション分離レベルの表があらわすもの 注目すべきは表タイトルです。 バージョン 表タイトル 9.4 表 13-1. 標準SQLトランザクション分離レベル 9.5 表13.1 トランザクション分離レベル 9.4で記載されている表は「標準SQLトランザクション分離レベル」です。「PostgreSQLトランザクション分離レベル」ではありません。「標準SQLトランザクション分離レベル」とはANSI（米国国家規格協会）で定義されたトランザ
トランザクション分離レベルの古典的論文 A Critique of ANSI SQL Isolation Levels を読む - Hatena Developer Blog
こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー
トランザクションの設計と進化
3. Copyright©2016 NTT corp. All Rights Reserved. トランザクションの基本 トランザクションとは： データに対する一連の操作を一つにまとめた単位の事 トランザクションマネージャとは： 複数のトランザクションがACIDを守って走るよ うに管理する機構 A: Atomicity 結果がAll-or-Nothingとなる事 C: Consistency 一貫性を守る事 I: Isolation 過程が他の処理から見えない事 D: Durability 結果が永続化される事 Consistentな状態空間 Inconsistentな状態空間 Diskが取りうる全ての状態の空間 Atomicな遷移 4. Copyright©2016 NTT corp. All Rights Reserved. 何らかの実行順(スケジュール空間) 直列に実行した場合の結果
ゲームエンジニアのためのデータベース設計
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
リレーショナルモデルについて
Mikiya Okuno @nippondanji 第一正規形の条件は、テーブルがリレーションの性質を満たすこと。何故ならば、正規化はリレーショナルモデル上での設計理論なので、リレーションにしか適用できないから。だからNULLを含んではいけないし、繰り返しグループは許容されず、ドメインの設計がしっかりできていないといけない。 2015-03-31 22:23:44 Mikiya Okuno @nippondanji リレーショナルモデル上の設計理論は、対象がリレーションであるから実行できる。ということは、リレーションになれないデータには正規化も適用できない。なので「テーブルを全部正規化せよ」という方針は破綻してしまう。 2015-03-31 22:26:02 Mikiya Okuno @nippondanji テーブルを正規化すべきかの判断は実は至ってシンプル。それはリレーションか否か。あ
論理削除がデータを汚している - jfluteの日記
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
DB設計でこだわりたい三つの要素
http://connpass.com/event/10849/ しょぼちむにデータモデル設計について教えてくださいの会 #syoboben で話した資料です。Read less
O/Rマッパーによるトラブルを未然に防ぐ
2. copyright © 2014 kuwata-lab.com all rights reserved まえがき 現在、アプリケーション開発の現場では O/R Mapper (ORM) が普及しています。今後 も ORM を使った開発は、増えることはあっても減ることはないでしょう。 しかし ORM は、アプリケーション開発者にとっては便利でも、DB 管理者 (DBA) か らみたらトラブルの種でもあります。それが特にパフォーマンスに関する問題であるこ とが多いため、開発者と DBA が対立することも珍しくありません。 とはいえ、ORM による問題はすでに解決策が用意されている場合があります。本当の 問題は、すでに存在する解決策があまり知られていないことではないでしょうか。 そこで本発表では、ORM によってどのような問題が起こりやすいか、どう解決・予防 すればいいか、そして ORM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBアンチパターン // Speaker Deck
SQLでNULL同士の比較がfalseになるのは、何故ですか？
ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城