1 - 25 件 / 25件
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
DB設計の管理や作成に疲弊してません?こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは? dbdocsは、コードベース(DBML)でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
# 実装の参考資料 - 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設計は「属性」と「関係」の2つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
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
はじめに こんにちは、SRE部カート決済SREブロックの伊藤(@_itito_)です。普段はZOZOTOWNのカート決済機能のリプレイス・運用・保守に携わっています。また、データベース(以下DB)領域でのテックリードを担っており、DBREとしてDB周りの運用・保守・構築に関わっています。 弊社のDBRE活動については、以前次の記事で紹介しました。 techblog.zozo.com この活動の中で、DBのテーブル定義の設計レビューを行っています。この運用にAWSのBedrockを用いて自動化を組み込んだ取り組みを紹介します。 目次 はじめに 目次 背景・課題 DB設計レビューの課題 レビュー工数と「トイル化」の問題 開発者によるガイドライン遵守度のばらつき DBレビューフローの変更方針 自動レビューBotの設計・実装 技術選定 作成するレビューシステムとSlackとの連携 Confluen
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
こんにちは!LAPRAS でエンジニアをしていますモロズミ (@Chanmoro) です。 約3ヶ月前になりますが、今年の6月9日に LAPRAS 公開設計レビュー「LAPRAS の DB 設計について」そーだいさんに相談してみた というオンラインイベントを開催しました。 事前収録した動画を参加者の方にご覧いただく形式でしたが、イベント公開から本日まではイベント参加者の方のみに限定公開としていました。しかし、とても参考になる内容をお聞きできたのでより多くのエンジニアの方の参考になればという思いと、イベントに参加ができなかった方から「ぜひ内容を知りたい」というお声を多くいただいていたことから、この度イベントの動画を全ての方にご覧いただけるように一般公開しました。 動画を頭から最後まで全部見ていただける方がイベント中のそーだいさんと私たちの会話の文脈がよりわかるのでオススメではあるものの、全部
さて、だいぶ久しぶりとなりますが、新著が出ます。序文を掲載しますので、購入にあたっての参考にしていただければと思います。初版は14刷りを数えたロングセラーで、第2版では主にクラウド対応や古くなった部分の最新化を行いまいした。 本書の初版が刊行されて10年以上が経過しました。その間にシステムとビジネスの世界にも予想だにしていなかった大きな地殻変動が起きました。ビッグデータという言葉はバズワードの域を脱して、企業の意思決定に使われるようになり、データ分析を専門に行うデータサイエンティストという職種も登場しました。クラウドの利用はもはや当たり前になり、むしろその応用方法を考えるハイブリッドクラウドやマルチクラウドの時代へと入りつつあります。そして何より、生成AIを中心とするAIの波があらゆる業界に押し寄せています。しかし、その中でも変わらなかったことがあります。それがデータベースの重要性です。変
概要と投稿の背景 本投稿では、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? 本記事の目的 「テーブル設計、ほんとにこれがベストなのかな...?」 と思うことありますよね。シンプルなテーブル構造だと普通に正規化すれば問題なく運用できるんですが、ビジネスルールが複雑だったりするとあえて正規化を崩した設計を行うこともあります。ですが、「正規化を崩して何が嬉しいのか?」を論理的に考え、メリット・デメリットを考慮することによって、うまくトレードオフスライダーを調整することができるようになります。本記事では正規化も含めて、それぞれの正規化崩しがどのような目的のもと行われるのかを整理してみました。(なので、RAIDなどの物理
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エンジニアであるミックさんが、データベース脱初級者を目指すエンジニアのために、一歩踏み込んだDB設計について解説した本です。この第2版では内容を最新の情報に更新し、クラウドDBにも対応できるようになっています。 内容としては、実際の開発現場で通用することを前提に、論理設計と物理設計、正規化とパフォーマンス、そして論理設計のアンチパターンや注意すべきグレーノウハウを取り上げています。「なんとなくわかっている」を「仕組みと理由がわかっている」にレベルアップさせ、DB設計をしっかり理解できる1冊です。 豊富なサンプルを参照し、練習問題も解きながら、長く使える確かなノウハウを身につけましょう。 目次 第1章 データベースを制する者はシステムを制す 第2章 論理設計と物理設計 第3章 論理設計と正規化〜なぜテーブルは分割する必要があるのか? 第4章 ER図〜複数のテーブルの関係を表現
Pinterest、6人で1100万人支えてた時代のDB設計がヤバい Pinterestが6人のエンジニアで1100万人のユーザーを支えてたって話、控えめに言ってバグってるんだけど... それ以上にすごかったのが、その急成長をMySQLベースのアーキテクチャで乗り越えた戦い方だった。 MongoやCassandraを試しては不安定さに泣かされ、クラスタリングはリバランスが地獄。 何度もデータ破損の危機を迎えた末に選んだのが、シャーディング ×ばつ キャッシュ ×ばつ シンプル設計。 ユーザーごとに全データをひとつのシャードに集めて、ID構造でどのシャードにあるか即判定できる仕組みを用意。 さらに結合や制約はアプリケーション層に逃がして、 「システムは壊れる前提」で動くように組んでたのが本当にかっこいい。 もちろん失ったものもある。トランザクションとか、JOINとか。 でもそれ以上に、「崩壊せずスケール
スマホ用のランディングページを作る機会があって、そのクライアントからお気に入りに入れられるような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操作を行なっていたがあらためてインデックスについて知りたい人 ・初めてデータベース設計に挑戦する人 1.そもそもインデックスって? データベース内のデータを高速に検索するための仕組みです。データベースに大量のデータが格納されて
在庫は在庫テーブル(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.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? わっきゃお 1.DBを制すものがシステムを制す データが先、プログラムは後。 1-4.設計工程とデータベース スキーマは基本的に3つのレベルで成り立っている。 1.外部スキーマ(外部モデル) 2.概念スキーマ(論理データモデル) 3.内部スキーマ(物理データモデル) 1.外部スキーマ いわゆる「ユーザーから見たdb」である 画面のUIや入力データなども外部スキーマに含まれる 2.概念スキーマ 「開発者から見たdb」 dbに保持するデータの要素および、データ同士の関係を記述するスキーマ 3.内部スキーマ 概念スキーマで定義された論理データ
エンジニアの格闘 エンジニアのみなさんはかつてひどいコードや設計と直面し、それと格闘したことでレベルアップした経験はあるでしょう。 つまり、先輩エンジニアたるものクソコードやクソ設計を残して、後輩エンジニアのレベルアップに寄与するのは義務だと言っても過言ではありません(?) 今回はDB設計に焦点をあてて、そのように絶望させる設計の残し方を記しておきます。 初めての投稿なのでレベル的にはかなり初歩になっています。 ↑きっと彼も立派なエンジニアになった時感謝してくれるでしょう 1) 必要な正規化を行わない エンジニアという不思議な不思議な生き物は処理の共通化等なにかと処理をまとめたがる習性があります。 以下のように著者テーブルと書籍テーブルがあるとします。 書籍 書籍ID 書籍名 著者ID
達人に学ぶDB設計 徹底指南書 作者:ミック発売日: 2013年08月07日メディア: Kindle版 2020年の年末から、フィヨルドブートキャンプ内で『達人に学ぶDB設計 徹底指南書』の輪読会をやった。 Slack で輪読会の話が出たときに、DB関係の本を読みたい!と言ったところ、フィヨルドブートキャンプのアドバイザーであるベテランエンジニアの方がメンターをやってくださることになり、開催に至った。 初学者で集まって読むのも楽しく一人で読むよりは知識も深まるが、その分野の知識や経験が豊富な方に参加してもらえたことで、さらに何倍も有意義な会になったと思う。 ものすごく勉強になったのを独り占めするのはもったいないのと、自分の復習のためにも特に印象に残ったところだけでも書き残しておくことにしたい。 学んだこと〜データベースを制する者はシステムを制す データベースは事実を保存するもの 可能な限り
はじめに こんにちは、会員システムグループの渡邊です。 社内にNotionが導入されて2年以上立ちました。 最近は何でもNotionで管理すればいいじゃんという気持ちになってきていて、試しにDB設計をNotionで行ってみたのでその感想を書いていきます。 範囲 今回はDB設計におけるエンティティ抽出とデータモデリング、ER図作成までをNotionだけで行います。 エンティティ抽出とモデリング NotionはMermaid記法が使えるため、こちらを使ってエンティティ抽出を行うことが可能です。 しかし、いきなりコードベースで図を作成するのは難易度が高いため、今回はdraw.ioを使ってエンティティ抽出とデータモデリングを行っていきます。 draw.io for Notionという拡張機能を使うことで、SVGファイルをNotionに貼り付けるだけで直接draw.ioの操作を行うことができます。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く