Content-Length: 282609 | pFad | http://b.hatena.ne.jp/takaesu/rdb/

[B! rdb] takaesuのブックマーク

タグ

rdbに関するtakaesuのブックマーク (11)

  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
  • RDBを使わない究極のマルチテナント

    先日、SmartHRさんのDB移行の話が話題になりました。 これは、「つらくないマルチテナンシーをどのように実現したか」という生々しくインパクトのあるプレゼンでした。 ただ、個人的にはちょっと引っ掛かるところがありました。そもそもテナント毎にテーブルを作成するという設計に無理があったのではないかと思ったからです。Citus Cloudで解決できたそうなので結果オーライではあるのですが。 マルチテナントでDBを分けたくなる気持ちはわかります。②のパターンですね。 それは、顧客データを全て一つのDBに混ぜてしまうのはデータ混濁のリスクがあるのでDBの機能・ユーザーでデータを分離したいというのがその理由なのだろうと思います。 ですが、当にDBを分ける必要があるかはよく考える必要があると思います。なぜなら、テナントごとに1 つのDBをサポートするという状態はマルチテナンシーが回避しようとしている

    RDBを使わない究極のマルチテナント
    takaesu
    takaesu 2019/06/20
    databaseを使わないでGCPでデータを作る
  • トランザクションについて(SELECT FOR UPDATE) | ケーワン・エンタープライズStaffブログ

    今回は、SELECT FOR UPDATE時のトランザクションの挙動を確認したいと思います(`・ω・´)ゞビシッ!! その前に前回のトランザクションを読んでない人は読んでからの方が理解しやすいと思われます(; ・`д・´) こちらになります。 ・トランザクションについて ・ランザクションについて(その2) ■下準備 同じMySQLサーバーに別々のコンソールからログインして2つ開きます。 (以下、コンソールA、コンソールBとします。) データベースにはMySQLのデフォルトで作られているtestを利用して、 テーブルはuserというテーブルを作って利用します。; テーブル定義は次のものを利用しています。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `mail_address` varchar(255) DEFAUL

    トランザクションについて(SELECT FOR UPDATE) | ケーワン・エンタープライズStaffブログ
  • MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)

    どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。(もちろん、きっかは自分がドツボにはまったから) ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 (というか、これが問題なく読めて理解できる人はこの記事読む必要ない….) 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ

    MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
  • あなたの知らない
データベースのロギングの世界 / logging queries

    builderscon tokyo 2018 の発表資料です。 https://builderscon.io/tokyo/2018/session/87e13506-2f80-4fae-af9c-2421c7dbb460 ※発表後に分かったこと、教えていただいたことにより、発表時の資料から若干の…

    あなたの知らない
データベースのロギングの世界 / logging queries
  • NULLと戯れる: ORDER BYとNULL - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    NULLと戯れる: ORDER BYとNULL - Qiita
  • PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較!|ハイクラス転職・求人情報サイト AMBI(アンビ)

    PostgreSQLMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! オープンソースのデータベースとしてよく比較されるPostgreSQLMySQL。どんな長所・短所があるのでしょう? それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース(以下、RDB)を選ぶのが最善なのか?」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ

    PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較!|ハイクラス転職・求人情報サイト AMBI(アンビ)
  • PostgreSQLのIndex入門

    PostgreSQLでのSELECTなどで対象のレコードを早く検索するための「Index(インデックス、索引)」についてのまとめです。 🗻 お勧めスライド:PostgreSQLクエリ実行の基礎知識 PostgreSQLについて丁寧な解説がされているスライドです。PostgreSQLの実行計画を理解するのにすごく参考になりました! 😼 Index作成までの流れ いつ 新規テーブルの作成時 DBのパフォーマンス・チューニングの際 どうやって SQLの実行ログから、実行回数が多い & 実行に時間がかかるSQLを探す EXPLAINで実行計画を元に最適なindexを探す 代替案としてサマリテーブルを作ったり、キャッシュをもつことも検討 🐹 Index作成SQLCREATE INDEXでIndexを作成できます。 -- レコードがユニークではないインデックスの場合 CREATE INDEX

    PostgreSQLのIndex入門
  • PostgreSQLの実行計画を読み解くための参考資料集 - ぱと隊長日誌

    はじめに PostgreSQLは商用DBに比べて書籍が少なく、まとまった情報が入手しにくいです。また、有志の方がPostgreSQLに関する資料を公開していますが、散在しており、せっかくの有益な情報にアクセスしにくい状況にあります。 そこで、エントリではPostgreSQLの実行計画に焦点を絞り、公開されている有用な資料(書籍含む)をまとめました。読み返したい資料を探しやすくするため、内容のポイントも併せて紹介してます。 エントリをきっかけに、これらの資料がさらに活用されることを願っています。 前提 各資料の前提としているPostgreSQLのバージョンは異なることにご注意ください。調査対象のPostgreSQLのバージョンが異なれば、状況は変わっているかもしれません。 各資料には内容の重複があり、ほぼ同一内容の場合もあります。重複している内容についてはポイントから割愛することがありま

    PostgreSQLの実行計画を読み解くための参考資料集 - ぱと隊長日誌
  • YAPC::Kansai で RDBアンチパターン その2 について話してベストトーカー賞を取ってきた #yapcjapan - そーだいなるらくがき帳

    YAPC::Kansaiでトークしてきました。 yapcjapan.org RDBアンチパターンの話してきました。 去年、PHPカンファレンスでRDBアンチパターンの話をして盛り上がったのでそれの第二弾です。 b.hatena.ne.jp speakerdeck.com 僕が伝えたい事はたったひとつ。 このブログを読んだらすぐ自分たちのサービスのバックアップとリストア手段確認してください! お兄さんとの約束だぞ!! このトーク応募したらGitLab.comが大事故起こしたり、S3が落ちたり世の中では大変そうでした。 www.publickey1.jp ヒューマンエラーとかあるんですよほんと。 僕もいっぱい見てきたし、やったし(ぉぃ なので当にもうこれだけは絶対確認してほしいって思います。 実際に「バックアップ無いDBをバグで飛ばしたんですけどどうすればいいですか?」とか相談来ます。 ほん

    YAPC::Kansai で RDBアンチパターン その2 について話してベストトーカー賞を取ってきた #yapcjapan - そーだいなるらくがき帳
  • 分析SQLのコーディングスタイル - クックパッド開発者ブログ

    SQL、書いてますか? こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……? という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし(青木)が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析

    分析SQLのコーディングスタイル - クックパッド開発者ブログ
  • 1








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://b.hatena.ne.jp/takaesu/rdb/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy