タグ

DB設計に関するJxckのブックマーク (10)

  • 4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回はに載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方はを購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをま

    4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita
    Jxck
    Jxck 2016/11/01
    "全てのテーブルにidという名前を安易につかっていないか"
  • 1日に100万レコード増える場合のテーブル設計

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

    1日に100万レコード増える場合のテーブル設計
  • 論理削除gemを1年ほど保守してみて。重大な欠点にやっと気づいたポエム。 - 波打際のブログさん

    はじめに kakurenboというgemはご存知でしょうか?paranoiaの欠点を克服すべく1年ほど前に私が開発を始めたgemです。(参考:Rails4と3で論理削除を行うためのGem Kakurenbo の紹介と今更論理削除Gemを実装した理由。 - 波打際のブログさん) issueやpullrequestを送信してくださる善意のコミッターの方々に支えられながら1年ほど保守をしてきました。その上で薄々は気がついていたのですが、どうしても認められなかった重大な欠点をハッキリと認識させられたのでポエムにしました。 論理削除gemの起源 kakurenboもparanoiaも、廃れてしまった acts_as_paranoid を再実装したものです。 これらのgemは導入するだけで、いつも使っているdestroyメソッドが論理削除メソッドに早変わりする素晴らしいgem...になるはずだったので

    論理削除gemを1年ほど保守してみて。重大な欠点にやっと気づいたポエム。 - 波打際のブログさん
  • 論理削除がデータを汚している - jfluteの日記

    ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か

    論理削除がデータを汚している - jfluteの日記
  • イミュータブルデータモデル(入門編)

    2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。

    イミュータブルデータモデル(入門編)
  • 複合主キー「否定派」と「許容派」の論争 - 設計者の発言

    定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基的なレベルの議論が始まってしまったのか。2つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方(ID方式)が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子(オブジェクトID)を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア

    複合主キー「否定派」と「許容派」の論争 - 設計者の発言
  • データベース設計徹底指南

    DBエンジニアのための技術勉強会(第3回)で使用した資料です。主にリレーショナルモデルと正規化について解説しています。リレーショナルモデルの限界について正しく認識してこそ、リレーショナルモデルを理解したと言えると思います。

    データベース設計徹底指南
  • Data Models

    Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves

    Data Models
    Jxck
    Jxck 2013/06/25
    DB pattern model
  • dbpatterns.com

    This domain may be for sale!

  • 【DB概論】データベース設計の目的・まとめ

    DB概論】データベース設計の目的・まとめ:できるエンジニアになる! ちょい上DB術・基礎編(6) デキるエンジニアになるためには、DB技術の基礎は必須です。連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。

    【DB概論】データベース設計の目的・まとめ
  • 1