決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
初心者でもDB設計やデータモデリングについて学べる7つのサイトと本 - paiza times
Photo by Samuel Mann こんにちは。谷口です。 「SQLは何となく書けるけど、DB設計はしたことない…」「DB設計について一度ちゃんと学んでおきたい…」という人は多いですよね。 DB設計とは、DBのデータモデル（DBの構成など）を作成する作業です。 DBを一から作ったり、テーブルを追加したりする際は、当然ですが「今あるデータが何となく格納できればそれでOK」ではありません。 テーブルは正規化できていないといけませんし、データの整合性も取れないといけません。また、効率よくデータが取れる構造になっているかどうかも重要です。 一から設計に取りかかるようなケースは少ないかもしれませんが、DBを取り扱うことがあるなら、こうしたDB設計の基本は知っておいて損はありません。むしろ自分が扱うDBの構造はきちんと知っておかないと、「なんか適当にSQL投げたらデータ取れたけど、正しく取れてる
「SQLアンチパターン」を避けるためのチェックリスト（サマリー版） - log4ketancho
これまで「SQLアンチパターン」本のまとめを書いてきました。 「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト④（アプリケーション設計編） - log4ketancho この記事は、自分用のチェックリストとして、これまでの記事をサマライズしたものになります。本にこのチェックリストが書かれているわけではなく、個人的に解釈したものになりますが、もしよろしければ DB 設計の一助にしていただければ幸いです。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
[講義] データベース設計の講義資料を公開します - YoheiM .NET
こんにちは、@yoheiMuneです。 G's ACADEMY TOKYOさんでいくつか講義を担当させていただいているのですが、新しくデータベース設計の講義を行ったので、そのスライドを公開したいと思います。 講義内容 この講義は、初めてプログラミングを学んだ方向けで、卒業制作で作るアプリケーションのデータベース設計ができるようになることを目標にしています。特に論理設計を扱い、アプリケーションで扱うデータ構造を読み解いて理解できるようになります。 論理設計では以下の項目を扱います。 データの理解 エンティティの定義 リレーションシップの定義 データ項目の定義 列の定義 少しでも参考になればと思い、もし気になった方はチラッと見てみて頂けたら嬉しいです。 編集後記 データベース設計についていざ講義を作ろうとするとなかなかアイデアがまとまりませんでした。いつもやっていることをいざ明文化しようとする
![[講義] データベース設計の講義資料を公開します - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/c8f8646166b23c50571aee45678e8d77a47d399e/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F546.png)
1日に100万レコード増える場合のテーブル設計
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
DB設計でこだわりたい三つの要素
http://connpass.com/event/10849/ しょぼちむにデータモデル設計について教えてくださいの会 #syoboben で話した資料です。
今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ
あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
PHPMatsuri2013で発表した資料を公開しました「ソーシャルゲーム案件におけるDB分割のPHP実装～とにかく分割ですよ。10回じゃ足りない。20回くらい分割。～」｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ホーム 技術ブログ PHPMatsuri2013で発表した資料を公開しました「ソーシャルゲーム案件におけるDB分割のPHP実装～とにかく分割ですよ。10回じゃ足りない。20回くらい分割。～」 PHPMatsuri2013で発表した資料を公開しました「ソーシャルゲーム案件におけるDB分割のPHP実装～とにかく分割ですよ。10回じゃ足りない。20回くらい分割。～」 記事を書くのは初めてになります。sasakiです。 2013年7月14日から15日にかけて、PHP Matsuri 2013が開催されました。 今回は北海道開催という事で弊社もスポンサーとなり、社員の何名かはスタッフとして開催に協力しました。 また、スポンサー枠でセッション時間を一コマ頂き 「ソーシャルゲーム案件におけるDB分割のPHP実装 ～とにかく分割ですよ。10回じゃ足りない。20回くらい分割。～」 と題した発表を行いましたの
ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI
これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
実行可能な仕様書は“設計できるプログラマ”が書く
実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（1/3 ページ） 前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。 DBを正規化することのインパクト 前回、業務システムに含まれる機能（データ処理プログラム）をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ（アプ
【DB概論】データベースシステムに求められる要件
【DB概論】データベースシステムに求められる要件：できるエンジニアになる！ ちょい上DB術・基礎編（1） デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。 デキるエンジニアになるためには、DB技術の基礎は必須です。 「使える」システムを構築するには、データベース設計がと非常に重要です。先人が遭遇したトラブルを避けられるかどうか、システム構築やアプリケーション開発が成功するか否かは、データベース設計にかかっているところが大きいです。 本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。システム構築において「どの工程で、どのような観点からデータ
DB設計の神ツール「ERMaster」なら、ここまでできる
DB設計の神ツール「ERMaster」なら、ここまでできる：ユカイ、ツーカイ、カイハツ環境！（11）（1/3 ページ） 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか？ いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI（ユーザーインターフェイス）に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。本稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや
マイクロソフト萩原正義氏MIJS講演「スケールアウト設計における問題点の考察と分析手法の提案」 : 小野和俊のブログ
昨年末にMIJSのコンソーシアム内での交流会があり、前回のはてな伊藤さん講演に続き、理事会の方から講演者の選定とコンタクトを依頼されたので、マイクロソフトの萩原さんに「クラウドの時代のデータモデリング」の講演をお願いした。 今回萩原さんに講演をお願いしたのは、以前参加させていただいたマイクロソフト系のイベントでの萩原さんの講演が大変興味深い内容だったからだ。 以下、今回の講演を聞きながら私がメモした内容である。 「スケールアウト設計における問題点の考察と分析手法の提案」 現在マイクロソフトでクラウドの技術のうち、開発の現場に対して、どういうやり方をしなければいけないかを提案する仕事をしている。 今日お話しする内容は、インターネットや書籍で紹介されているものよりも、深いところを話していきたい。とはいえ1時間という短い時間なので、ポイントを絞って話をしていきたい。マイクロソフトはWindows
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【旧版・説明欄参照ください】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス
アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2