タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
DB設計の共有で疲弊してない？dbdocsのすゝめ
DB設計の管理や作成に疲弊してません？こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは？ dbdocsは、コードベース（DBML）でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
# 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab
Table users { id integer [pk] first_name varchar last_name varchar email varchar [not null] password varchar [note: 'Hashed password'] created_at datetime [not null, default: `now()`] updated_at datetime Indexes { email [unique, name: "ui_users_email"] } Note: 'table: users' } 上記のテーブル定義を dbdiagram.io の左側のコード記載部分に張り付けると右側にプレビューが表示されます。 以下は dbdiagram.io でのプレビューをした時の表示です。(Noteの箇所は説明のため加工しています) (1) Ta
アンチパターンで学ぶDB設計 - Qiita
はじめに データベース（DB）の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て
書籍案内 » 書籍ジャンル » ネットワーク・UNIX・データベース » データベース・SQLなど » 標準SQL＋データベース入門 ——RDBとDB設計、基本の力［MySQL/PostgreSQL/MariaDB/SQL Server対応］ Tech × Books plusシリーズ標準SQL＋データベース入門 ——RDBとDB設計、基本の力［MySQL/PostgreSQL/MariaDB/SQL Server対応］ この本の概要 「標準SQL」＆「データ設計」を土台に，SQL＆データベースの基本を学べる入門書。 「SQLでどんなことができるのか」「どんなときに便利なのか」「なぜそんなしくみになっているのか」一つ一つ，ステップアップしながら解説します。 本書の特徴は「標準SQL」準拠である点と文法の背景にある「データ設計」を丁寧に扱っている点です。SQL学習時の頻出ケースである，思った
セキュリティ、DB設計、パフォーマンス分析＿＿。Railsを使ったWebアプリ開発をパワーアップする書籍6冊 | レバテックラボ（レバテックLAB）
TOPコラムプロフェッショナルの技術書本棚セキュリティ、DB設計、パフォーマンス分析＿＿。Railsを使ったWebアプリ開発をパワーアップする書籍6冊 日本Rubyの会代表理事 高橋 征義 株式会社達人出版会代表取締役、一般社団法人日本Rubyの会代表理事。20世紀末よりWeb制作会社にてプログラマーとして勤務する傍ら、任意団体として日本Rubyの会を設立。後に法人化し、現在まで代表理事を務める。2010年よりITエンジニア向けの電子書籍の制作と販売を行う達人出版会を創業、現在まで代表取締役。ほか、RubyKaigiや技術書典の運営にも関わる。著書に『たのしいRuby』（共著）など。好きな作家は新井素子。 X：@takahashim keyboard_arrow_down はじめに keyboard_arrow_down 想定しているレベル感について keyboard_arrow_down
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、IT業界は4年目だけど開発はあんまりやったことがなかった人です 独学でDBとアプリ周りを勉強して最近開発現場へと行くことになったのですが、僕でもわかるようなやばいような事がかなりゴロゴロあって唖然とする毎日です(運が良いのか悪いのか…) 今日はそんな中の一つを紹介したいと思います #R無しRDB これには本当にびっくりしました どういうことかというと、外部キーをひとつも使ってなかったのです 分析系DBなのかと思いきや調べたり聞いたりして確認したところがっつり処理系、しかもコアな部分…ｗ データの不整合を許せない部分なのに外部キー
こんにちは！LAPRAS でエンジニアをしていますモロズミ (@Chanmoro) です。 約3ヶ月前になりますが、今年の6月9日に LAPRAS 公開設計レビュー「LAPRAS の DB 設計について」そーだいさんに相談してみた というオンラインイベントを開催しました。 事前収録した動画を参加者の方にご覧いただく形式でしたが、イベント公開から本日まではイベント参加者の方のみに限定公開としていました。しかし、とても参考になる内容をお聞きできたのでより多くのエンジニアの方の参考になればという思いと、イベントに参加ができなかった方から「ぜひ内容を知りたい」というお声を多くいただいていたことから、この度イベントの動画を全ての方にご覧いただけるように一般公開しました。 動画を頭から最後まで全部見ていただける方がイベント中のそーだいさんと私たちの会話の文脈がよりわかるのでオススメではあるものの、全部
さて、だいぶ久しぶりとなりますが、新著が出ます。序文を掲載しますので、購入にあたっての参考にしていただければと思います。初版は14刷りを数えたロングセラーで、第2版では主にクラウド対応や古くなった部分の最新化を行いまいした。 本書の初版が刊行されて10年以上が経過しました。その間にシステムとビジネスの世界にも予想だにしていなかった大きな地殻変動が起きました。ビッグデータという言葉はバズワードの域を脱して、企業の意思決定に使われるようになり、データ分析を専門に行うデータサイエンティストという職種も登場しました。クラウドの利用はもはや当たり前になり、むしろその応用方法を考えるハイブリッドクラウドやマルチクラウドの時代へと入りつつあります。そして何より、生成AIを中心とするAIの波があらゆる業界に押し寄せています。しかし、その中でも変わらなかったことがあります。それがデータベースの重要性です。変
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近システムエンジニアの出てくる海外映画をよく見る人です 今日は「本当にあったやらかしDB設計②【囚人番号テーブル】」に続いてびっくりしたことを紹介します #ロジカルクエリー これ、本当に良く見かけます どういうことかというと、本来アプリケーションで処理するべき機能を無理矢理クエリーに詰め込む、ということです ###何が悪いの？？ DBというのはデータという商品の入った、ただの倉庫です RDMBSという倉庫番が居るため、倉庫に入れる前に商品を検査することができます 倉庫番(RDBMS)は商品を倉庫に入れたり、取り出したりすること
どうも、GWのほうが用事が詰まって忙しかった人です(外出はしていないのですが…) 今日は本当にあったやらかしDB設計③【ロジカルクエリー】に続いてびっくりしたことを紹介します #テストチューニング 案件説明とかを受けると出会うことが意外と多いです どういうことかというと、本番より明らかにレコード数の少ないテーブルに対してチューニングを行う、ということです ###何が悪いの？？ データベースではとある計算に基づいてオプティマイザー(DBの脳みそのような部分)が実行計画を立てます 今主流なのはコストベースオプティマイザーです コストベースオプティマイザーでは、レコード当たりの平均容量や、テーブルのレコード数に基づいて計算を行い、実行計画を立てます レコード数が全く違うテスト用テーブルに対してチューニングを行うとどのようなことが発生するでしょうか ###問題 まず、チューニングといっても種類があ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、記事書くのにちょっとはまっちゃった人です 今日は「本当にあったやらかしDB設計①【R無しRDB】」に続いてまたびっくりしたことを紹介します #囚人番号テーブル 割とみんな使ってしまっているのではないでしょうか どういうことかというと、「XXX001」「XXX002」「XXX003」のようにテーブル名に囚人番号を付けている、ということです ###何が悪いの？？ 皆さん、クラス名や関数名を付けるときに悩んだ経験はありませんか？ 誤用を避けるためや可読性を向上させるためにも名前付けって大事ですよね これは**テーブル名にも同じことが言
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近満員電車に殺意を抱くようになった人です 今日は本当にあったやらかしDB設計⑥【見えない削除フラグ】に続いてびっくりしたことを紹介します #ステートフルDB そもそもステートフルDBとは何でしょうか ステートフルDBとは、状態遷移をDBが管理していることです DBの値を0や1にすることによってアプリケーションの挙動を変えようとしてしまっています 更に、更新頻度が異常に高いです 削除フラグについては前回も触れていますが、削除フラグに留まらず、○○フラグというものは手法としてはかなり悪手です 下記で説明されているので、是非見てみて
概要と投稿の背景 本投稿では、Firestore の DB 設計の基礎についてまとめます。 私は普段、都内の企業で Flutter エンジニアとして勤務しています。最近は Python/Django のバックエンド API や、Nuxt.js/Vue.js による Web フロントエンドのタスクにも取り組むことがあるのですが、業務レベルで Firestore を使いこなすような機会はありません。 ですが、趣味や個人で使用する範囲のアプリケーションを開発する際には、DB としての Firestore の便利さ・手軽さ・それでいて高機能な面に魅力を感じており、最近では NoSQL データベースや Firestore の特徴をうまく捉え、メリットを活かしながら、いろいろな規模のサービスを Firestore を用いて実現している例もかなりあるようです。 これから行おうとしている個人開発でも、Fi
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近夏バテ気味の人です 今日は[「本当にあったやらかしDB設計⑦【ステートフルDB】」] (https://qiita.com/bouitengineer12/items/325fec42c1c3bb385c64)に続いてびっくりしたことを紹介します #ファンクションDB そもそもファンクション(関数)とは… あるデータを渡すとあるデータを返す処理のことです 同じデータを渡せば、同じ結果が返ってくるという特徴があります ファンクションを利用する側は実際にどのような処理を行っているかを気にする必要がなく、inputとoutputだ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? どうも、最近コンビニ飯に飽きてきた人です 今日は「本当にあったやらかしDB設計⑤【第三正規化病】」に続いてびっくりしたことを紹介します #見えない削除フラグ そもそも削除フラグとは何でしょうか レコードに専用のカラムを用意し、その値が0であれば未削除、1であれば論理削除、とする手法のことです しかし、削除フラグは良い方法ではありません 下記でかなり詳細にわかりやすく説明されているので是非見てください SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 削除フラグは手間を増やしたりバグになる可能性を持ってはいますが、注意していれば
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事の目的 「テーブル設計、ほんとにこれがベストなのかな...?」 と思うことありますよね。シンプルなテーブル構造だと普通に正規化すれば問題なく運用できるんですが、ビジネスルールが複雑だったりするとあえて正規化を崩した設計を行うこともあります。ですが、「正規化を崩して何が嬉しいのか?」を論理的に考え、メリット・デメリットを考慮することによって、うまくトレードオフスライダーを調整することができるようになります。本記事では正規化も含めて、それぞれの正規化崩しがどのような目的のもと行われるのかを整理してみました。(なので、RAIDなどの物理
20190905_イチから理解するサーバーレスアプリ開発-サーバーレスアプリケーション向きのDB 設計ベストプラクティス
[イチから理解するサーバーレスアプリ開発] サーバーレスアプリケーション向きの DB 設計ベストプラクティス 2019.09.05 Amazon Web Services Japan K.K. Akihiro Tsukada, Startup Solutions Architect, Manager Version 2019-09-05 何者 • 塚⽥ 朗弘 @akitsukada • Startup Senior Solutions Architect • #startup #blockchain #dev #mobile #serverless • 好きなサービス︓Amazon Pinpoint 2 アジェンダ • サーバーレスアプリケーションとデータベースの種類 （および懸念事項と対案） • データベース設計プロセス 〜 RDB と Amazon DynamoDB 〜 • かんたんド
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 新卒の時に有名な本だったので一度読んだことはあったのですが 読んだ後に実践練習をしなかったので定着しないまま終わっていました。 2年目になり1年越しに読んだ感想と実際に簡易的なTwitterのDB設計を outputとして行ったので特に参考になった部分を5点ほど自分なりにまとています！！ 対象の方は DB設計の概要を知りたい方 DB設計学ぶか悩んでる方 DB設計学んだけどうまく利点を簡潔に言えない方 DB設計＝正規化だと思っている方 なので、具体的な正規化の方法などには突っ込みません。 ただ結構奥深いことが分かると思うので本買
どうも、近々引っ越しを考えていたのに在宅勤務が始まって引っ越す意味がなくなった人です 今日は「本当にあったやらかしDB設計④【テストチューニング】」に続いてびっくりしたことを紹介します 「正規化は第三正規化までやればいい！」と誰かが言ってたらしいです 僕の周りにはR無しRDBを見ても何も思わないような人ばっかりなので直接聞いたことはないですが…ｗ しかし、第三正規化まですればいい、というのは嘘です 必要に応じて更に正規化を行う必要があります ほとんどの場合、更に正規化をしたほうが良いです ※詳細について知りたい方は、是非SQLアンチパターンの付録としてついてきている「正規化のルール」を見てください 何が悪いの？？ 正規化という考え方に縛られてはいけません 一番重要なのはデータの不整合を防ぎつつ、データの冗長性も減らすことです 問題 第三正規化までやればいい！、という考えに縛られていると、冗
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本稿ではサブスクリプションサービスを提供するシステムの裏に潜む仕様を考察しながら、DBの設計を中心として設計を考察していきます。 サブスクリプションサービスは日本語で「定期購読」「会費」等と訳しますが、購読以外にも定期的に一定金額を自動で請求するシステム全般をさして「定額課金」とします。 本稿ではこれ以降、サブスクリプションについて「定額課金」と記します。 1. 毎月1回、固定の金額の請求をする 定額課金のサービスではサービス提供者から利用者へ「月額〇〇円」として毎月請求を出します。利用者は請求の支払う度にサービスを継続して利用できるよ
本書はプロのDBエンジニアであるミックさんが、データベース脱初級者を目指すエンジニアのために、一歩踏み込んだDB設計について解説した本です。この第2版では内容を最新の情報に更新し、クラウドDBにも対応できるようになっています。 内容としては、実際の開発現場で通用することを前提に、論理設計と物理設計、正規化とパフォーマンス、そして論理設計のアンチパターンや注意すべきグレーノウハウを取り上げています。「なんとなくわかっている」を「仕組みと理由がわかっている」にレベルアップさせ、DB設計をしっかり理解できる1冊です。 豊富なサンプルを参照し、練習問題も解きながら、長く使える確かなノウハウを身につけましょう。 目次 第1章 データベースを制する者はシステムを制す 第2章 論理設計と物理設計 第3章 論理設計と正規化～なぜテーブルは分割する必要があるのか？ 第4章 ER図～複数のテーブルの関係を表現
Pinterest、6人で1100万人支えてた時代のDB設計がヤバい Pinterestが6人のエンジニアで1100万人のユーザーを支えてたって話、控えめに言ってバグってるんだけど… それ以上にすごかったのが、その急成長をMySQLベースのアーキテクチャで乗り越えた戦い方だった。 MongoやCassandraを試しては不安定さに泣かされ、クラスタリングはリバランスが地獄。 何度もデータ破損の危機を迎えた末に選んだのが、シャーディング × キャッシュ × シンプル設計。 ユーザーごとに全データをひとつのシャードに集めて、ID構造でどのシャードにあるか即判定できる仕組みを用意。 さらに結合や制約はアプリケーション層に逃がして、 「システムは壊れる前提」で動くように組んでたのが本当にかっこいい。 もちろん失ったものもある。トランザクションとか、JOINとか。 でもそれ以上に、「崩壊せずスケール
スマホ専用、ブックマーク促進プログラム。(jquery) - ホームページ制作・システム構築・ＤＢ設計のユタシステム
スマホ用のランディングページを作る機会があって、そのクライアントからお気に入りに入れられるようなjavascriptプログラムを作って欲しいというオーダがあった。しかもホーム画面へ追加できるプログラムというオーダだ。 そのクライアントから以前も同じオーダがあったのだか、「スマホの場合、PCブラウザと違って、そのようなjavascriptは存在しない、それはスマホのネイティブ機能を触ることになり、そのようなプログラムは存在しないし、存在してはいけない」という回答をしていたのだが、先日「これこれ」と見せられたのが、 http://qiita.com/narikei/items/4240f03542f29e313989 だった。 確かにブクマを促進しているが、そこまでである。できることは促進まで。 ローカルストレージを使ったり、一週間に2回訪問しないと表示されなかったりとか制約がいろいろある。S
▼ 高画質版はこちらから（内容は同じものとなります） https://youtu.be/hothDfIeEOU ▼ ハッシュタグ #LAPRAS公開設計レビュー LAPRASでは、新規機能開発の際、そーだいさんのブログ等を参考にさせていただくことが多くあります。 我々が作った設計について、よりよいものとするために、DB設計の雄であるそーだいさんに相談する場を頂戴しました。 実際のLAPRASの求人機能のDB設計を元にそーだいさんに質問を投げかける形式で実施する勉強会をせっかくなので収録し、公開しようと思います。 ▼ イベントページ 公開設計レビュー「LAPRASのDB設計についてそーだいさんに相談してみた」 https://lapras.connpass.com/event/214564/ ■ 動画内で言及されている説明資料(PDF) https://drive.google.c
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 初期開発プロジェクトでDB設計を担当することになった際、今まで深く考えず使っていたインデックスの設計で思考の沼にハマりました。 ではどのような基準でインデックス設計を行うべきなのか？ 基本的な考え方と、設計初心者が迷ってしまいがちなポイントについてまとめてみました。 本記事の対象者 ・今までなんとなくDB操作を行なっていたがあらためてインデックスについて知りたい人 ・初めてデータベース設計に挑戦する人 １．そもそもインデックスって？ データベース内のデータを高速に検索するための仕組みです。データベースに大量のデータが格納されて
![[DB設計]インデックス設計の基本と注意点 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a03791e2f7be6ef139aa2548484e596f584bbb07/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCREIlRTglQTglQUQlRTglQTglODglNUQlRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTglQTglQUQlRTglQTglODglRTMlODElQUUlRTUlOUYlQkElRTYlOUMlQUMlRTMlODElQTglRTYlQjMlQTglRTYlODQlOEYlRTclODIlQjkmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTQ2ZTBhM2M2ZWI4Y2VhZWRlMzIwMzA0ZDgxYTUzZWYx%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBqdXN0YXdheTA4JnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0xZDliYTRlNGFlNDcwNzM3OGRhY2NjYTg2ZjkzOTQ5NA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-VklTSU9OQVJZIEpBUEFO%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D1089ade54500b1ea7a7cb91578028ad2)
在庫管理のDB設計
在庫は在庫テーブル(stocks)で管理し、各明細テーブルと1対1の関係にします。 明細テーブルに在庫テーブルの外部キーを設定するため、データ挿入の順序は 親テーブル→在庫テーブル→明細テーブル になります。 こうすることで明細テーブルと在庫テーブルの参照整合性を保証するようにしています。 在庫数の計算クエリ 在庫数を計算するSQL文を作成していきます。 最後に棚卸しが行われた日付以降の仕入、売上の商品数を集計します。 SELECT t1.id AS product_id , (MAX(CASE WHEN t2.process_type_id = 99 THEN t2.quantity ELSE 0 END) + SUM(CASE WHEN t2.transaction_type_id = 2 THEN t2.quantity ELSE 0 END) - SUM(CASE WHEN t2.
わっきゃお 1.DBを制すものがシステムを制す データが先、プログラムは後。 1-4.設計工程とデータベース スキーマは基本的に3つのレベルで成り立っている。 1.外部スキーマ（外部モデル） 2.概念スキーマ（論理データモデル） 3.内部スキーマ（物理データモデル） 1.外部スキーマ いわゆる「ユーザーから見たdb」である 画面のUIや入力データなども外部スキーマに含まれる 2.概念スキーマ 「開発者から見たdb」 dbに保持するデータの要素および、データ同士の関係を記述するスキーマ 3.内部スキーマ 概念スキーマで定義された論理データモデルを、具体的にどのようにデータベース管理システム内部に格納するかを定義するスキーマです。 小さいシステムだと概念スキーマをあえて作らずに、外部スキーマと内部スキーマだけ定義することがある、しかし、大きいシステムで2層スキーマを定義してしまうと、スキーマ同
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
達人に学ぶDB設計 徹底指南書 作者:ミック発売日: 2013/08/07メディア: Kindle版 2020年の年末から、フィヨルドブートキャンプ内で『達人に学ぶDB設計 徹底指南書』の輪読会をやった。 Slack で輪読会の話が出たときに、DB関係の本を読みたい！と言ったところ、フィヨルドブートキャンプのアドバイザーであるベテランエンジニアの方がメンターをやってくださることになり、開催に至った。 初学者で集まって読むのも楽しく一人で読むよりは知識も深まるが、その分野の知識や経験が豊富な方に参加してもらえたことで、さらに何倍も有意義な会になったと思う。 ものすごく勉強になったのを独り占めするのはもったいないのと、自分の復習のためにも特に印象に残ったところだけでも書き残しておくことにしたい。 学んだこと〜データベースを制する者はシステムを制す データベースは事実を保存するもの 可能な限り
わっきゃお 1.DBを制すものがシステムを制す データが先、プログラムは後。 1-4.設計工程とデータベース スキーマは基本的に3つのレベルで成り立っている。 1.外部スキーマ（外部モデル） 2.概念スキーマ（論理データモデル） 3.内部スキーマ（物理データモデル） 1.外部スキーマ いわゆる「ユーザーから見たdb」である 画面のUIや入力データなども外部スキーマに含まれる 2.概念スキーマ 「開発者から見たdb」 dbに保持するデータの要素および、データ同士の関係を記述するスキーマ 3.内部スキーマ 概念スキーマで定義された論理データモデルを、具体的にどのようにデータベース管理システム内部に格納するかを定義するスキーマです。 小さいシステムだと概念スキーマをあえて作らずに、外部スキーマと内部スキーマだけ定義することがある、しかし、大きいシステムで2層スキーマを定義してしまうと、スキーマ同
はじめに こんにちは、会員システムグループの渡邊です。 社内にNotionが導入されて2年以上立ちました。 最近は何でもNotionで管理すればいいじゃんという気持ちになってきていて、試しにDB設計をNotionで行ってみたのでその感想を書いていきます。 範囲 今回はDB設計におけるエンティティ抽出とデータモデリング、ER図作成までをNotionだけで行います。 エンティティ抽出とモデリング NotionはMermaid記法が使えるため、こちらを使ってエンティティ抽出を行うことが可能です。 しかし、いきなりコードベースで図を作成するのは難易度が高いため、今回はdraw.ioを使ってエンティティ抽出とデータモデリングを行っていきます。 draw.io for Notionという拡張機能を使うことで、SVGファイルをNotionに貼り付けるだけで直接draw.ioの操作を行うことができます。
生成 AI アプリケーション開発に評価の仕組みを導入して精度向上を実現した話：DB 設計レビュー自動化の取り組み
こんにちは。 DBRE チーム所属の @p2sk と @hoshino です。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベース（DB）に関する課題解決やプラットフォーム開発に取り組んでいます。 本記事では、AWS の生成 AI サービス Amazon Bedrock を活用し、Serverless アーキテクチャで構築した DB テーブル設計の自動レビュー機能を紹介します。この機能は GitHub Actions と連携し、プルリクエスト（PR）がオープンされると AI が自動でレビューし、修正案をコメントとして提案します。また、生成 AI アプリケーションの評価をどのように設計・実装したかも解説します。LLMOps のライフサイクルにおける 3 つのフェーズ（モデル選定、開発、運用）ごとに採用した評価手法を説明し、特に運
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[連載] ネットワーク基礎 第0回 インフラエンジニアとネットワークエンジニアの本当の違い - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/cbf13d44b60207389e257aa00ef93a0c1a8132c4/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnMzLWFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkZxaWl0YS1pbWFnZS1zdG9yZSUyRjAlMkYzNTIxNTczJTJGMTUxZWYzYTNiNGRiNDcwNTU1ODM1MDZlZjExODNiM2M4YzQyOGJhMSUyRnhfbGFyZ2UucG5nJTNGMTc1MTE0NzI1Nz9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz1jOWM0MTA5Njc3MjNlMTVkODc1NGY2OWIxMDI2MThlNw%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D90c04cd81ffbe8678870c7fd7b85f70f%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJUU5JTgwJUEzJUU4JUJDJTg5JTVEJTIwJUUzJTgzJThEJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgzJUFGJUUzJTgzJUJDJUUzJTgyJUFGJUU1JTlGJUJBJUU3JUE0JThFJTIwJUU3JUFDJUFDMCVFNSU5QiU5RSUyMCVFMyU4MiVBNCVFMyU4MyVCMyVFMyU4MyU5NSVFMyU4MyVBOSVFMyU4MiVBOCVFMyU4MyVCMyVFMyU4MiVCOCVFMyU4MyU4QiVFMyU4MiVBMiVFMyU4MSVBOCVFMyU4MyU4RCVFMyU4MyU4MyVFMyU4MyU4OCVFMyU4MyVBRiVFMyU4MyVCQyVFMyU4MiVBRiVFMyU4MiVBOCVFMyU4MyVCMyVFMyU4MiVCOCVFMyU4MyU4QiVFMyU4MiVBMiVFMyU4MSVBRSVFNiU5QyVBQyVFNSVCRCU5MyVFMyU4MSVBRSVFOSU4MSU5NSVFMyU4MSU4NCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTk2NjZkMmExOGZmZGEzNTMyODFmMTA2YWI5Nzc1Mjgw%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBTaGlnZW1vcmlNYXNhdG8mdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz01NWYyMTRhNGU0YmFjYTk5NGNmOWVkZTUyYzI2YzM5Zg%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Df0436dc778bfabf49080488d04ac4fdf)
決済システムの残高管理周りの DB 設計と戦略 - カンム テックブログ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
テーブル・DB設計するときの極意 - Qiita
後輩エンジニアを絶望させるDB設計方法4選 - Qiita
標準SQL＋データベース入門 ——RDBとDB設計、基本の力［MySQL/PostgreSQL/MariaDB/SQL Server対応］
本当にあったやらかしDB設計①【R無しRDB】 - Qiita
「LAPRASのDB設計についてそーだいさんに相談してみた」イベントレポート | LAPRAS株式会社
新著が出ます - 『達人に学ぶDB設計徹底指南書 第2版』｜ミック
本当にあったやらかしDB設計③【ロジカルクエリー】 - Qiita
本当にあったやらかしDB設計④【テストチューニング】 - Qiita
本当にあったやらかしDB設計②【囚人番号テーブル】 - Qiita
本当にあったやらかしDB設計⑦【ステートフルDB】 - Qiita
Firebase 公式動画から『Firestore の DB 設計の基礎』を学ぶ - Qiita
本当にあったやらかしDB設計⑧【ファンクションDB】 - Qiita
本当にあったやらかしDB設計⑥【見えない削除フラグ】 - Qiita
【DB設計】現場で使う正規化崩しのパターン - Qiita
達人に学ぶDB設計入門がよかったので全力で勧めてみる - Qiita
本当にあったやらかしDB設計⑤【第三正規化病】 - Qiita
サブスクリプション（定額課金）サービスのDB設計 - Qiita
脱初級者を目指すデータベースエンジニアのための教科書 『達人に学ぶDB設計徹底指南書 第2版』発売
Pinterest、6人で1100万人支えてた時代のDB設計がヤバい
公開設計レビュー「LAPRASのDB設計についてそーだいさんに相談してみた」
[DB設計]インデックス設計の基本と注意点 - Qiita
【サルが書く】DB設計を達人に学んだのでまとめてみた - Qiita
後輩エンジニアを絶望させるDB設計方法4選 - Qiita
『達人に学ぶDB設計 徹底指南書』輪読会をやった - No Solution for Life
【サルが書く】DB設計を達人に学んだのでまとめてみた
Notionでいい感じにDB設計を行う方法 - NIFTY engineering
www.nhk.or.jp
nakaiyuhi.com
akiko42life.hatenablog.com
daturyoku-pukapuka32.hatenablog.com
www.nhk.or.jp
www.nhk.or.jp