Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQLと正規形のはなし

4,008 views

Published on

2016/07/02 YAP(achimon)C:: Asia Hachioji 2016 mid in Shinagawa

Published in: Technology
  • Be the first to comment

MySQLと正規形のはなし

  1. 1. MySQLと正規形のはなし 申し訳ない、あんまりMySQLのはなし出てこなかったDeath 2016/07/02 yoku0825 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa
  2. 2. \こんにちは/ yoku0825@とある企業のDBA オラクれない- ポスグれない- マイエスキューエる- 家に帰ると 妻の夫- せがれの⽗- ムスメの⽗- ⽣息域 Twitter: @yoku0825- Blog: ⽇々の覚書- MyNA ML: ⽇本MySQLユーザ会- MySQL Casualʼs Slack: MySQL Casual- 1/87
  3. 3. これまでの (︖) あらすじ 2/87
  4. 4. あらすじ MySQLで正規化すると遅くなる あるある- 節⼦、それ正規化が原因やない、内側のテーブルでソートし てるやんか YAPC::Asia Tokyo 2014 WHERE狙いのキー、ORDER BY狙いのキ ー - 「正規化したら遅くなった」テーブルを⾒せてもらったら正 規形じゃなかった テーブル分割≠正規化- イマココ- 3/87
  5. 5. 正規形 # とは 4/87
  6. 6. 正規化 #とは 関係の正規化(かんけいのせいきか)は、関係データベ ース (リレーショナル・データベース) において、正規 形と呼ばれる形式に関係(リレーション)を準拠させる ことにより、データの⼀貫性の維持と効率的なデータア クセスを可能にする関係設計を導くための⽅法である。 関係の正規化 - Wikipedia 5/87
  7. 7. ウッ 6/87
  8. 8. 正規化 #とは 更新箇所を減らす1. 参照効率を上げる2. データの整合性を守りやすくする3. ためのテーブル設計のプラクティス集 “Normal Form” だから “標準系” とか “平坦化” とかでもい い気がする(正規っていうと正誤の問題ぽく聞こえるから) 7/87
  9. 9. 正規形 第1正規形(1NF) 第2正規形(2NF) 第3正規形(3NF) ボイスコッド正規形(BCNF) 第4正規形(4NF) 第5正規形(5NF) 第6正規形(6NF) 8/87
  10. 10. MySQLerが絶対に押えておくべき正規形 第1正規形(1NF) 第2正規形(2NF) 第3正規形(3NF) ボイスコッド正規形(BCNF) 第4正規形(4NF) 第5正規形(5NF) 第6正規形(6NF) 9/87
  11. 11. 第1正規形 関係がスカラ値のみを持ちうるとき、その関係を第1正 規形 (first normal form; 1NF) であるという 関係の正規化 - Wikipedia 10/87
  12. 12. 第1正規形 全ての⾏の 全てのカラムの値が それ以上分割できない値であるとき 俺はアトミックな値って良く⾔う アトミックな値についてはあとで- 11/87
  13. 13. NOT NULLと候補キー 第1正規形の定義に⼊ってることもある 候補キーが無いと第2正規化のステップで詰まる 3NFを除いてこれ以降の正規化は全て候補キーを軸にテーブル分割す る - NULLABLE(NOT NULLしてない)と、第3正規化のステップ で詰まる ⼈間的な理屈で無理⽮理それっぽく分割することはできるけれど- 個⼈的にはこれらは第1正規形の前だと思ってる 12/87
  14. 14. 第2正規形 ある関係が、第1正規形で、かつ、すべての非キー属性 が、すべての候補キーに対して完全従属するとき、第2 正規形 (second normal form; 2NF) であるという 関係の正規化 - Wikipedia 13/87
  15. 15. ( ゚д゚) 14/87
  16. 16. (゚д゚) 15/87
  17. 17. (゚д゚ ) 16/87
  18. 18. 雑に⾏き ます 17/87
  19. 19. 第2正規形 候補キー(PRIMARY KEYとUNIQUE KEYだけど、何らかの 事情で制約をかけていないものも含む)が複数のカラムで構 成されているときに(複合候補キー) 複合候補キーの⼀部が決まれば値が決まるカラム がないと き 18/87
  20. 20. 第2正規形 候補キーが複数のカラムで構成されてない場合は 第1正規形 ⇔ 第2正規形 第1正規形であって第2正規形でない例 (prefecture, city)がPRIMARY KEY- 19/87
  21. 21. 第3正規形 ある関係が、第2正規形で、かつ、非キー属性があるな らば、それら全てが候補キーに非推移的に関数従属する とき、第3正規形 (third normal form; 3NF) であると いう 関係の正規化 - Wikipedia 20/87
  22. 22. 第3正規形 非キー属性(候補キーでないカラム)があるとき ある非キー属性の値が決まると、値が決まるカラム がない とき NULLABLEなカラムがあると、そもそも「値が決まらなくなる」ので 何とも⾔えなくなる - 21/87
  23. 23. 第3正規形 第2正規形であって第3正規形でない例 (name)がPRIMARY KEY- 実はもう⼀つ罠がある- 22/87
  24. 24. ボイスコッド正規形 ある関係上に存在する⾃明でない全ての関数従属性の決 定項が候補キーであるとき、かつそのときに限り、その 関係はボイス・コッド正規形 (Boyce/Codd normal form; BCNF) であるという 関係の正規化 - Wikipedia 23/87
  25. 25. ボイスコッド正規形 候補キーが複数のカラムで構成されているときに ある非キー属性の値が決まると、候補キーの⼀部が決まって しまうものがないとき 24/87
  26. 26. ボイスコッド正規形 第3正規形であってBCNFでない例(︖) PRIMARY KEY (ipaddr, port, process) に対して、protocolがわかれば processは⼀意に決まる場合 memcachedとInnoDB memcached Pluginが混在するとこの前提は崩れる - 25/87
  27. 27. ボイスコッド正規形 複合候補キーが複数 (ipaddr, port, process), (ipaddr, port, protocol) あって、それぞれの真部分集合 (ipddr, port) が重なってる場合にしか発⽣しない 候補キーの⼀部 と 非キー属性 (の全部または⼀部) から候 補キーの別の⼀部が決まるケース が ない このへんから「制約」の側⾯が強まってくる 26/87
  28. 28. 第4正規形 第4正規形 (fourth normal form; 4NF) では候補キーで はない属性への多値従属性をもった属性があってはなら ない。 関係の正規化 - Wikipedia 27/87
  29. 29. 第5正規形 第5正規形 (fifth normal form; 5NF) を満たす関係は、 その関係が第4正規形であり、さらにその関係に含まれ る結合従属性の決定項が候補キーのみである場合、かつ その場合だけである。 関係の正規化 - Wikipedia 28/87
  30. 30. 先に⾔っておくと BCNFを満たすリレーションのうち 非キー属性を持つものは ⾃動的に第5正規形 テーブルが 3カラム以上の複合候補キーだけで構成されてい る場合のみ 第4正規化と第5正規化を考える必要がある そんなテーブル作ったことあるお客様はいらっしゃいますか 29/87
  31. 31. 第4正規形 3カラム以上の複合候補キーのみで構成されるテーブルが1 つのカラムで交差している場合に分割する 30/87
  32. 32. 第5正規形 3カラム以上の複合候補キーのみで構成されるテーブルが2 つ以上のカラムで交差している場合に分割する 31/87
  33. 33. もうやめて︕ yoku0825のラ イフはゼロよ︕ 32/87
  34. 34. 第6正規形 A relvar R [table] is in sixth normal form (abbreviated 6NF) if and only if it satisfies no nontrivial join dependencies at all ̶ where, as before, a join dependency is trivial if and only if at least one of the projections (possibly U̲projections) involved is taken over the set of all attributes of the relvar [table] concerned. Sixth normal form 33/87
  35. 35. 第6正規形 複数の非キー属性を持つテーブルを 1テーブルあたり1候補キー:1非キー属性に分割する正規化 ドメインキー正規形と呼ばれる場合も(定義がブレてるらし い) 普通やらない 34/87
  36. 36. 第6正規形 5NFのこんなテーブルを +------------------------------------------+------+------+------+ | _hash_ | flg1 | flg2 | flg3 | +------------------------------------------+------+------+------+ | a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 | 1 | 0 | | da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 | 0 | 0 | | 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 | 0 | 0 | +------------------------------------------+------+------+------+ 35/87
  37. 37. 第6正規形 こうじゃ +------------------------------------------+------+ | _hash_ | flg1 | +------------------------------------------+------+ | a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 | | da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 | | 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 | +------------------------------------------+------+ +------------------------------------------+------+ | _hash_ | flg2 | +------------------------------------------+------+ | a12483faa7f1c90c568017314a7ffdc84b544bb1 | 1 | | da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 | | 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 | +------------------------------------------+------+ +------------------------------------------+------+ | _hash_ | flg3 | +------------------------------------------+------+ | a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 | | da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 | | 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 | +------------------------------------------+------+ 36/87
  38. 38. ドメインと命名 ルールとか考え る時に便利 37/87
  39. 39. 正規形 第1正規形(1NF) 第2正規形(2NF) 第3正規形(3NF) ボイスコッド正規形(BCNF) 第4正規形(4NF) 第5正規形(5NF) 第6正規形(6NF) 38/87
  40. 40. 正規形 2NF, BCNFとそれ以降への正規化は複合候補キーがある場 合のみ 4NF以降(ただし6NFを除く)への正規化は3カラム以上の 複合候補キーのみで構成される場合 だからだいたい1NF〜3NFまで(本当はBCNFまで)きっち り把握してればプラクティスの使い⼼地(学習コストと得ら れるメリットの割合)としては上々 39/87
  41. 41. ここまでのまとめ 正規化は 更新箇所を減らす&参照効率&データの整合性を上げるためのテーブ ル設計のプラクティス集 - 1NF〜3NFは割と簡単かつ効果が⾼い 4NF以降は3カラム以上の複合候補キーのみのテーブルに対してのみ 考える - 40/87
  42. 42. 第1正規形(again) 関係がスカラ値のみを持ちうるとき、その関係を第1正 規形 (first normal form; 1NF) であるという 関係の正規化 - Wikipedia 41/87
  43. 43. 第1正規形(again) 全ての⾏の 全てのカラムの値が それ以上分割できない値であるとき 42/87
  44. 44. アトミッ ク #とは 43/87
  45. 45. アトミック #とは それ以上分割できない 1⾏に複数の(候補キーで識別されるべき)主体の情報が⼊ってはい けない - 1カラムに複数の種類の情報が⼊ってはいけない- 分割しすぎてもとの意味が失われていない 「⽂字列型は配列だから1⽂字ずつがアトミック(キリ)」とかいう ことは起こらない - 44/87
  46. 46. 1⾏に複数の主体 mysql57> SELECT * FROM t1G *************************** 1. row *************************** v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で「ワ レワレハ、ウチュウジンデス」って言っててちょっと面白い季節がやってきま した。 yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bugs: # 81827: no stack trace on crash in freebsdnhttps://bugs.mysql.co m/bug.php?id=81827 yoku0825@gmail.com: Workbench使いにとっては大事なことかもしれ ない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bugs.my sql.com/bug.php?id=81971 1 row in set (0.00 sec) 45/87
  47. 47. ⾏を分割 mysql57> SELECT * FROM t1G *************************** 1. row *************************** v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で 「ワレワレハ、ウチュウジンデス」って言っててちょっと面白い季節がやって きました。 *************************** 2. row *************************** v: yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bug s: #81827: no stack trace on crash in freebsdnhttps://bugs.mysq l.com/bug.php?id=81827 *************************** 3. row *************************** v: yoku0825@gmail.com: Workbench使いにとっては大事なことかもし れない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bug s.mysql.com/bug.php?id=81971 3 rows in set (0.00 sec) 46/87
  48. 48. それでもまだ1カラムに複数の情報 mysql57> SELECT * FROM t1G *************************** 1. row *************************** v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で 「ワレワレハ、ウチュウジンデス」って言っててちょっと面白い季節がやって きました。 *************************** 2. row *************************** v: yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bug s: #81827: no stack trace on crash in freebsdnhttps://bugs.mysq l.com/bug.php?id=81827 *************************** 3. row *************************** v: yoku0825@gmail.com: Workbench使いにとっては大事なことかもし れない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bug s.mysql.com/bug.php?id=81971 3 rows in set (0.00 sec) 47/87
  49. 49. カラム分割 mysql57> SELECT * FROM t1G *************************** 1. row *************************** u: yoku0825@gmail.com v: せがれが扇風機に向かってですます調で「ワレワレハ、ウチュウジンデス」 って言っててちょっと面白い季節がやってきました。 *************************** 2. row *************************** u: yoku0825@gmail.com v: "Noted in 8.0.0 changelog." nnMySQL Bugs: #81827: no stack t race on crash in freebsdnhttps://bugs.mysql.com/bug.php?id=81827 *************************** 3. row *************************** u: yoku0825@gmail.com v: Workbench使いにとっては大事なことかもしれない。nnMySQL Bu gs: #81971: Needs HiDPI supportnhttp://bugs.mysql.com/bug.php?id =81971 3 rows in set (0.00 sec) 48/87
  50. 50. ところで 49/87
  51. 51. yoku0825@gmail.com ってアトミック︖ 50/87
  52. 52. yoku0825@gmail.com はアトミックか ほとんどのサービスにとってはアトミック Twitter, Slack, GitHub, Oracle Single Signin On, ..- yoku0825@gmail.com をメールアドレスだとしか認識してない⼈たち アカウント名が yoku0825 なのは俺がそう設定したからであって、関連はない(彼ら にとっては) - 51/87
  53. 53. yoku0825@gmail.com はアトミックか たまに、アトミックじゃないサービスがいる GMail, その他MTAさんたち- yoku0825@gmail.com は gmail.com の yoku0825 ユーザー DNSさんにとっては gmail.com もアトミックじゃない - 52/87
  54. 54. つまりアトミック #とは 設計次第 なんだけど LIKE 演算⼦や SUBSTR 関数を使ってるなら、それは多分アト ミックじゃない ⇔ アトミックなら LIKE 演算⼦や SUBSTR 関数を使ってない 配列型(MySQLにはない)やJSON型もBLOB型も、SQLからはPKで 引いてアプリケーション側でゴニョゴニョするならリレーショナルモ デル的には正規形 - SET型(こんなデータ型MySQLくらい︖)さん…- 53/87
  55. 55. 第2正規形(again) ある関係が、第1正規形で、かつ、すべての非キー属性 が、すべての候補キーに対して完全従属するとき、第2 正規形 (second normal form; 2NF) であるという 関係の正規化 - Wikipedia 54/87
  56. 56. 第2正規形(again) 候補キー(PRIMARY KEYとUNIQUE KEYだけど、何らかの 事情で制約をかけていないものも含む)が複数のカラムで構 成されているときに(複合候補キー) 複合候補キーの⼀部が決まれば値が決まるカラム がないと き 55/87
  57. 57. 第2正規形 第1正規形であって第2正規形でない例 (prefecture, city)がPRIMARY KEY- prefectureが決まるとprefecture̲kanaは⼀意に決まる- 56/87
  58. 58. 第2正規形 57/87
  59. 59. 第2正規形 +--------------+----------------------+ | _prefecture_ | _city_ | +--------------+----------------------+ | 北海道 | 札幌市中央区 | | 北海道 | 札幌市北区 | | 北海道 | 札幌市東区 | +--------------+----------------------+ +--------------+-----------------------+ | _prefecture_ | prefecture_kana | +--------------+-----------------------+ | 北海道 | ホッカイドウ | +--------------+-----------------------+ +--------------------+--------------------------------------+ | _city_ | city_kana | +--------------------+--------------------------------------+ | 札幌市中央区 | サッポロシチュウオウク | | 札幌市北区 | サッポロシキタク | | 札幌市東区 | サッポロシヒガシク | +--------------------+--------------------------------------+ 58/87
  60. 60. 正規化の醍醐味 北海道の読みが「でっかいどう」に変わった時にテーブルま るごと更新しなくていい 更新箇所を減らす- prefecture vs. prefecture̲kana を⾒れば容量がコンパク トになっているのは⼀目瞭然 参照効率を上げる- city̲kanaはこの⾯微妙。。 カーディナリティー依存 - 北海道の読みが「ほっかいどう」であることを保証できる (整合性の保証) 元のテーブルで SELECT DISTINCT prefecture_kana FROM .. WHERE prefecture = '北海道' が2⾏返ってきちゃったら、どっちが正しい のかは機械は判断できなくなる - 59/87
  61. 61. 第3正規形(again) ある関係が、第2正規形で、かつ、非キー属性があるな らば、それら全てが候補キーに非推移的に関数従属する とき、第3正規形 (third normal form; 3NF) であると いう 関係の正規化 - Wikipedia 60/87
  62. 62. 第3正規形(again) 非キー属性(候補キーでないカラム)があるとき ある非キー属性の値が決まると、値が決まるカラム がない とき 61/87
  63. 63. 第3正規形 第2正規形であって第3正規形でない例 62/87
  64. 64. 第3正規形︖ 63/87
  65. 65. 第3正規形︖ +----------------------+------------+ | _name_ | birthday | +----------------------+------------+ | yoku0825 | 1982-08-25 | | yoku0825の妻 | 19xx-01-17 | | yoku0825のせがれ | 20xx-05-27 | | yoku0825のムスメ | 20xx-01-05 | +----------------------+------------+ +------------+-----------------+ | _birthday_ | birthday_stone | +------------+-----------------+ | 1982-08-25 | ペリドット | | 19xx-01-17 | ガーネット | | 20xx-05-27 | エメラルド | | 20xx-01-05 | ガーネット | +------------+-----------------+ 64/87
  66. 66. 第1非正規形になってしまった birthdayがアトミックじゃない +----------------------+------------+ | _name_ | birthday | +----------------------+------------+ | yoku0825 | 1982-08-25 | | yoku0825の妻 | 19xx-01-17 | | yoku0825のせがれ | 20xx-05-27 | | yoku0825のムスメ | 20xx-01-05 | +----------------------+------------+ +------------+-----------------+ | _birthday_ | birthday_stone | +------------+-----------------+ | 1982-08-25 | ペリドット | | 19xx-01-17 | ガーネット | | 20xx-05-27 | エメラルド | | 20xx-01-05 | ガーネット | +------------+-----------------+ 65/87
  67. 67. 改めて第1正規系のプロセスを通すと第3正規形に 66/87
  68. 68. 改めて第1正規系のプロセスを通すと第3正規形に +----------------------+------------+ | _name_ | birthday | +----------------------+------------+ | yoku0825 | 1982-08-25 | | yoku0825の妻 | 19xx-01-17 | | yoku0825のせがれ | 20xx-05-27 | | yoku0825のムスメ | 20xx-01-05 | +----------------------+------------+ +------------+------------+ | _birthday_ | birthmonth | +------------+------------+ | 1982-08-25 | 8 | | 19xx-01-17 | 1 | | 20xx-05-27 | 5 | | 20xx-01-05 | 1 | +------------+------------+ +--------------+-----------------+ | _birthmonth_ | birthday_stone | +--------------+-----------------+ | 1 | ガーネット | | 5 | エメラルド | | 8 | ペリドット | +--------------+-----------------+ 67/87
  69. 69. キモい… 68/87
  70. 70. 現実問題、中間テーブルはかっ⾶ばす name_birthday JOIN birthmonth_stone ON MONTH (birthday) = birthmonth で仕留める リレーショナルモデルの世界には MONTH 関数なんてないの で、中間テーブルを作らないと birthday と birthmonth の 対応が取れない そういう世界線なのだと割り切る- 現実世界では birthday が判れば birthmonth を⼀意に識別 できる 意味的に MONTH 関数が中間テーブルを提供してくれる- 69/87
  71. 71. さてみなさん お気付きだろ うか 70/87
  72. 72. 3NFまでの正規化では、分割の軸になったカラムが必ず新 しいテーブルの候補キーになる 71/87
  73. 73. 候補キーで分かれるという意味 そのリレーション(テーブル)で表現されるもの(=⾏)が 分けられるということ name̲birthday は「⼈間」が主体(名前で識別される “⾏”)だろう し - birthmonth̲stoneは「誕⽣⽉」が主体(1〜12で識別される “⾏”) だろう - 何の「属性」だかわからなくなったものを、それぞれ正しい「クラ ス」に割り振り直すのが正規化 - 72/87
  74. 74. 候補キーで分かれることが実際に起こすもの というわけでJOINのインデックスはPK狙いになる MySQLはPK狙いのJOINならそれなりに速い- というか PKで結合できないなら分割の仕⽅間違ってる あるいは、正規化とは関係ない別のテーブル分割の問題- 過剰分割とかね- 73/87
  75. 75. 候補キーで分かれることが実際に起こすもの そして出てくる 内側テーブルの “ORDER BY狙いのキー” が 選べない問題 真⾯目に(︖)正規化すると、サブクエリーやGROUP BYと のJOINをしたくなる SELECT user_id, tweet_count FROM user JOIN (SELECT user_id, COUNT(*) AS tweet_count FROM tweet GRUOP BY user_id) USING (user_id) ORDER BY tweet_count DESC .. - こんなことするとしんでしまいます 「正規化すると遅い」が真になる瞬間 - 74/87
  76. 76. ⽇常的にこんなクエリーが流れてくる世の中 75/87
  77. 77. 驚きのinnodb̲rows̲read 76/87
  78. 78. COUNTで死んでしまうこんな第5正規形を 77/87
  79. 79. COUNTを避けるためにテーブルをこうしたとしたら 78/87
  80. 80. それは正 規形︖ 79/87
  81. 81. 正規形は正規形 「ただし、明らかに冗 ⻑」by C.J.Date 80/87
  82. 82. 正規化かどうかは別として、同じフレームで評価すると 参照効率を上げる 成功してる- 更新箇所を減らす 2テーブル更新しなきゃいけなくなったから失敗してる- 整合性の保証 トランザクションがあるとはいえ制約は失った(=整合性は保証され ない) 正しくトランザクションが使われている限りは 整合性があるけれど、 正しくトランザ クションが使われていることそのものは誰も保証してくれない - 81/87
  83. 83. あんまり望まし い⽅向じゃなか った(´・ω・`) 82/87
  84. 84. とはいえこれイン デックスを思い出 しませんか︖ 83/87
  85. 85. インデックス(ただし禁書目録ではない) ソート済みのデータの複製 予めソートした状態でデータのサブセットを作っておくことで、検索 時の探索効率を上げる - 重複をなくした設計にしましょうって⾔ってるRDBMSが基 本的な機能として、「データを敢えて重複させている」とい うのは業が深くて考えさせられる 重複させても不整合が出ないように、重複させるオーバーヘッドを取 り除くために、裏側の実装はすんごくがんばってる - それと同じだと割り切れば、上⼿い使い⽅として付き合うこ とはできる FriendFeed では MySQL を使いどのようにスキーマレスのデータを 保存しているのか (⽇本語訳) - FriendFeedがFacebookに買収されてサービスを終了したので、原⽂はリンク切れ - 84/87
  86. 86. 後半のまとめ 正規化は “⾏” が表すものをクラス化する作業 候補キーはインスタンス、非キー属性はプロパティーみたいな感じ- ⼿順通りに3NFまで正規化するとJOINはPK結合になるはず PK結合にならなかったら正しく分割できていないか、正規化とは別の テーブル分割をしたのか - 別のクラスのプロパティーとして再定義することで(せめ て)正規形を保ちつつ冗⻑な⽅向に倒す インデックスと同じ考え⽅- 正規化と同じ評価軸を使うと、どこまで論理的にアレな感じかの尺度 として⾒られる - 85/87
  87. 87. 参考情報 あなたが知らない リレーショナルモデル 理論から学ぶデータベース実践⼊門 Amazon.co.jp︓ SQL and Relational Theory FriendFeed では MySQL を使いどのようにスキーマレスの データを保存しているのか Where狙いのキー、order by狙いのキー 86/87
  88. 88. Questions and/or Suggestions? 87/87

×