タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに タイトルのとおり、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 やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 𝕏 𝕃（おおきなえる）🌸🐻💿⚒️ @ellnore_pad_267 > 単なる SQL やテーブル設計のいろはとかではなく『データベース』そのものの勉強な。 オプティマイザとかその辺の細かい部分の話。 この部分読めてない奴が一定数おる？？？？
基本から学ぶ テーブル設計 超入門！ 〜データモデリングとテーブル設計の基本を学ぼう〜 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
はじめに 参考書籍が非常に参考になったのでテーブル設計に関する内容のみをピックアップまとめてみました。普段テーブル設計をしていれば"当たり前"に実践している方も多いと思いますが、今回チーム内での勉強会用の資料の意味合いも込めて作成しました。本記事では、基本的にリレーショナルデータベースにおける設計を想定しています。 ご留意ください 本記事は"何があってもこのような設計が非推奨される"というものではありません。その時々のコンテキストによっては採用することが妥当な場合もあるかと思います。 1. 正規化が不十分 非正規化とは、データベース設計において、データの重複や冗長性を意図的に許容することを指します。正規化は、データの整合性と効率的なストレージのためにデータの重複を排除するプロセスですが、非正規化はそれとは逆のアプローチをとります。非正規化の目的は主にパフォーマンスの向上です。ジョイン操作の
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし3 「テーブル設計のスタイル」 - asken テックブログ
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし3ページ目です。最初からお読み頂く場合は、こちらから御覧ください。 資料 増田さんの講演資料 質疑応答モデル なぜこの場を作ったのか 書き起こしリンク パート1「良い設計を目指す」 パート2「設計スタイルの選択とクラス設計のスタイル」 パート3「テーブル設計のスタイル」（本記事） パート4「開発のやり方と設計スキルと補足資料」 パート5「質疑応答」 目次 テーブル設計のスタイル テーブル設計の分かれ道 イミュータブルモデルを選ぶ イミュータブルデータモデルの効果 イミュータブルに設計したテーブルの特徴 プログラムが単純かつ明快になる 2022/08/24 追記 イミュータブルデータモデルについてより詳し知りたい方は、WEB+DB Press Vol.130 も是非お読みくださいませ！ パート3の内容（イミュータブルデータモデル）につ
はじめまして、himakuroです。 2017年ぐらいからQiitaに記事を投下しようと考えていたのですが、なかなか筆が乗らずようやく初投稿です 軽く自己紹介をしておくと、普段は社内SEとしてPHP、Ruby、Golangを書いたり、 趣味の個人ブログ方ではプログラミング初心者に向けた記事や雑記的なものを書いたりしています。 今回は記念すべき1つ目の記事と言う事で 僕が普段テーブル設計（主に命名）で気をつけている6つの事を書きました。 僕の好みも含まれていますが、初心者の方がテーブルやカラム名を決める際の参考になればなと思います。 テーブル名は必ず複数形にする テーブルは一つしかないから単数形を使うべき！ Modelも単数形で定義するじゃん！ みたいな反論が聞こえてきそうですが、僕は複数形で定義する派です。 また複数形にする場合に、テーブル名の途中の部分を複数形にしている物をたまに見かけま
DynamoDBをいじり始めてかれこれ一年くらい。見よう見まねで騙し騙しやってきたが、色々と痛い目を見てわかってきたこともある。転んで生傷つくりながら、テーブル設計をする際に考えるようになったことを、備忘録的に記述していく。 オートスケールの話はしない（わからない）。インフラ専門部隊がいないなら、オンデマンドがいいよ。人的コストより多分安いよ。 ドキュメント なにはともあれ、公式のドキュメントについて存在を知っておく→「DynamoDB のベストプラクティス - Amazon DynamoDB」 こんな記事を読んでいる時間があるなら、公式のドキュメントを読むべきだ。でも多分読めない。自分も今でも読めていない。ここに書かれているのは本当に日本語だろうか、と真剣に思う。まぁ教科書なんていうのはだいたい、わかってから読むとわかるもんである。 それでも通して読むことでなんとなく親しみがわくのが人間
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 のテーブル設計でお悩みの方に読んで頂けたらと思います。 本記事では、クエリーによる検索について言及します。フィルターは全件取得の後に条件でデータをフィルターするので、データ数や実行回数が多いと課金が高額になる恐れがあります。また、データ量が多いとレスポンスが一気に遅くなるので、実用的でなくなるケースがあります。あくまで、データ量が少ないときの
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 アプリケーションではできるだけ少ないテーブルを維持する必要があります。設計が優れたアプリケーションでは、必要な
［DB/SQL］要件をテーブルに落とし込む手法のメモ書き（複式簿記のテーブル設計を例に） - Qiita
「複式簿記」に興味を持った理由 ・グーグル日本法人の社長を勤めた村上憲郎さんが「エンジニアとしてキャリアを始めた時に簿記を勉強させられたがそれが後に役に立った」と書籍に書かれていたから。 そもそも「複式簿記」とは？ ・どこからいくらお金を調達して（=負債または収益）、 ・何にいくらお金を支払ったのか（＝費用） ・または、調達したお金をどういう形でいくら保管しているか（＝資産）を記録する手法。 （目的） ・決算日における資産状況を把握する貸借対照表（B/S）を作成 ・１年間の損益や当期純利益を把握する損益計算書(P/L)を作成 テーブル設計の流れ ①要件の把握 >> ②概念設計 >> ③論理設計 >> ④物理設計 要件の把握
© 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 の場合は対照的に、答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが不可欠です。
ゲームにおけるテーブル設計 - 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テーブル」にそれぞれ共通属性を持たせま
「みんなさぁ、データベースって何で学んだ？」単なるSQLやテーブル設計のいろはとかではなく『データベース』そのものの勉強についての質問に有益な情報が集まる (3ページ目)
きのこ @p_kinoko @ellnore_pad_267 インデックスの仕組みや実行計画の基本はこちらで学びました。 use-the-index-luke.com/ja 本（翻訳書）やpdfでも、「SQLパフォーマンス詳解」という名前で出されてますね。 amazon.co.jp/SQL%E3%83%91%E… リンク use-the-index-luke.com SQLのインデックスとそのチューニングについてのオンラインブック 開発者のための、$SQLのインデックスとそのチューニングについてのチュートリアル。 各データベースの詳細までは踏み込み過ぎず、開発者が必ず知らねばならないことに的を絞りました。 主要なSQLデータベース全てをカバーしています。 638 users 32
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
テーブル設計の考え方とやり方 [入門編]
超入門！テーブル設計をデータモデリングから考えよう
【随時更新】テーブル設計でミスらないために確認したいアンチパターン - Qiita
【初心者向け】データベースのテーブル設計で僕が意識している6つのこと - Qiita
DynamoDBのテーブル設計をするとき、自分に問いかけていること - 或る阿呆の記
パフォーマンスに影響！Redshiftのテーブル設計時に最低限意識すべきポイント3選
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料 - Qiita
データベース テーブル設計入門 | フューチャー技術ブログ
SQLAlchemyでテーブル設計とORMの操作
AWS DynamoDBのテーブル設計における注意点 - Qiita
DynamoDBテーブル数を少なめで運用するためのテーブル設計
Amazon Redshift テーブル設計詳細ガイド –分散スタイルとソートキーの決定方法–
DynamoDBのテーブル設計時に気を付けること | It works for me
サブタイプモデルのテーブル設計 - わくわくBank
komachi.yomiuri.co.jp
network.mobile.rakuten.co.jp
narukinhonda.com
news.2chblog.jp
lib-erty.com
news.mynavi.jp