タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
「基本から学ぶテーブル設計 超入門！」 https://modeling-how-to-learn.connpass.com/event/242944/ の発表資料。 - ２つの設計スタイルの違いを理解する - 何を記録するか（資源・活動・当事者・規程） - どう記録するか（テーブルの役割…
![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…
「みんなさぁ、データベースって何で学んだ？」単なるSQLやテーブル設計のいろはとかではなく『データベース』そのものの勉強についての質問に有益な情報が集まる
𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ @ellnore_pad_267 みんなさぁ・・・ データベースって何で学んだ？ あんま学ぶチャンスなくね？ そんなことはないか？ 単なる SQL やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 2024-09-09 20:18:38 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ @ellnore_pad_267 > 単なる SQL やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 この部分読めてない奴が一定数おる？？？？ 2024-09-10 10:12:46
基本から学ぶ テーブル設計 超入門！ 〜データモデリングとテーブル設計の基本を学ぼう〜 https://modeling-how-to-learn.connpass.com/event/242944/ にてお話した際のプレゼン資料です。 入門者に向けて、テーブルを設計する上でモデリングすると…
テーブル設計を遅らせることでユーザー体験の最大化を狙える!?米国式最新開発手法「ADD」とは。。 - Qiita
初めまして、記事に訪問いただきありがとうございますm(_ _)m 今までのプロジェクトでありがちな言い訳。。。 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります なんでこんなことが起こってしまうのか もう15年も前になるPOA vs DOA論争の結果、データ整合性のためにテーブル設計を一番初めに済ませることが一般的になりました。 【初級】ゼロから学ぶDOA 第1回 ですがこのやり方では実際の画面の動きをお客様が見る前に仕様を決めて、 そ
DynamoDBのテーブル設計に最適！NoSQL WorkbenchのData modelerで今度こそDynamoDBを使いこなす！ | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 今回はAWSが提供しているDynamoDB用のアプリ「NoSQL Workbench」の機能を使ってデータモデリングする流れを解説します。 最近案件でテーブル設計を再検討する必要がありNoSQL Workbenchを使ったところ、サンプルデータを入れながら設計が正しいか検証でき非常に便利だったので紹介します。 他の記事でもアプリの紹介はありますが本記事ではデータモデリングに絞って解説を行います。題材として多対多のデータをモデリングしながら設計する方法を紹介します。 本記事を読めば今までDynamoDBのデータ設計に悩んでいた方の検討時間をかなり減らすことができます。自分ももっと早く「NoSQL WorkbenchのData modeler はこう使って欲しい！」という記事があれば良かったなあと思ったので記事にしました。 NoSQL Workbench
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし3 「テーブル設計のスタイル」 - asken テックブログ
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし3ページ目です。最初からお読み頂く場合は、こちらから御覧ください。 資料 増田さんの講演資料 質疑応答モデル なぜこの場を作ったのか 書き起こしリンク パート1「良い設計を目指す」 パート2「設計スタイルの選択とクラス設計のスタイル」 パート3「テーブル設計のスタイル」（本記事） パート4「開発のやり方と設計スキルと補足資料」 パート5「質疑応答」 目次 テーブル設計のスタイル テーブル設計の分かれ道 イミュータブルモデルを選ぶ イミュータブルデータモデルの効果 イミュータブルに設計したテーブルの特徴 プログラムが単純かつ明快になる 2022/08/24 追記 イミュータブルデータモデルについてより詳し知りたい方は、WEB+DB Press Vol.130 も是非お読みくださいませ！ パート3の内容（イミュータブルデータモデル）につ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめまして、himakuroです。 2017年ぐらいからQiitaに記事を投下しようと考えていたのですが、なかなか筆が乗らずようやく初投稿です 軽く自己紹介をしておくと、普段は社内SEとしてPHP、Ruby、Golangを書いたり、 趣味の個人ブログ方ではプログラミング初心者に向けた記事や雑記的なものを書いたりしています。 今回は記念すべき1つ目の記事と言う事で 僕が普段テーブル設計（主に命名）で気をつけている6つの事を書きました。 僕の好みも含まれていますが、初心者の方がテーブルやカラム名を決める際の参考になればなと思います。 テー
Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 この文書は、AWS ヒーローであるAlex DeBrie によるゲスト投稿です。 Amazon DynamoDB について学ぶ人にとって、シングルテーブル設計という考え方は、最も心を揺さぶるコンセプトの1つです。DynamoDBのテーブルは、エンティティごとにテーブルを持つというリレーショナルデータベースのような概念ではありません。多くの場合、1つのテーブルに複数の異なるエンティティを含みます。 DynamoDBのシングルテーブルに関するデザインパターンについては、DynamoDBのデベロッパーガイドを読む、re:Inventのトークやその他のビデオを見る、私が執筆した本をチェックするなどで理解することができます。シングルテーブル設計の賛否両論に特に焦点を当て
Amazon DynamoDB のテーブル設計で悩んだら最初に読もう -これだけ知ればある程度の検索には対応できる-
こんにちは、広野です。 Amazon DynamoDB は NoSQL と言われる類のデータベースですが、検索条件の指定に限りがあり、また検索条件を増やすための設定が構築後に追加できない箇所があります。そのため、最初のテーブル設計の時点で実際に使用する検索条件を意識して構築しないと、最悪データベースの作り直しになってしまいます。 そこで、簡易な検索要件であればこれだけ押さえておけば対応できる！という例をつくってみました。Amazon DynamoDB のテーブル設計でお悩みの方に読んで頂けたらと思います。 本記事では、クエリーによる検索について言及します。フィルターは全件取得の後に条件でデータをフィルターするので、データ数や実行回数が多いと課金が高額になる恐れがあります。また、データ量が多いとレスポンスが一気に遅くなるので、実用的でなくなるケースがあります。あくまで、データ量が少ないときの
DynamoDBで多対多のテーブル設計 - 或る阿呆の記
DynamoDBの設計を始めてからたいていの人が引っかかるであろう、DynamoDBにおける多対多(many-to-many relationship)の対応について、つらつらとメモする。 AWSのドキュメントにベストプラクティスがあるので、それについて書き連ねるだけではある。 DynamoDBの2番目くらいの壁 ウキウキしながらDynamoDBを始めた後、だんだん「あれ？これクエリめっちゃ厳しくない？」ということに気づき、その制約に愕然とするパターンの一つが、いわゆる多対多の実装だと思う。RDBなら中間テーブル作ってリレーション貼って正規化すればよし、だけれど、同じことをDynamoDBですると、めちゃくちゃクエリ投げないといけないことにハタと気づく。すごく思う。joinしたい。 もちろんDynamoDBにjoinはない。ああなるほど、KVS、Key Value Storeってそういう…
データベースを止めずにテーブル設計を変更したい
プラハチャレンジにて、受講生チームから次のような質問がありました。 データベース（RDB）のテーブル設計を変更したい テーブル設計を変更する作業中にアプリケーションからデータベースへのアクセスが発生すると困る メンテナンス期間を設けアプリケーションを一時的に停止することで、データベースへのアクセスを防ぐことはできる データベースを止めることなくテーブル設計を変更する方法はないか この質問に対して、Expand and Contract patternを紹介しました。 この記事では、Expand and Contract patternを用いてテーブル設計を移行する方法を例を交えて紹介します。 ことのおこり プラハチャレンジのデータベース設計の課題の1つに、次のようなものがあります。 「漫画・小説といった書籍を保存してそれらにコメントできるようなサービス」（以下、書籍サービスとします）のデー
Introduction AWSが提供するDWHサービス、Amazon Redshift。 全世界での採用企業は数万社を超えており、弊社も国内において多くのお客様に導入のご支援をさせて頂きました。 RedshiftはAWSエコシステムとの親和性が高く、AWSを既にご利用のお客様は導入の敷居が低いDWHサービスとなっております。 しかし、適切なテーブル設計を行わなければパフォーマンスを全く発揮できません。 不適切なテーブル設計をしてしまったが故、「バッチ処理が当初想定していた時間で終わらない」等、弊社にご相談頂いたお客様も数多くいらっしゃいます。 では、Redshiftを扱うにあたってどのようなテーブル設計を行えば良いのか。 本記事では、パフォーマンスの向上に繋がるテーブル設計のポイントを3つ、ご紹介致します。 1. ソートキー（SortKey） ソートキー（SortKey）は、テーブルのデ
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
SQLAlchemyとは SQLAlchemyは、PythonのORMの1つで、Pythonでは一番有名なORMでもあります。ORMとしては、SQLインジェクション対策が標準でサポートされています。ただのORMとしてではなく、テーブル設計を行うのにも非常に便利です。 ここではSQLAlchemyの使い方について紹介します。DBはPostgresqlやMySQLではなく、簡易的なはSQLiteを使用します。 ORMとは Object-Relational Mappingの略です。 オブジェクト志向言語のクラスとRDBとのマッピングを行ってくれるのがORMです。SQLをオブジェクト指向で書けるようになります。 ORMの利点をまとめると主に以下の2つの点があります。 異なるDBの違いを吸収する MySQLやPostgresqlといったデータベースの種類によらず、同じソースコードで操作できます。
この記事は何か AWS DynamoDBをメインのDBとして利用した開発の中でぶち当たったDynamoDBの制約についてまとめた記事 DynamoDBの特徴をまとめてくれている記事はたくさんあるが、実際にDynamoDBが技術選定の土俵に上がった際の明確な選定基準を提供する記事は少ないため、少しでもヒントになればと思い執筆していく。 ※間違いなどあればコメントなどで教えて頂けると幸いです TL;DR DynamoDBは「それらの指定でレコード(Item)が一意に特定できない2つ以上のカラム(Attribute)での条件検索を伴うクエリが頻繁に投げられる」要件には向かないので注意しよう DynamoDBのテーブル設計における前提条件 各テーブルにHash Key と Sort Keyを指定することができる 1. Hash Keyのみ 2. Hash KeyとSort Key のいづれかのパタ
はじめに こんにちは！ 最近仕事でDynamoDBの設計について議論をしているとき、「DynamoDBのテーブルは一つだけにすることがベストプラクティス」というのが少し盛り上がりました。スキーマレスなDynamoDBならではの議論で面白いですね。実は私が前職で開発をしていた時にこれに近いことを実践していて、なるべくDynamoDBのテーブルは少なくなるような設計を行っていました。 この記事はその手法を共有したいと思います。 本記事の対象読者 DynamoDBを使ったことがある方 ハッシュキー、レンジキー、LSI、GSIがどういうものか何となく理解できている方 なぜDynamoDBのテーブルは少ないほうが良いのか？ ひと昔前はAWSのDynamoDB開発者ガイドに DynamoDB アプリケーションではできるだけ少ないテーブルを維持する必要があります。設計が優れたアプリケーションでは、必要な
Laravel Filamentでお手軽に作る管理画面とそのためのテーブル設計 - KAYAC Engineers' Blog
はじめに この記事は【カヤック】面白法人グループ Advent Calendar 2024の12日目の記事です。 こんにちは、カヤックボンド所属のサーバーサイドエンジニアの朝倉と申します。 本記事のテーマはLaravel filamentを用いた管理画面作成です。 管理画面を簡単に作れるFilamentの基本的な使い方と要件をちゃんと決めずに見切り発車したらぶつかってしまうFilamentならではの問題を書いていきたいと思います。 Laravel Filamentとは filamentphp.com まずPHPのフレームワークとしてLaravelがあり、その拡張パッケージがFilamentです。 管理画面を作るための機能を豊富に持っています。 また、今回は触れませんがサーバーサイドの記述のみでフロントの動的な制御をする機能も用意されています。 環境構築 環境構築についてはこちらを参考にさせ
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 柴田竜典 2017/6/1 Amazon Redshift テーブル設計詳細ガイド 分散スタイルとソートキーの決定方法 自己紹介 柴田竜典［シバタツ］ • データベース関連の 相談ごと何でも担当 • AWSへの移行を機に RDBMSをAuroraに 乗り換えたい • オンプレミスOracleを AWSにフォーク リフティングしたい • 好きなAWSのサービス: S3 @rewse すでにRedshiftをお使いの方の悩み • クエリー性能をさらに向上させたい • 同時実行を上手にさばきたい • 料金を抑えたい などなど クエリー性能向上に大切なことは何か 最良のソートキーの選択 最適な分散スタイルの
[GT-2] イラストで学ぶAmazon DynamoDB ～テーブル設計からパフォーマンスチューニングまで～ | AWS Dev Day 2023 Tokyo #AWSDevDay
Amazon DynamoDB はフルマネージドかつサーバーレスの Key-Value型NoSQL で、ゲームとの相性が良いサービスです。 しかし NoSQL のためまだ事例も少なく、慣れていないゲーム開発者もいるため検証や実装まで進められていないケースも多いと思います。 このセッションではAmazon DynamoDBでの実践的なテーブル設計の方法やパフォーマンスチューニングなどを実際にタイトル使用された体験を元にイラストを交えてわかりやすく解説します。 ◆スピーカー： 中島 淳平 氏 ( 株式会社カプコン第二開発統括システム基盤部 ゲーム基盤室) / 中村 一樹（アマゾン ウェブ サービス ジャパン合同会社 ） ◆中島 淳平 氏 プロフィール： 株式会社カプコンで十数年サーバーエンジニアとして活動し、多くのモバイルタイトルの開発に参加。モンス
![[GT-2] イラストで学ぶAmazon DynamoDB ～テーブル設計からパフォーマンスチューニングまで～ | AWS Dev Day 2023 Tokyo #AWSDevDay](https://cdn-ak-scissors.b.st-hatena.com/image/square/68a4a4bf0dffc18d1364c07e75a3e087786ef609/height=288;version=1;width=512/https%3A%2F%2Fi.ytimg.com%2Fvi%2FJeVsqphKKEI%2Fhqdefault.jpg)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
ゲームにおけるテーブル設計 - Qiita
「Applibot Advent Calendar 2021」 4日目の記事になります。 前日は @kazunosuke さんのスマートコントラクト触ってみた という記事でした! 目次 1.はじめに 2.用語定義 2.1マスターデータ 2.2ユーザーデータ 2.3よく使うテーブル構成 3.設計 3.1命名規則 3.2マスターデータの設計方針 3.3ユーザーデータの設計方針 4.おわりに 1. はじめに 出して終わりではなく、運用や仕様変更などが頻繁に行われるゲームでは、既存のテーブル設計とは少し違う視点で設計する必要が出てくる場合があります。 新規のゲームを立ち上げから5つほど実際に担当した筆者が、大事だと思う点をまとめてみましたので、他では適さないケースもあるかとは思いますが参考にしてもらえると嬉しいです。 ※こちらは弊社で行った新卒研修のために準備した、「ゲームにおけるテーブル設計」に
概要 こういうテーブルを見たことはないだろうか。 statusごとに、nullable, not nullカラムが混在しているクレイジーなテーブルである。 どんなときに、値が入るねん！と不安にさせてくる。 どの現場にも存在して、もはや既視感すらある。 このテーブルの問題点とその解決案を説明していきたい。 登壇しました 対象読者 テーブル設計を学んでいる方 技術的負債を解消したい方 いいね！してね この記事の事例は必要に応じて今後追記していく予定です！ 「新しい事例が知りたい」「他の事例も知りたい」と思った人は、ぜひこの記事にいいね👍してください。筆者のモチベーションにつながります！ それでは以下が本編です。 結論 ✅テーブルに状態を持たせない（statusカラムをつけない）、ロングタームイベントパターンでテーブルを分割する。 テーブルの数は多いけど、シンプルで可読性が高い 解説は別記事
OAuth2.0のユーザーテーブル設計
一昔前のユーザー登録はusernameとpasswordを入力して貰い、DBのデータと一致していればログイン成功の判定を出してましたが、 今風のWebサービスはgithub、googleアカウントログインなどの外部認証サービスを使用することも少なくありません。 この記事では、そういった外部認認証を使用することが前提のユーザーテーブルの設計を軽く紹介します。 ベーシックのユーザーテーブル構成 usernameとpasswordを使用して認証する、一番ベーシックなテーブル構成、外部認証の使用は想定しない。 :boy_tone1:テーブル: users id: 主キー username: ユーザーネーム password: パスワード register_time: ログイン時間 id username password register_time
サブタイプモデルをテーブルに落とし込むには、何通りか方法があります。実装方法ごとのメリット、デメリットについて確認します。 例 例として、「User」のサブモデルとして「Student」と「Teacher」が存在する場合のテーブル設計について考えてみます。 設計方法 DB設計といえば、以下の本が有名です。 SQLアンチパターン この本の5章でサブタイプのモデリングについて取り上げられています。ここでも以下４つの方法でテーブル設計してみます。 シングルテーブル継承 具象テーブル継承 クラステーブル継承 半構造化データ シングルテーブル継承 １つのテーブルにサブタイプの属性を全て詰め込みます。 サブタイプの識別には、user_typeを利用します。 サブタイプの属性が少ないときに適切です。 具象テーブル継承 「teachersテーブル」と「studentsテーブル」にそれぞれ共通属性を持たせま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
テーブル設計の考え方とやり方 [入門編]
超入門！テーブル設計をデータモデリングから考えよう
【随時更新】テーブル設計でミスらないために確認したいアンチパターン - Qiita
【初心者向け】データベースのテーブル設計で僕が意識している6つのこと - Qiita
Amazon.co.jp: アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド (KS情報科学専門書): ローレンス・コル (著), ジム・スタグニット (著), 株式会社風音屋 (翻訳), 打出紘基 (翻訳), 佐々木江亜 (翻訳), 土川稔生 (翻訳), 濱田大樹 (翻訳), 妹尾拡樹 (翻訳), ゆずたそ (翻訳), 株式会社風音屋 (監修): 本
パフォーマンスに影響！Redshiftのテーブル設計時に最低限意識すべきポイント3選
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料 - Qiita
SQLAlchemyでテーブル設計とORMの操作
AWS DynamoDBのテーブル設計における注意点 - Qiita
DynamoDBテーブル数を少なめで運用するためのテーブル設計
Amazon Redshift テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–
【ER図】カーディナリティ「必ず1」「1つだけ」と「1」の違い【テーブル設計】 - Qiita
テーブル設計: statusカラムから生じる技術的負債とその解決策①
サブタイプモデルのテーブル設計 - わくわくBank
togetter.com
note.com/hoshiyamalog
www.akita-abs.co.jp
komagome-minna-dc.com
www.mbs.jp
www.itmedia.co.jp