タグ

データベースに関するkihalaのブックマーク (39)

  • データベース中心の設計になってしまう問題と闘う - laiso

    『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

    データベース中心の設計になってしまう問題と闘う - laiso
  • 実践データベース設計

    2024年度リクルート エンジニアコース新人研修の講義資料です

    実践データベース設計
  • [提案]テーブル名はもう全部単数形にしようや

    こんにちは、データベース愛好家のみなさん!今日は、データベース設計で永遠の議論となっている「テーブル名、単数形 vs 複数形問題」について、徹底的に掘り下げていきます。私は単数形派です!でも、なぜそうなのか、一緒に深掘りしていきましょう。 イントロダクション:我らが主人公、単数形くん みなさん、こんな経験ありませんか? You: テーブル名って、users? user? どっちがいいんだろう... 先輩: いや、絶対usersだよ!Rails使ってるし。 You: でも、user_idって書くときは単数形だよね? 先輩: あ、そうだね...でもやっぱりテーブルは複数形! You: (心の中で)なんかモヤモヤする... 実は、この「モヤモヤ」には理由があるんです。今日はその理由を解き明かし、単数形テーブル名の魅力をお伝えします。準備はいいですか?Let's dive in! 言語の壁を突破せ

    [提案]テーブル名はもう全部単数形にしようや
  • こんなに違うよ MySQLとPostgreSQL /

    2024年6月22日に開催された「第14回 関西DB勉強会 」での、 『こんなに違うよ MySQLとPostgreSQLMySQLとPostgreSQLのニッチな違いを語る~』 の発表資料です。 https://kansaidbstudy.connpass.com/event/316348/

    こんなに違うよ MySQLとPostgreSQL /
  • クラウド時代のデータベースを理解するために①

    最近、分散データベースとかNewSQLとかサーバレスなデータベースとか色々聞きますよね。 でも、専門ではない人たちにとって、「何が違うの?」「自分たちに必要なDBはどれなの?」という点が分かりづらいと思います。 私も良く聞かれます。 AuroraはNewSQLですか? NewSQLってサーバレスなんですか? スケールできないDBとか聞きますけど、リードレプリカ増やせますよね? などなど。この辺に基的なところから答えられるように、順を追って解説していきましょう。 「コンピュートとストレージは別であれ」 と神が言うと、コンピュートとストレージは分離された。 と言うのは冗談ですが、まずはここからスタートしましょう。 クラウド以前のデータベースを使っていた人にはお馴染みのように、それまでデータベースは大きな1つの箱でした。 過去に私は下図でデータベース(厳密にはRDBMS)のコンポーネントを解説

    クラウド時代のデータベースを理解するために①
  • データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。

    回答 (7件中の1件目) まずはUUID及びその対案として用いられる連番(自動採番)のメリット・デメリットを整理します。 (タイムスタンプキーや複合キーなどもその効率性から設計上有用なシーンはありますが、比較から除外します。) * UUIDを使うことのメリット * * データベースにSQLを送信する前からアプリケーションレイヤーでIDを生成できる。 * * トランザクション処理を実装しやすい場合がある。 * IDを推測しにくい。リソースが列挙可能ではない。 * UUIDを使うことのデメリット * * レコード・インデックスサイズが増加する。 * * ...

    データベースでユニークキーにUUIDを使うメリットは何ですか?連番やタイムスタンプまたは複合などではいけないのでしょうか?どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
  • テーブル・DB設計するときの極意 - Qiita

    はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者(私)向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも?中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ! ・テーブル・DB設計は「属性」と「関係」の2つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1 / 1:N / N:N しかない(しかも、ほとんど 1:N) これが極意だ!!! 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょう。 users / posts / comments / likes のテーブルが

    テーブル・DB設計するときの極意 - Qiita
  • インデックスを理解したい - Qiita

    はじめに みなさんはDBのインデックスを正しく使えていますか? 私はなんとなく「DBのパフォーマンスを向上するためのもの」という認識はあったのですが、 どのような場面で使うものなのか、逆にどのような場面では使うべきでないのかなど 明確に理解できていませんでした。 今回はそんなインデックスについての理解を深めたいと思います。 インデックスとは インデックスとは、その名の通り「索引」です。 表現の仕方と変えると、(x, a)という形式の配列であるとも言えます。 xというキー値とそれに結びつくaというデータ情報があり、 これを利用することですべてのデータを網羅して見ることなく、 まさにの索引のように目的のデータにたどり着くことができます。 インデックスはSQLのパフォーマンスを改善するための非常にポピュラーな手段であり、 理由としては下記の3点が挙げられます。 アプリケーションのコードに影響を

    インデックスを理解したい - Qiita
  • 履歴データテーブルとの向き合い方_PHPerKaigi2024

    PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

    履歴データテーブルとの向き合い方_PHPerKaigi2024
  • リレーショナル・データベースの世界

    序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記:その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

  • SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita

    データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH

    SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
  • RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag

    PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134

    RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
  • ハッカーのおもちゃとしてのNostrのススメ - Qiita

    はじめに Nostrという、SNSのようなものはご存知でしょうか? ご存知でなければ、ぜひまず一度触ってみることをお勧めします。 割と普通にSNSっぽく使えます。 分散系SNSっぽいシステム Nostrは、分散系のSNSっぽいネットワークです。 図で表すとこんな感じ。普通に想像するWebサービスとは随分形が違うと思います。 各所のリレーサーバーに、ユーザーは投稿をばらまき、ユーザーがそれを見る形です。 分散の責任がユーザー(クライアント)側にあって、リレーサーバーが落ちたり消えたりしても影響が起きにくい仕組みです。 より詳しい説明は上記でやってるのですが、端的に言って 中央管理者がいない(各リレーに管理者はいる) 冗長で災害に強い Websocketのリアルタイム通信 オープンでシンプルで、でも拡張し放題な仕様 数多のサーバーによる分散ネットワーク といった特徴があります。 ※P2P技術

    ハッカーのおもちゃとしてのNostrのススメ - Qiita
  • データベース概論Ⅰ | 筑波大学オープンコースウェア|TSUKUBA OCW | 北川博之

    データベースシステムに関する入門。データベースの基概念、データモデリング、リレーショナルデータモデル、データベース言語SQL、リレーショナルデータベース設計論、物理的データ格納法、問合せ処理等について講述する。 (2018年度) 【教科書】 「データベースシステム」(北川博之著、オーム社) 北川 博之筑波大学 計算科学研究センター教授1978年東京大学理学部物理学科卒業。1980年同大学理学系研究科修士課程修了。日電気(株)勤務の後、筑波大学電子・情報工学系講師、同助教授を経て、現在、筑波大学計算科学研究センター教授。理学博士(東京大学)。データベース、データ統合、データマイニング、ストリーム処理、情報検索、ビッグデータ等の研究に従事。著書「データベースシステム」(オーム社)等。日データベース学会会長、ACM SIGMOD日支部委員長等を歴任。情報処理学会フェロー、電子情報通信学会

    データベース概論Ⅰ | 筑波大学オープンコースウェア|TSUKUBA OCW | 北川博之
  • 開発者が知るべきキャッシュ設計でよく遭遇する問題

    はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない

    開発者が知るべきキャッシュ設計でよく遭遇する問題
  • ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は?[PR]

    ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は?[PR] 日常的に多数の同時アクセスが発生し、大量のデータが蓄積されるオンラインゲームのバックエンドは、データベースにとってもっとも過酷な環境の1つだといえます。 このバックエンドデータベースとしてよく使われているのがMySQLデータベースです。しかしその使われ方は一般的なMySQLとは異なり、データベースを細かく分割して多数のサーバに負荷を分散するシャーディングと呼ばれる仕組みを構築するなど、複雑なシステム構築と運用が行われているのが現実です。 そこで急速に注目度を高めているのが、MySQL互換でありつつ分散データベースの機能を備え、シンプルなクラスタ構成で高い負荷に耐える、いわゆる「NewSQL」と呼ばれる分野の代表的なデータベースの1

    ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は?[PR]
  • DynamoDBのベストプラクティスを技術的詳細から理解する

    こんにちは。 株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 弊社では宿泊施設様向けに宿泊施設の予約管理用のSaaSを提供しており、現時点で1000近くの施設様にご利用いただいています。 現在、これまでに溜め込んだ日最大級の宿泊コンテンツの検索エンジンを構築しており、その過程でさまざまなデータベースを探索しています。 記事では、AWSのKVSであるDynamoDBを題材に、公式ドキュメントに書かれているキー設計のベストプラクティスの背景を理解することを目的とします。 なお、記事の執筆にあたって、こちらの動画を大変参考にさせていただきました。 DynamoDBとは DynamoDBとは、AWSで利用できる、あらゆる規模に対応する高速で柔軟なNoSQLデータベースサービスです。 DynamoDBが登場した背景は、アプリケーションの大規模化です。

    DynamoDBのベストプラクティスを技術的詳細から理解する
  • 無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita

    はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ

    無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita
  • 【随時更新】テーブル設計でミスらないために確認したいアンチパターン - Qiita

    はじめに 参考書籍が非常に参考になったのでテーブル設計に関する内容のみをピックアップまとめてみました。普段テーブル設計をしていれば"当たり前"に実践している方も多いと思いますが、今回チーム内での勉強会用の資料の意味合いも込めて作成しました。記事では、基的にリレーショナルデータベースにおける設計を想定しています。 ご留意ください 記事は"何があってもこのような設計が非推奨される"というものではありません。その時々のコンテキストによっては採用することが妥当な場合もあるかと思います。 1. 正規化が不十分 非正規化とは、データベース設計において、データの重複や冗長性を意図的に許容することを指します。正規化は、データの整合性と効率的なストレージのためにデータの重複を排除するプロセスですが、非正規化はそれとは逆のアプローチをとります。非正規化の目的は主にパフォーマンスの向上です。ジョイン操作の

    【随時更新】テーブル設計でミスらないために確認したいアンチパターン - Qiita
  • MySQLとOracleの実行計画を比較してみた - ASMのきもち

    まいえすきゅーえりたい ぽすぐれない おらくるってる(狂ってる)tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな!というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません

    MySQLとOracleの実行計画を比較してみた - ASMのきもち