idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
新人にオブジェクト指向の魅力を知られてはいけない - 設計者の発言
新人研修の季節に思うところを書こう。開発作業の中核として活躍するはずの中堅技術者の多くがまともにDB設計できない、という寒々した状況がある。関数従属性も移動平均単価も知らない「設計担当者」がいたりする。私にとってその原因は明らかで、８０年代から９０年代にかけて注目されたDB設計や業務知識の重要性を、「オブジェクト指向」が怒涛のように押し流してしまったためだ。業務システム設計にとっての「失われた２０年」といっていい。 具体的には、JavaやRubyといったオブジェクト指向言語ベースのフレームワーク（未完成な骨格のようなコード群）を用いた開発スタイルが一般的になったためでもある。その結果、新人教育がオブジェクト指向言語の一辺倒になった。同時に、クラス設計を学べばDB設計も学んだことになると勘違いされて、「実装手段から独立したDB設計の枠組み」を学ぶための気運が失われた。IDのような単独主キーだ
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
片手間MySQLチューニング戦略
