そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr

例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First

PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を（テーマは変えて）手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます！ 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

酔いどれ設計ナイト2019の発表資料です。

最近、あるプロジェクトのデータモデルをレビューして驚いた。マスター系テーブルのほとんどの主キーに「発効日」が含まれていたからだ。たしかに、レコードの有効期間をそのように管理することはある。しかしそこまで徹底されると異様だし、明らかな問題を含んでいた。あらためて「発効日」を主キーに含むモデリングについて考えてみたい。 まずは、発効日を含む「まとも」なモデリング例を見よう。図１では、{仕入先ID,商品ID,発効日}の組み合わせに「契約単価」が関数従属している。発注管理ではありきたりなシステム要件だ（発効年月を用いるほうが自然なのだが、ここではテーマに沿って発効日にしてある）。 図１．発効日を含むまともなモデル 契約仕入単価テーブル上の「失効日」は、同一の{仕入先ID＋商品ID}を持つレコード群の中で、当該レコードの発効日に後続する発効日が代入される論理フィールド（仮想フィールド）である。また、

3. 2 Agenda 1. 自己紹介 2. RDBMSで履歴データを扱う  スナップショットデータモデル  トランザクション時間データモデル  有効時間データモデル  バイテンポラルデータモデル 3. Javaからバイテンポラルモデルを容易に扱うReladomoの紹介 hashtag: #ccc_g3 4. 3 自己紹介 趣味：ドラム演奏 JavaOneコミュニティバンド Null Pointersで演奏経験あり（日本人初） Tech Lead @ FOLIO 伊藤 博志 Eclipse Collections：共同プロジェクトリード兼コミッター Reladomo：コントリビューター OpenJDK：コントリビューター JJUG CCC、Java Day Tokyo、JavaOne San Francisco登壇 2017年5月17日に株式会社FOLIO入社。 hashtag:

PHPカンファレンス2016の資料です http://phpcon.php.gr.jp/2016/

なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう

大したことは書いてありません。 気付いたことのメモ程度です。 『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 』を少し本屋で立ち読みしました。(ノットワーキングプアにあえいでいるので立ち読みしかできない(´・ω・｀)) この本の中で履歴系テーブルの扱い方というのに丸々一章が割り当てられていました。 だいたいこんなことが書かれてたと思う。 「時間軸と直交していない」という点は、履歴テーブルは過去の事実の集合で、データを取得する条件が変われば結果が異なるのは当たり前だと思うんだけども。— enum (@enum) 2015, 3月 16 たしかに、RDBMSでは履歴データというのは相性が悪い。 僕は陸上競技を見るのが好きなので、これのデータモデルをたまに考えたりしています。で、選手の氏名が変わることあるよなーと考えると、こ

RDBMSの知識不足を感じて以来、ここのところその勉強に力を入れている。学習方針は、 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ - kagamihogeのblog等の著書のミック氏が推奨している方法で、理論と実装の両面から進めている。俺の場合、後者は、Oracleで主にパフォーマンスの観点から基本的原則を確認することをやり、前者は、本書のような書籍を通して行っている。 本書は、コンピュータサイエンス初年度の講義の教科書を想定して作られている。そのため、コンパクトながらもトピックの網羅性、それになにより各章が独立していながらも本一冊を通してみると一貫性が保たれているのが素晴らしい。また、章から章への論理展開が極めて明快なので読みやすい。もっとも、これは俺がある程度の実務経験という下地と、まがりなりにもコンピュータサイエンスの学部経験があるからこそ、の部分もあるだろうけど

「仕様書によるアプリの動的制御」を実現したＯＳＳプラットフォーム「XEAD Driver」を使って、生産管理システムの開発を進めている。その複雑膨大な仕様の中から、生産管理システムに関する有用な知識をときどき紹介したい。今回は、品目毎の仕様のバリエーションを表すための工夫である「フィーチャ･オプション」について取り上げよう。 ■有効期間で構成を切り替える 工場で新製品が企画されて同じ仕様でずっと製造されることは稀で、さまざまな理由で仕様変更がなされる。これを「改版（かいはん）」という。改版にともなって、部品表や工程表の一部が切り替わることがある。これらの生産基本情報と改版とをどう統合するか。それは生産管理システムの設計課題のひとつだ。 同一製品向けに部品構成を適宜切り替えるためによく用いられるやり方が、部品表への「有効期間」の組み込みである。モデル１では、品目Ａに関してＢとＣとＤが構成品と

「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model

マスターテーブルには「比較的変化しないデータ」が登録されるが、Ｍ＆Ａが常態化した結果、取引先マスターあたりは頻繁に変わるようになった。社名や取引条件が変わるだけでなく、複数の取引先が１社に統合されることもある。 ここらへんは、マスターデータに「有効期間」を設けるべきかどうかの問題としてしばしば話題になる。「有効期間を含むテーブルとの参照関係」の記事でも触れたが、もう少し補足しておきたい。結論を先に言えば「ケースバイケースではあるが、それほど神経質になる必要はない」ということだ。 まず、有効期間を伴わない通常例を見よう。(1)では、すべての属性項目が主キーであるidに関数従属している。 (1)期間管理しないパターン [得意先GRP] GRP_id、グループ名、... ＋　　　　　　　　012　　 Ｍグループ ｜ └―…[得意先] 得意先id、社名、GRP_id、... 00001　　Ｍ社　　

前回に続いて動的参照関係に関する話題である。システムのコード量を減らすために、動的参照関係を「手続的」ではなく「宣言的」に扱える仕組みが必要だ――これは私の長年の主張なのだが、あらためてその意味を説明したい。 ■「手続的」に記述される動的参照関係 通常の参照関係（静的参照関係）にもとづく外部キー制約は、テーブル上の仕様として、ＤＤＬ(create table等のデータ記述命令)を用いて次の例のように宣言することで組み込める。 （１）静的参照関係の例 create table C (c ..., d ..., a ..., constraint C_PK primary key (c), constraint C_FK1 foreign key (a) references A(a)); いっぽう、動的参照関係にともなう外部キー制約については、ＤＤＬでは組み込めない。たとえば（２）で、Ｃ上の

一次識別子に「有効期間」が含まれることがある。そんなテーブルに対して関連を張ってゆくと正規化違反を生じてしまうケースがある。これを避けるためには「動的参照関係」の知識と、これに対応した開発基盤が必要だ。よほど単純なＤＢでない限り「動的参照関係」のデータ要件は出現するものなので、実務者としてはしっかり理解しておきたい。 まず、有効期間とキーとの関わりを整理しておこう。「商品値引テーブル」を例にした場合のモデリングパターンをいくつか挙げよう。{...}内はキー（一次識別子）を表している。 (1)開始日・終了日ともに属性 [商品] {商品ID},商品名,... ＋　　　12345　全自動漬物石ＴＳ１００ ｜ └―…[商品値引] {商品値引ID},商品ID,開始日,終了日,値引率,... 000001　　12345　07/01　08/31　　15 000002　　12345　08/01　09/30

定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて

買掛残高、売掛残高、在庫残高といった「残高テーブル」の構成に関して見る。とくに、残高テーブルと「統計情報」との関係について検討したい。 以前に取り上げた「取引実績テーブル」もそうなのだが、業務システムにとってごく基本的なテーブルであるにもかかわらず、どのように設計すべきかの議論がきわめて少ない。経理まわりの知識は書籍やサイトで豊富に手に入るが、これをＤＢ設計の問題と関連させた記事がほんとうに少ない。こんな粗末なエントリーでも、ないよりはマシに違いない。 まず買掛残高テーブルと売掛残高テーブルを見よう。基本的に次のような形をとる。取引先テーブルは「マスター管理サブシステム」に、仕入先テーブルは「買掛管理サブシステム」に、得意先テーブルは「売掛管理サブシステム」に所属する。仕入先と得意先は、取引先の拡張属性を保持する「サブタイプ」として位置づけられる。 ┌＋取引先 {取引先Ｃ} 名称,所在地,

データベース設計の際に「スタンプ属性」を載せることが設計標準とされているプロジェクトは多い。典型的なところでは、 ・レコード追加日時 ・レコード追加ユーザＩＤ ・レコード追加プログラムＩＤ ・レコード最終更新日時 ・レコード最終更新ユーザＩＤ ・レコード最終更新プログラムＩＤ といった項目をテーブル毎に載せ、更新系の処理が起こるたびにアプリに更新させる。捺印するように設定されるので「スタンプ属性」と呼ばれる。私も何も疑問を持たずに昔から従っていたものだ。 スタンプ属性の意義として、何か異状が生じた場合にそれらの値を調べることによって原因を特定しやすくなる、と説明される。しかし私のこれまでの開発経験の中で、そのように役に立った記憶が一度もない。 今やスタンプ属性は、「要らないもの」ではないにせよ「とりあえず載せるもの」ではなくなっている。それは「必要であれば載せ、必要でないなら載せなくていい