タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに タイトルのとおり、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)
「みんなさぁ、データベースって何で学んだ？」単なる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のトークやその他のビデオを見る、私が執筆した本をチェックするなどで理解することができます。シングルテーブル設計の賛否両論に特に焦点を当て
DynamoDBで多対多のテーブル設計 - 或る阿呆の記
DynamoDBの設計を始めてからたいていの人が引っかかるであろう、DynamoDBにおける多対多(many-to-many relationship)の対応について、つらつらとメモする。 AWSのドキュメントにベストプラクティスがあるので、それについて書き連ねるだけではある。 DynamoDBの2番目くらいの壁 ウキウキしながらDynamoDBを始めた後、だんだん「あれ？これクエリめっちゃ厳しくない？」ということに気づき、その制約に愕然とするパターンの一つが、いわゆる多対多の実装だと思う。RDBなら中間テーブル作ってリレーション貼って正規化すればよし、だけれど、同じことをDynamoDBですると、めちゃくちゃクエリ投げないといけないことにハタと気づく。すごく思う。joinしたい。 もちろんDynamoDBにjoinはない。ああなるほど、KVS、Key Value Storeってそういう…
Amazon DynamoDB のテーブル設計で悩んだら最初に読もう -これだけ知ればある程度の検索には対応できる-
こんにちは、広野です。 Amazon DynamoDB は NoSQL と言われる類のデータベースですが、検索条件の指定に限りがあり、また検索条件を増やすための設定が構築後に追加できない箇所があります。そのため、最初のテーブル設計の時点で実際に使用する検索条件を意識して構築しないと、最悪データベースの作り直しになってしまいます。 そこで、簡易な検索要件であればこれだけ押さえておけば対応できる！という例をつくってみました。Amazon DynamoDB のテーブル設計でお悩みの方に読んで頂けたらと思います。 本記事では、クエリーによる検索について言及します。フィルターは全件取得の後に条件でデータをフィルターするので、データ数や実行回数が多いと課金が高額になる恐れがあります。また、データ量が多いとレスポンスが一気に遅くなるので、実用的でなくなるケースがあります。あくまで、データ量が少ないときの
データベースを止めずにテーブル設計を変更したい
プラハチャレンジにて、受講生チームから次のような質問がありました。 データベース（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か
リレーションRが次の二つの条件を満たす。 1.第１正規形であること 2.すべての非キー属性は、いかなる候補キーにも部分関数従属していない(完全関数従属である)こと ですがこの定義の説明、専門用語と独特の言い回しが多く初見だと難しく感じたので順を追ってわかりやすく非正規形から第３正規形にしてみようと思います。 STEP0 基本となるテーブル説明の為、サンプルとなるテーブルを用意します。社員番号、社員名、部署コード、部署、趣味を持つものとします。社内向け社員検索システムの設計の一部だとでも思っていただければよいです。 仮のレコードも付け加えると以下のようになります。以後、主キーは下線にて示します。 この社員テーブルは非正規形の状態です。 社員 ※1 本来であれば社員名は姓、名で分けたり、よみがなの項目を分けて持つべきですが、今回の説明の主旨から外れるので簡易的に社員名として表現しています。 ※
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をお使いの方の悩み • クエリー性能をさらに向上させたい • 同時実行を上手にさばきたい • 料金を抑えたい などなど クエリー性能向上に大切なことは何か 最良のソートキーの選択 最適な分散スタイルの
DynamoDBを使いだして、DynamoDBの仕様やNoSQLへの理解不足ゆえに、あーこれ設計ミスったなーとか、設計段階で考慮すべきだった問題が噴出してきたので、知見をまとめてみます。 テーブル設計より先にデータ利用シーンを洗い出す AWSの公式ドキュメントには、次のように書いてあります。 NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい質問とクエリの要件が発生したら、そのデータモデルを拡張することができます。各タイプのデータを独自のテーブルに整理できます。 NoSQL 設計は異なります。 DynamoDB の場合は対照的に、答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。
[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つほど実際に担当した筆者が、大事だと思う点をまとめてみましたので、他では適さないケースもあるかとは思いますが参考にしてもらえると嬉しいです。 ※こちらは弊社で行った新卒研修のために準備した、「ゲームにおけるテーブル設計
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 テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–
DynamoDBのテーブル設計時に気を付けること | It works for me
【ER図】カーディナリティ「必ず1」「1つだけ」と「1」の違い【テーブル設計】 - Qiita
サブタイプモデルのテーブル設計 - わくわくBank
atmarkit.itmedia.co.jp
dic.pixiv.net
toyokeizai.net
gendai.media
ioritorei.com
www.ushidama.com