タグ

dbと設計に関するsds-pageのブックマーク (5)

  • 「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング

    はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 番環境の住所情報テーブルをdropするまでの作業 今回、番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC

    「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
    sds-page
    sds-page 2017/05/26
    一月様子を見て大丈夫だと思ってたら年末調整とかの年一処理でいきなり必要になる類の奴
  • 論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ

    互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。

    論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
    sds-page
    sds-page 2015/09/01
    そういう設計で通じる場合もあるって事でしょ。全否定は視野が狭すぎる
  • 論理削除はなぜ「筋が悪い」か

    「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」(トランザクション)は不定形(どのテーブルをどのように修正するかはアプリケーション依存)だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる(というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが

    sds-page
    sds-page 2015/03/26
    エンドユーザーの誤操作でデータが消えないような設計なら良いのかな?具体例も無いしちょっと現実的じゃない提案
  • SQLのUPDATE文と履歴系テーブル - mike-neckのブログ

    大したことは書いてありません。 気付いたことのメモ程度です。 『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 』を少し屋で立ち読みしました。(ノットワーキングプアにあえいでいるので立ち読みしかできない(´・ω・`)) このの中で履歴系テーブルの扱い方というのに丸々一章が割り当てられていました。 だいたいこんなことが書かれてたと思う。 「時間軸と直交していない」という点は、履歴テーブルは過去の事実の集合で、データを取得する条件が変われば結果が異なるのは当たり前だと思うんだけども。— enum (@enum) 2015, 3月 16 たしかに、RDBMSでは履歴データというのは相性が悪い。 僕は陸上競技を見るのが好きなので、これのデータモデルをたまに考えたりしています。で、選手の氏名が変わることあるよなーと考えると、こ

    SQLのUPDATE文と履歴系テーブル - mike-neckのブログ
    sds-page
    sds-page 2015/03/25
    消費税率変更前後の単価と金額で集計かけるときとかみんなどうしてるんだろ
  • 論理削除が云々について - mike-neckのブログ

    今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意

    論理削除が云々について - mike-neckのブログ
    sds-page
    sds-page 2015/03/25
    テーブル1600個とか管理できる気がしない。適材適所って感じがする
  • 1