「完璧な表」は扱いづらい。データ配置理論の皮肉。【データベース4】#90

「データベース」の第4回です。「レシピの洗練とデータベース設計は一緒」「正規化をして表の冗長性をなくそう」「未来のデータベースの形はどうなる？」など、正規化する際の重要な点について話しました。
【Notionでデータベースを使いこなそう！】
ntn.so/yurucom
【目次】
0:00 レシピの洗練とデータベース設計は一緒
1:26 正規化しをして表の冗長性をなくそう
9:34 ここでも重要なdivide and conquer
15:41 人生は妥協でできている
22:15 結局のところは「どう分割するか」
26:02 Notionはなぜ画期的か？
【参考文献】
○データベースシステム（改訂2版）
amzn.to/3qeyt3V
【サポーターコミュニティ加入はこちらから】
yurugengo.com/support
【親チャンネル：ゆる言語学ラジオ】
/ @yurugengo
【実店舗プロジェクト：ゆる学徒カフェ】
/ @yurugakuto
【おたよりフォーム】
forms.gle/BLEZpLcdEPmoZTH4A
※皆様からの楽しいおたよりをお待ちしています！
【お仕事依頼はこちら！】
[e-mail]
【堀元見プロフィール】
慶應義塾大学理工学部卒。専門は情報工学。WEBにコンテンツを作り散らかすことで生計を立てている。現在の主な収入源は「アカデミックに人の悪口を書くnote有料マガジン」。
Twitter→ / kenhori2
noteマガジン→note.com/kenhori2/m/m125fc452...
個人KZbin→ / @kenhorimoto
【水野太貴プロフィール】
名古屋大学文学部卒。専門は言語学。
某大手出版社で編集者として勤務。言語学の知識が本業に活きてるかと思いきや、そうでもない。
Twitter→ / yuru_mizuno
【姉妹チャンネル】
◯ゆる音楽学ラジオ( / @yuruongaku )
◯ゆる民俗学ラジオ ( / @yuruminzoku )
◯ゆる天文学ラジオ ( / @yurutenmon )
◯ゆる書道学ラジオ ( / @yurushodo )
◯ゆる生態学ラジオ ( / @yuruseitai )
◯ゆる哲学ラジオ ( / @yurutetsugaku )
#データベース #ゆるコンピュータ科学ラジオ_データベース

[@yurucom]

【Notionでデータベースを使いこなそう！】 ntn.so/yurucom 【参考文献】 ○データベースシステム（改訂2版） amzn.to/3qeyt3V 【サポーターコミュニティ加入はこちらから】 yurugengo.com/support 【おたよりフォーム】 forms.gle/BLEZpLcdEPmoZTH4A

[@pistlove]

この手の論争の原因は、ユーザは見た目の「プレゼンテーション層」と再利用のために「データ層」を同時に欲しがっているのが原因だと考えます。　解決方法としてはシートを二枚作り、裏のデータ層には正規化された表を作り、見たり印字するためのプレゼンテーション層としてのシートを表に出しておけばよいと考えます。

[@hirobou3]

ビットフィールド的な概念出せるのさすが水野さんという感じ

[@doridoriization]

生命、宇宙、そして「ゆるコンピュータ科学ラジオ」についての究極の疑問の答え　→　Divide and Conquer

[@HighCaloLily]

良いねの数が42になっていて美しすぎるのでこれ以上誰も押せなくなってて笑う （押したい人は私のコメントに押してもいいですよ）

[@akinaka7543]

@@HighCaloLily こんにちわ。ってなわけで押させていただきました。もう次はコメント数=42を目指すしか無いですねw

[@knngayr]

データベース回頭から見てもやっぱり水野さんの頭の回転の良さから出力される終わってるメモのギャップで笑っちゃう

[@whzwiz]

水野さんの小数点以下アイデア、とても良いしchmodとかでもおなじようなことをしているものの、それ第1正規形を満たしていない

[@carchess1896]

Webプラットフォーム的なサービス開発をしてる身なので、割と第5正規形が必須だという派閥です。 SQLの実行速度の観点では、第五正規形の方が実行計画が上手く立つので処理は早い事が多い体感です。 SQL自体も、正規性が担保されていれば割と半自動レベルで作れるので楽です。 APIで返すにも分割単位がDBと一致するので管理が楽で再利用性も高く、めっちゃメリットだらけに感じています。 見づらい問題は、そもそも人が見るならviewで整形する前提なので確かに情報整理の観点では第三までで良さそうですが、システムDBで使うなら限界まで正規化した方がいいと思っています。

[@nanoriKYDO]

「キー」という言葉を使わずに説明していく姿勢に憧れを抱きました

[@HijiriTachibana]

わかる。初学者主キー・外部キー分からないがち。

[@kamodomon0913]

@@HijiriTachibanaキーと言われたらデータベースを触ってない人は家や車の鍵 を想像するし、そのキーを使って複数のデータベースにアクセスすると言われたら、色んな家を同じ鍵で開けて入るイメージになるので何が良いことなのかさっぱりわからなくなりますよねｗ 現在だと主キーに限って言えばマイナンバーと言えば通じるのかもしれませんね･･･と思ったけど、それが理解されていないからカードの中に預金情報や通院履歴などが入っていると勘違いしてる人が居るのか･･･。

[@kuppa222]

これ〇〇回の後に基本情報の問題を水野さんに解かせて、 全て周り切ったあとにノー勉で水野さんに基本情報受けさせる企画やってほしい

[@kei5328]

水野さん、Bitmaskを自分で思いつくのか。素晴らしいな。

[@user-sj1sn9dv5s]

「一括置換する」とか「全部同じ修正をするのが大変」っていう語り口だと第5正規化の有用性はピンと来ないと思ってる。 「一部だけ修正することで不正な状態を保持できてしまう」っていうことが重要なのかなと思いました。

[@kirinkame]

水野さんのアイディア、小数点じゃなくて固定長だけどうちのシステムで使ってたわ。 抽出する時煩雑になる仕組みで好きじゃなかったけど、あの短時間で自力で同じ考えに至るのスゴ！！

[@garhyla]

「JavaとJavaScriptは加藤あいと阿藤快ぐらい違う」はワロタ

[@TM-yp2eo]

使い古された表現なんだけどな…

[@YS-sz7rm]

くりぃむ上田ですね。 同系に「アン・ルイスと半ライスくらい違うよ！」があります。

[@術中hack]

メロンとメロンパンくらい違うって聞いたことがある

[@remio39ryobb]

飛ばしてはくれてんのねぇ。

[@masayokami]

クリシェっちゃクリシェ

[@aliliciganske337]

「朝涼」鏑木清方が自分の娘を描いた日本画で、私の大好きな作品のタイトルになっています。番組内では文字でも声でも何度も登場し、こんなにも誰かが触れている様子を見てなんだか嬉しく思います。 蓮の花が綻ぶ道をそぞろ歩くうら若き乙女。まさに「朝涼」（夏の朝の涼しいころ）を表した爽やかな一枚です。

[@ch-py7lw]

ずっと待ってた！

[@yukonsw]

フラグ立てを独自開発(ただし車輪の再発明)した水野氏

[@dog--4773]

人間にとって見やすいピボットテーブル的な表のデータをそのままBIツールにくわせても理想のグラフができないで困っている今の私にはめちゃくちゃためになりました。

[@paaman815]

ビッグデータ扱うとかじゃない限り、今は第5正規形まで正規化したほうが早いパターンのが多いですね

[@mxs105]

今回のサムネ頑張ってるなあ😂 中身もおもしろかったです

[@user-yt4pi5mc9n]

使いやすい表の定義も、システムの規模や運用者の属性、テーブルの更新頻度や格納するデータの性質など様々な要素によって変わっていきますよね。 統計取ってどの要素が一番正規化への影響が強いか見たら面白そう

[@mudaso-heavy-user]

楽しみに待ってました

[@tsicsafjapan9371]

たのまち(5時間遅れ)

[@cakirgokceyilmaz7743]

以前,多すぎる選択肢に疲れて使うのやめてkeep使っているのですが、 とてもおもしろくてnotion猛烈に使ってみたい…となったので他に有能なテンプレートがあったら配布していただけるとめちゃくちゃうれしいです

[@Ai-ttkw]

Accessの設計を仕事でしているので、データの整合性とかリレーションとか、首がもげそうなほど頷きながら見てました。横に40項目有るデータを縦型に変更するためにunionクエリでSQL書いたり、一般人が作ったデータを正しく整えるのめっちゃ大変。

[@user-zj4cv4gy1z]

水野さん正規形は、不動小数点数表現の誤差というか、解像度の限界で行き詰まりますね。 結局は一つの変数のビットフィールドを複数の項目でシェアしているだけなので、予めたくさんのカラムを用意しておくことと本質的に変わらないですね。

[@user-uy4br8kv4b]

行き詰まんないと思うけど。 あと浮動ね。

[@user-zj4cv4gy1z]

@@user-uy4br8kv4b 浮動小数点は変換ミスです。大変失礼しました。 「行き詰る」について、前提としてデータベースがコンピューター上に実装されるとします。 コンピューターは2進数で数を扱うので10進数の小数を正確に表現できずに微小な誤差が出ます。 これを「丸め誤差」と呼びます。 属性が少ない場合は「微小な誤差は無視する」で通用しますが、属性が増えて桁が細かくなってくると「丸め誤差を無視できなくなるのでは？」という指摘です。 言語によっては10進数の小数を正確に表現できるような型もありますが、こちらも扱える桁数は有限なので、「無限に属性を追加できる」ものではないと補足します。

[@user-zj4cv4gy1z]

訂正ついでに、「ビットフィールド」という表現も間違ってましたね・・・ 「変数が64ビットなら表現できる数は2^64種類で、それ以上の状態の組み合わせを扱うことはできないのでは？」というのをうまいこと言えなかったっす・・・

[@user-lj7wc2dl2s]

「実践編」と第して、水野さんのデータベース関連のお悩み解決シリーズ見てみたいです！結構ネタありそうですね。

[@user-jq2hc8fi4l]

このシリーズで1番ためになって面白かったのはコピミズム伝道協会

[@masuo64]

※ただし信仰の対象はコピー＆ペーストではなく著作物の違法コピー

[@user-rj3xr3yz4f]

文系の私としては、水野さんの小数点をつける方法は、論理哲学論考みたいな目次味を感じました笑

[@hw6043]

アフターストーリー楽しみにしています。因みに、水野さんよりもっと使いこなしてなかった私がウェブサイト作れる事実を知って、課金ユーザーになりました。

[@efo1187]

JSONは入れ子にするとセルの結合みたいな構造も許容されるから感覚的にわかりやすい感じします

[@munji_ccr]

小数でフラグ管理するのおもろいですね。 新しい性質が増えた時に、過去に追加した項目もその性質を持っている、のような時に大変かもしれませんが……

[@anz2779]

この動画シリーズを観てNotion使い始めました。車の整備記録をエクセルに入力していたのですが、Notionに移行してから煩雑な入力が減りすこぶる快適です。 ただ、数値の単位が通貨しかないのがちょっと不満です。カスタムで任意の単位を追加できたらいいのにと思いました。

[@rachelhash1603]

コピミズム伝道教会の存在を知り、前回このチャンネルのコメントで紹介した『コピペ害悪論』の教授はここと宗教的に対立しているというイメージがつきました。本当にありがとうございました。

[@naiwanaidaroG]

言語オタクがデータベースを駆使し自分だけの辞書を作る物語の始まり

[@user-cp3ey7cz7z]

Notion, 使ってみます！🎉

[@yassu3015]

野菜メモはその後どう管理することにしたのかも聞きたいですね！！

[@user-im5nm3ez3w]

データベース面白かったから非リレーショナルデータベース楽しみ

[@user-ot2xz2gi6w]

ビット桁で情報を持つ水野案はデータベースとしては0点だけどむしろアプリケーション側で権限とか情報の持たせ方を工夫するときにちょくちょく見かける気がする SUMしか使えない機械オンチなのにこれが思いつくあたりが流石のセンス

[@Chloe-1006]

社内でNotionの使い方勉強会するために参考にさせてもらいました。もっとやってほしいです！

[@user-fu1qz9bv7p]

18:50 「知的好奇心がドライブされて後世に任せる」ここの水野さんの言葉最高だな。。。

[@pantrois]

水野さんのような小数点のような発想は、カラムの追加などが容易ではない 昔のデータベースなどのときに使用されました 例えば図書館の本の属性を管理するのに ①図書館所蔵の本である ②閲覧に司書の許可がいる ③持ち出し禁止である という３種のフラグが必要な際に ①を1、②に2、③に4といった数字を振って たとえば図書館所蔵で持ち出し禁止の際には1+4=5を記録しておく これの利点は、更にフラグを増やす場合には8、16…と増やしていける点 欠点はめんどくさい ので、自由にカラムを追加できる現代では次第に使われなくなりました。

[@akinaka7543]

Ruby on Railsのhas many throughは、第5正規系なテーブル定義を作らせる方向にアプリ開発者(エンドユーザではなく)を誘導する仕掛け、ってことになるのかな。

[@yuragi1146]

売り上げ管理をnotionでしてますー。もちろん表計算もできるし、同じ数字で同じ品名ばっかりだから、テンプレ挿入でポンポン追加できるの楽だしミス少なくて便利！ スマホからもPCからも使えるし。 ほかは、作業メモとかの箇条書き形式ばかりですが…、わざわざ多機能なnotionを使わなくてもいいんだけど、UIがいいしついついnotionを使っちゃうんですよねぇ。

[@llil7934]

12:48 　ネ　申　の　一　手

[@jing7968]

自動でIDを振るのは賛否ありますね。正規具合は変わらず、入力に対しても挙動が一定じゃないので分散処理や複数環境に向かないため、振らなくても一意になるなら振らない方が良い場合も多いですね。

[@user-bj3sz6bm8e]

Notionこんなに便利だったんですね！（反響） 私はゲームエンジニアなんですが、このキャラがこのアイテムを持ってるなどの初期データをNotionで管理するのありかも…となりました

[@takutoezx]

DjangoやRailsなんかのフレームワークだと全部自動で第五正規形になってる気がする！ ただのデータとしてはそこまでする必要ないけど、例えば多言語対応等で後からテーブルを追加したり、複雑な操作が入ってくるのを考えると第五正規形最強なのでは？

[@yuukostar3129]

むっちゃ笑えました。 漫才とか見ているより楽しいかも。

[@todays9890]

Notionはスペース押したときにAI機能が勝手に出るのを設定でOFFにできるようにしてほしいのと、バナーみたいに画像を押したらリンク先のページに飛べる機能を実装してほしい

[@user-op1ez9qw6g]

これ聞いてマジでnotion使いたくなった！ ISO9000のマネジメントにも使えるみたいです

[@youyam8409]

「百科事典棒」から発想した水野さんの小数点のアイデアを堀元さんが「お？」と反応するところが私的にハイライトでした。論文の引用もプログラミング的再利用ですね。

[@ofoneDyag]

水野さんの小数点の案は、２進数でやればプログラミングっぽくなるね。２進数の１桁目が１なら状態A、みたいな。

[@user-yp1rl5yz9k]

Notionのデータベース機能初めて知りました。リレーショナルデータベースおじさんなので面白そうだなと思いました

[@arcsin1203]

水野式は素数の積でも同じ考えになりそうですね 「語釈が面白い」=2 「知らなかった」=3 「語釈が面白い」かつ「知らなかった」=6 結局タグ使った方がよい

[@user-bv2so7jz7c]

知恵の深そうな話　楽しいですなあ

[@user-pw6bg8lu9e]

7:11 性質の要素毎に桁を用意して、フラグを01としてuintとかに突っ込むヤツだ、と思ってコメント欄を見たらビットフィールドって名前があるんですね。勉強になりました。 それはそれとして本質的には性質の列を増やしているのと何も変わらない、むしろ扱いにくくなってるような

[@hyper264]

「人生は妥協」というのは、「なるほどなぁ」と思いました。 私自身、C言語を使用していますが、確かに同じ機能は関数化(一つの機能として独立)し、他の処理でも使えるようにしています。 ただし、その関数に変更を加えると、その関数を参照している処理すべてに影響がでてしまいます。 なので、影響範囲次第では「変更」か「新規」かを使い分けてますね。

[@user-jo5go4qc2k]

7:08 複数の真偽値を一つのセルで管理する際、それぞれの真偽値を2進数羅列しその10進数の値を格納する、というやり方があります。 「知らなかった」だけなら01(2) = 1(10)、「語釈が面白い」だけなら10(2) = 2(10)、「知らなくて語釈が面白い」なら11(2) = 3(10)

[@rabutlilriddle1904]

気持ちはすごくよくわかります。 分りますが、DB屋はこれをやられるとスン…って遠い目になってしまいます…。 おねがいなので、どうか、普通に正規化してください…。

[@user-jo5go4qc2k]

@@rabutlilriddle1904 いかにしてデータサイズを節約するか…の思考で生まれたやり方っぽいですよね。 古のシステムでしかほぼ見ないです。

[@bluegear8780]

古いシステムだとよくあるやつ

[@EanaHufwe]

二進数フラグってCとかの言語で結構よく使う気がする、そしてデバッグする時に値を見て「なにこれ」になって、いちいち各けたの意味を調べなきゃとすごく面倒臭い

[@Kureham]

組込み屋さんには馴染み深いんだよなぁ

[@user-qc8zs6rh1g]

3:17 ｛単語、性質}→｛意味、備考｝の関数従属性に対して、｛単語}→｛意味、備考｝が成り立つから 第二正規形にもなってなさそうだけどどうなんだろ？

[@mudaso-heavy-user]

アフターストーリー楽しみに待ってます

[@yurucom]

ありがとうございます！いつか世に出しますね！！！

[@jajathree9506]

@@yurucom 半年後、１年後の水野さんの成長、待ってます。

[@tsicsafjapan9371]

アフまち

[@akinaka7543]

14:50 IDが自動採番されてくれる仕組の話(人工キー)は、RDBの理論とはまた別の話なような気がするけど、まあ実用的には私もそういう説明が一番しっくりくるので賛成に一票。編集容易性も別話題だけど、もともとあの理論(だけ)だと編集などの運用容易性を考慮してない節が有って"刺さんない"んで

[@user-ru9pk4qr4u]

無料だったのか ここまでオススメされると、触ってみようかなとなる

[@arigayas]

水野さんにNotionの使い方を教える回をやったら面白そう。

[@WinLinux1028]

正規化して整合性が取れるようにしつつ､パフォーマンスもある程度取れる方法としてマテリアライズドビューってのはあったりする

[@jyozu]

ストレージを優先するか、処理速度を優先するかで使い分けますよね。 最近はコードファーストでDBがマイグレできる環境があるんで、 第一正規系になっていない表で列を後から増やす・減らすの手法もありなんじゃないかと思いました。 Notionのバックエンドエンジニアの募集要項はDB系だとこのへん（Memcached、Postgres、Elasticsearch）の知識があることってなってますね。

[@RIAFeed]

小数点は残念ながら一般的なDBでは正確には表現出来ないので数値をビットに見立ててやるのが確実かな

[@user-nh9xk1rc8u]

既定値の概念を独自に考え出す水野さん　すごい

[@rabutlilriddle1904]

水野さんのゼロイチ並べが微妙に好評で、DB屋としてはもにょる。 これ、画期的なアイディアではなく、むしろ古いシステムを中心に チョコチョコ現れる設計で、「あー…、またお前か…」ってなるんですよね…。 で、その設計にアプリ側から見ると一定の妥当性があって、直してもらえないこともあり…。 まあ、これも妥協の芸術なのですかね…。

[@HitYoutube]

CPUのFLAGみたいなもので分岐する感じですし コンピュータの能力が低かった時代には便利だったんですよね インデックスレジスタに入れれば命令で256分岐が出来たりしたので。

[@user-ie5nq4he8z]

Nortionのrelation とlinkedview を今回取り上げた分かりにくい表を元にして解説希望

[@oyasai350]

水野式みたいに管理番号を桁数ごとに意味を持たせて採番する方法も使ってます。ケースによると思いますが、間違いではないと思います😃　notionめちゃくちゃ活用しています。

[@harudoki7665]

番外編でいいので、ド文系に向けてnotionの使い方教えてください。読書メモのテンプレも配布してくれると嬉しいです。

[@ryoryo9384]

何故アクセスはエクセル程の市民権を得ていないのだろうか… 同じMicrosoftのツールなのに

[@user-jo5go4qc2k]

NoSQLのNoは否定のNoではなくNot OnlyのNoです

[@184a-xx8km]

それはバクロニムですね。

[@ozuretim]

今はね．

[@kotokoto8362]

Notion, 数式書くとき別窓ではなく書いた場所に表示できるのがよいです（そういうエディタ少ない） 特にノートパソコンのような小さな画面で作業するときに👍 ショートカットも充実してて、数式と言葉が多く交じる文章を書くには最適

[@user-etopen]

加藤あいと阿藤快くらい違うよ！ってくりぃむしちゅー上田のツッコミをこんなにナチュラルに使ってるの気持ちいい笑

[@Dec25Oct31]

単語IDは自然数列と対応させ、性質IDは2の累乗の数列と対応させておいて、まっすぐ並べた後、単語ID n が持つすべての性質IDの総和 S をn番目がSであるような数列として書いておく。 というような、ただ三つの列をまっすぐ並べるメモがスマホの中にあったんですが、後から見て発狂した覚えがあります。 できるだけなんでも少ない文字数で表現したいもんで、思いついたときは、天才だと思ったんですが、計算も参照も面倒すぎましたね。 小数で管理するという水野さんの案は、これと同じ（これの場合は二進数として上の桁を追加していっていますが）ように思えました。

[@yoshi4401]

8:30 このあたりの分類はBackRoomsのサブレベルみたいでいいですね。

[@hipopo_tamagawa]

タグというと Postgres の配列型が浮かんだけど Notion はどういう型で管理されているんだろう

[@nerotas4299]

Notion、使い始めました。

[@wb5266]

堀元さんのおかげで初めてnotionを活用して使えました＾＾♪ データ管理に活かします！

[@Yuto-el7dz]

分野が少し違うけどDWHのトークもしてほしい。データ分析基盤のデータモデリングも面白いトピックなので

[@user-mb6xs4zu6i]

実際のシステムの場合、マシンパワーが追い付かなかった場合は、利用方法に合わせて非正規化という手順が入る場合があります。 ただ非正規化を行うと、データの関係性として二重管理することになるので、関係性に矛盾が生じる危険性が出てきます。 なので、このセルが変更されたらこちらのセルも自動的に変更するといったプログラムを別に作って、矛盾が生じないようカバーしたりします。

[@paaaaaaanda]

アフターストーリーきになる！

[@user-cu3wx3qm4v]

7:30 情報系なら小数点以下でなくて　ビットで立てるところかな？

[@aods1004]

小数点以下つかって拡張性を確保するやつ、 RDBでツリー構造表現するときの入れ子集合モデルがそんな感じだったのを 思い出した！

[@Fnak202]

コンピュータで扱う浮動小数は、数量的限界（表現可能な範囲）と丸め誤差があるので、ラベル代わりに使うとプログラマーさん達からめっちゃ怒られそう。

[@mentosukoala]

9:10 算術符号のアイディアに近いものがありますね。

[@user-kl7hd2vv3e]

notionは入力の段階で重複があるかを自動チェックする機能は欲しいな

[@user-iu5yw1qk1l]

元の表がそこまで複雑じゃなくてまとめて書いちゃっても一覧できちゃうから正規化しすぎると「余計見づらくなった」に感じちゃうんだよね。カラムが大量にあって、かつその全部を同時に利用したいわけじゃない場合とかは正規化するとわかりやすくなったと感じると思う。

[@malerena9133]

学問としては完璧なデータベースを定義できない限り、データベース処理のアルゴリズムの改良ができないと思うんですよ。 なので、実際に使われるデータベースで十分というのはなかなか企業的だなあと思いました

[@renk1310]

水野さんの少数を使うアイデア、最初は画期的かもって思ったけど、よく考えたら1つのセルに情報が複数入ることになるので非正規リレーションなのでは？

[@bambooooooooooooooooo]

計算機科学と計算機（実物）と計算機の実務は全部違うんですね…

[@user-wu1yj3jb1s]

水野さんのこねくり回す 新人vtuberの名前みたいなイントネーションだ

[@tktk5656]

7:36 同じ手法ならビットフラグで実現することが多いかもね。 ただまぁデータベースだとビットフラグにindexは効かねーだろうから後で堀元さんが仰る外出ししますかねー。

[@tmtk5433]

水野さんが言ってた特製の持ち方はbitでデータを持たせるのに近しいイメージかな？

[@erde73]

26:53 NoSQL、Not(non)SQLじゃなくて Not only SQLだよな...？と思って調べたら、元はnon SQLだったらしく学びになった

[@ha9ha989]

水野さんのフラグ形式、良いですね。 堀本さん形式だと「単語」をキーにして、性質は 「単語ー性質」を外に作る 水野さん形式だと「性質を示すフラグ」をキーにして「フラグ－性質」の表を外に作る ただ、フラグがどんどん増えていくと DB の容量が 項目数×フラグのビット数 で増えてしまうのでちょっと残念。 あと、ジョーシンは阪神が優勝すると株価が上がります。

[@tambaren]

水野さんのアイデアはビットで表現してるのと同じ→ビットで表現してるの性質の列を増やしてるのと同じ ですね

[@user-ie5nq4he8z]

リレーションは次回ですか?

[@trip-person-of-village0301UA]

水野さん、細かく聞くのは「利益の圧縮」になるのは短期的には見られますが、それを「親切だからまた行こう」と捉えさせることができれば長期的に売り上げを保証することとなるためプランニング、ブランディングとして「親切にする」は理にかなっているのです。 それによりフローチャートが多くなり複雑化することで我々従業員のメモリ消費が激しいわけですが、、、 このように古典的な習慣でさえも説明を付ければ納得できてしまうので恐ろしいですよね。正直親切にされなくてもこちらからお願いするので、私は従業員の態度の前に顧客としてのリテラシーとモラルをあげることが大切であると考えます。従業員の皆様、いつもお疲れ様です。そしていつもありがとうございます。

[@tatara_gasa]

自分でDB扱うようになると、「列」は自動で増やせないけど「行」は自動で増やせるから、たとえばユーザーが購入したものだとかフォローしてるものだとかを参照するときに、別の表をつくってそこに紐付けるってやる方がいいんよな。結構直感にはんする部分。