Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

DB設計に関するclavierのブックマーク (5)

  • 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
  • 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
  • イミュータブル(不変)なDB設計 - 浜村拓夫の世界

    イミュータブル - Wikipedia オブジェクト指向プログラミングにおいて、イミュータブル(immutable)なオブジェクトとは、作成後にその状態を変えることのできないオブジェクトのことである。対義語はミュータブル(mutable)なオブジェクトで、作成後も状態を変えることができる。 イミュータブルなオブジェクトを使うと、複製や比較のための操作を省けるため、コードが単純になり、また性能の改善にもつながる。 しかしオブジェクトが変更可能なデータを多く持つ場合には、イミュータブル化は不適切となることが多い。 このため、多くのプログラミング言語ではイミュータブルかミュータブルか選択できるようにしている。 最近、DBの設計で、論理削除はダメだという話が盛り上がっていた。 Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku

  • アプリを作るときに気をつけたかったDB設計のこと - チョモランマに登るには。

    こんにちは。 最近秋晴れの日が続いて気持ちがいいですね。 紅葉が待ち遠しいです。 mine改修の進捗状況 さて僕の一つ目のアプリ、mineの改修作業を初めて何週間経ちましたでしょうか。 割と早く終わるかなと思いきや、結局ずるずると時間がかかっています。 結局何に時間がかかるのかというと、データの移行とか、前のバージョンとの兼ね合いを考慮しないといけない点なんですね。 前から使っている人が今回の大規模なアップデートによって使えなくなったり、データがおかしくなったりしないように気をつけなくてはいけません。 この点では先にチャットノベルで結構やらかしてしまったので、余計にびびっています。 でも普通のアップデートなら別にそんな気にすることはないと思うんです。 じゃあなぜ僕はこんなに気を使っているかというと、作るときにデータ構造の設計を間違えてしまったんです。 つまりデータをどう扱うかっていうところ

    アプリを作るときに気をつけたかったDB設計のこと - チョモランマに登るには。
    clavier
    clavier 2015/10/16
    アプリを作るときに気をつけたかったDB設計のこと - チョモランマに登るには。
  • 論理削除がデータを汚している - jfluteの日記

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

    論理削除がデータを汚している - jfluteの日記
  • 1