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

  Рет қаралды 162,370

ゆるコンピュータ科学ラジオ

ゆるコンピュータ科学ラジオ

Күн бұрын

Пікірлер: 254
@yurucom
@yurucom Жыл бұрын
【Notionでデータベースを使いこなそう!】 ntn.so/yurucom 【参考文献】 ○データベースシステム(改訂2版) amzn.to/3qeyt3V 【サポーターコミュニティ加入はこちらから】 yurugengo.com/support 【おたよりフォーム】 forms.gle/BLEZpLcdEPmoZTH4A
@pistlove
@pistlove Жыл бұрын
この手の論争の原因は、ユーザは見た目の「プレゼンテーション層」と再利用のために「データ層」を同時に欲しがっているのが原因だと考えます。 解決方法としてはシートを二枚作り、裏のデータ層には正規化された表を作り、見たり印字するためのプレゼンテーション層としてのシートを表に出しておけばよいと考えます。
@hirobou3
@hirobou3 Жыл бұрын
ビットフィールド的な概念出せるのさすが水野さんという感じ
@ばりー-z5q
@ばりー-z5q Жыл бұрын
「一括置換する」とか「全部同じ修正をするのが大変」っていう語り口だと第5正規化の有用性はピンと来ないと思ってる。 「一部だけ修正することで不正な状態を保持できてしまう」っていうことが重要なのかなと思いました。
@kei5328
@kei5328 Жыл бұрын
水野さん、Bitmaskを自分で思いつくのか。素晴らしいな。
@nanoriKYDO
@nanoriKYDO Жыл бұрын
「キー」という言葉を使わずに説明していく姿勢に憧れを抱きました
@HijiriTachibana
@HijiriTachibana Жыл бұрын
わかる。初学者主キー・外部キー分からないがち。
@kamodomon0913
@kamodomon0913 Жыл бұрын
@@HijiriTachibanaキーと言われたらデータベースを触ってない人は家や車の鍵 を想像するし、そのキーを使って複数のデータベースにアクセスすると言われたら、色んな家を同じ鍵で開けて入るイメージになるので何が良いことなのかさっぱりわからなくなりますよねw 現在だと主キーに限って言えばマイナンバーと言えば通じるのかもしれませんね・・・と思ったけど、それが理解されていないからカードの中に預金情報や通院履歴などが入っていると勘違いしてる人が居るのか・・・。
@whzwiz
@whzwiz Жыл бұрын
水野さんの小数点以下アイデア、とても良いしchmodとかでもおなじようなことをしているものの、それ第1正規形を満たしていない
@carchess1896
@carchess1896 Жыл бұрын
Webプラットフォーム的なサービス開発をしてる身なので、割と第5正規形が必須だという派閥です。 SQLの実行速度の観点では、第五正規形の方が実行計画が上手く立つので処理は早い事が多い体感です。 SQL自体も、正規性が担保されていれば割と半自動レベルで作れるので楽です。 APIで返すにも分割単位がDBと一致するので管理が楽で再利用性も高く、めっちゃメリットだらけに感じています。 見づらい問題は、そもそも人が見るならviewで整形する前提なので確かに情報整理の観点では第三までで良さそうですが、システムDBで使うなら限界まで正規化した方がいいと思っています。
@knngayr
@knngayr Жыл бұрын
データベース回頭から見てもやっぱり水野さんの頭の回転の良さから出力される終わってるメモのギャップで笑っちゃう
@doridoriization
@doridoriization Жыл бұрын
生命、宇宙、そして「ゆるコンピュータ科学ラジオ」についての究極の疑問の答え → Divide and Conquer
@HighCaloLily
@HighCaloLily Жыл бұрын
良いねの数が42になっていて美しすぎるのでこれ以上誰も押せなくなってて笑う (押したい人は私のコメントに押してもいいですよ)
@akinaka7543
@akinaka7543 Жыл бұрын
@@HighCaloLily こんにちわ。ってなわけで押させていただきました。もう次はコメント数=42を目指すしか無いですねw
@aliliciganske337
@aliliciganske337 Жыл бұрын
「朝涼」鏑木清方が自分の娘を描いた日本画で、私の大好きな作品のタイトルになっています。番組内では文字でも声でも何度も登場し、こんなにも誰かが触れている様子を見てなんだか嬉しく思います。 蓮の花が綻ぶ道をそぞろ歩くうら若き乙女。まさに「朝涼」(夏の朝の涼しいころ)を表した爽やかな一枚です。
@kirinkame
@kirinkame Жыл бұрын
水野さんのアイディア、小数点じゃなくて固定長だけどうちのシステムで使ってたわ。 抽出する時煩雑になる仕組みで好きじゃなかったけど、あの短時間で自力で同じ考えに至るのスゴ!!
@kuppa222
@kuppa222 Жыл бұрын
これ〇〇回の後に基本情報の問題を水野さんに解かせて、 全て周り切ったあとにノー勉で水野さんに基本情報受けさせる企画やってほしい
@mudaso-heavy-user
@mudaso-heavy-user Жыл бұрын
アフターストーリー楽しみに待ってます
@yurucom
@yurucom Жыл бұрын
ありがとうございます!いつか世に出しますね!!!
@jajathree9506
@jajathree9506 Жыл бұрын
@@yurucom 半年後、1年後の水野さんの成長、待ってます。
@tsicsafjapan9371
@tsicsafjapan9371 Жыл бұрын
アフまち
@paaman815
@paaman815 Жыл бұрын
ビッグデータ扱うとかじゃない限り、今は第5正規形まで正規化したほうが早いパターンのが多いですね
@羽蛾-p4x
@羽蛾-p4x Жыл бұрын
このシリーズで1番ためになって面白かったのはコピミズム伝道協会
@masuo64
@masuo64 Жыл бұрын
※ただし信仰の対象はコピー&ペーストではなく著作物の違法コピー
@やまけん-x1n
@やまけん-x1n Жыл бұрын
水野さん正規形は、不動小数点数表現の誤差というか、解像度の限界で行き詰まりますね。 結局は一つの変数のビットフィールドを複数の項目でシェアしているだけなので、予めたくさんのカラムを用意しておくことと本質的に変わらないですね。
@ああ-o1g8h
@ああ-o1g8h Жыл бұрын
行き詰まんないと思うけど。 あと浮動ね。
@やまけん-x1n
@やまけん-x1n Жыл бұрын
@@ああ-o1g8h 浮動小数点は変換ミスです。大変失礼しました。 「行き詰る」について、前提としてデータベースがコンピューター上に実装されるとします。 コンピューターは2進数で数を扱うので10進数の小数を正確に表現できずに微小な誤差が出ます。 これを「丸め誤差」と呼びます。 属性が少ない場合は「微小な誤差は無視する」で通用しますが、属性が増えて桁が細かくなってくると「丸め誤差を無視できなくなるのでは?」という指摘です。 言語によっては10進数の小数を正確に表現できるような型もありますが、こちらも扱える桁数は有限なので、「無限に属性を追加できる」ものではないと補足します。
@やまけん-x1n
@やまけん-x1n Жыл бұрын
訂正ついでに、「ビットフィールド」という表現も間違ってましたね・・・ 「変数が64ビットなら表現できる数は2^64種類で、それ以上の状態の組み合わせを扱うことはできないのでは?」というのをうまいこと言えなかったっす・・・
@uminosachi
@uminosachi 3 ай бұрын
⁠@@やまけん-x1n水野さんは0,1と言っていますよ。最初から2進数でいいでしょう
@user-jo5go4qc2k
@user-jo5go4qc2k Жыл бұрын
7:08 複数の真偽値を一つのセルで管理する際、それぞれの真偽値を2進数羅列しその10進数の値を格納する、というやり方があります。 「知らなかった」だけなら01(2) = 1(10)、「語釈が面白い」だけなら10(2) = 2(10)、「知らなくて語釈が面白い」なら11(2) = 3(10)
@rabutlilriddle1904
@rabutlilriddle1904 Жыл бұрын
気持ちはすごくよくわかります。 分りますが、DB屋はこれをやられるとスン…って遠い目になってしまいます…。 おねがいなので、どうか、普通に正規化してください…。
@user-jo5go4qc2k
@user-jo5go4qc2k Жыл бұрын
@@rabutlilriddle1904 いかにしてデータサイズを節約するか…の思考で生まれたやり方っぽいですよね。 古のシステムでしかほぼ見ないです。
@bluegear8780
@bluegear8780 Жыл бұрын
古いシステムだとよくあるやつ
@EanaHufwe
@EanaHufwe Жыл бұрын
二進数フラグってCとかの言語で結構よく使う気がする、そしてデバッグする時に値を見て「なにこれ」になって、いちいち各けたの意味を調べなきゃとすごく面倒臭い
@Kureham
@Kureham Жыл бұрын
組込み屋さんには馴染み深いんだよなぁ
@yukonsw
@yukonsw Жыл бұрын
フラグ立てを独自開発(ただし車輪の再発明)した水野氏
@Ai-ttkw
@Ai-ttkw Жыл бұрын
Accessの設計を仕事でしているので、データの整合性とかリレーションとか、首がもげそうなほど頷きながら見てました。横に40項目有るデータを縦型に変更するためにunionクエリでSQL書いたり、一般人が作ったデータを正しく整えるのめっちゃ大変。
@pantrois
@pantrois Жыл бұрын
水野さんのような小数点のような発想は、カラムの追加などが容易ではない 昔のデータベースなどのときに使用されました 例えば図書館の本の属性を管理するのに ①図書館所蔵の本である ②閲覧に司書の許可がいる ③持ち出し禁止である という3種のフラグが必要な際に ①を1、②に2、③に4といった数字を振って たとえば図書館所蔵で持ち出し禁止の際には1+4=5を記録しておく これの利点は、更にフラグを増やす場合には8、16…と増やしていける点 欠点はめんどくさい ので、自由にカラムを追加できる現代では次第に使われなくなりました。
@garhyla
@garhyla Жыл бұрын
「JavaとJavaScriptは加藤あいと阿藤快ぐらい違う」はワロタ
@TM-yp2eo
@TM-yp2eo Жыл бұрын
使い古された表現なんだけどな…
@YS-sz7rm
@YS-sz7rm Жыл бұрын
くりぃむ上田ですね。 同系に「アン・ルイスと半ライスくらい違うよ!」があります。
@術中hack
@術中hack Жыл бұрын
メロンとメロンパンくらい違うって聞いたことがある
@remio39ryobb
@remio39ryobb Жыл бұрын
飛ばしてはくれてんのねぇ。
@masayokami
@masayokami Жыл бұрын
クリシェっちゃクリシェ
@クマノミ-f8y
@クマノミ-f8y Жыл бұрын
ビット桁で情報を持つ水野案はデータベースとしては0点だけどむしろアプリケーション側で権限とか情報の持たせ方を工夫するときにちょくちょく見かける気がする SUMしか使えない機械オンチなのにこれが思いつくあたりが流石のセンス
@anz2779
@anz2779 Жыл бұрын
この動画シリーズを観てNotion使い始めました。車の整備記録をエクセルに入力していたのですが、Notionに移行してから煩雑な入力が減りすこぶる快適です。 ただ、数値の単位が通貨しかないのがちょっと不満です。カスタムで任意の単位を追加できたらいいのにと思いました。
@arcsin1203
@arcsin1203 9 ай бұрын
水野式は素数の積でも同じ考えになりそうですね 「語釈が面白い」=2 「知らなかった」=3 「語釈が面白い」かつ「知らなかった」=6 結局タグ使った方がよい
@rachelhash1603
@rachelhash1603 Жыл бұрын
コピミズム伝道教会の存在を知り、前回このチャンネルのコメントで紹介した『コピペ害悪論』の教授はここと宗教的に対立しているというイメージがつきました。本当にありがとうございました。
@efo1187
@efo1187 Жыл бұрын
JSONは入れ子にするとセルの結合みたいな構造も許容されるから感覚的にわかりやすい感じします
@youyam8409
@youyam8409 11 ай бұрын
「百科事典棒」から発想した水野さんの小数点のアイデアを堀元さんが「お?」と反応するところが私的にハイライトでした。論文の引用もプログラミング的再利用ですね。
@百足兎
@百足兎 Жыл бұрын
7:11 性質の要素毎に桁を用意して、フラグを01としてuintとかに突っ込むヤツだ、と思ってコメント欄を見たらビットフィールドって名前があるんですね。勉強になりました。 それはそれとして本質的には性質の列を増やしているのと何も変わらない、むしろ扱いにくくなってるような
@cakirgokceyilmaz7743
@cakirgokceyilmaz7743 Жыл бұрын
以前,多すぎる選択肢に疲れて使うのやめてkeep使っているのですが、 とてもおもしろくてnotion猛烈に使ってみたい…となったので他に有能なテンプレートがあったら配布していただけるとめちゃくちゃうれしいです
@ツキ-o1k
@ツキ-o1k Жыл бұрын
18:50 「知的好奇心がドライブされて後世に任せる」ここの水野さんの言葉最高だな。。。
@tmtmtmx
@tmtmtmx Жыл бұрын
DjangoやRailsなんかのフレームワークだと全部自動で第五正規形になってる気がする! ただのデータとしてはそこまでする必要ないけど、例えば多言語対応等で後からテーブルを追加したり、複雑な操作が入ってくるのを考えると第五正規形最強なのでは?
@hyper264
@hyper264 Жыл бұрын
「人生は妥協」というのは、「なるほどなぁ」と思いました。 私自身、C言語を使用していますが、確かに同じ機能は関数化(一つの機能として独立)し、他の処理でも使えるようにしています。 ただし、その関数に変更を加えると、その関数を参照している処理すべてに影響がでてしまいます。 なので、影響範囲次第では「変更」か「新規」かを使い分けてますね。
@mudaso-heavy-user
@mudaso-heavy-user Жыл бұрын
楽しみに待ってました
@tsicsafjapan9371
@tsicsafjapan9371 Жыл бұрын
たのまち(5時間遅れ)
@yuragi1146
@yuragi1146 Жыл бұрын
売り上げ管理をnotionでしてますー。もちろん表計算もできるし、同じ数字で同じ品名ばっかりだから、テンプレ挿入でポンポン追加できるの楽だしミス少なくて便利! スマホからもPCからも使えるし。 ほかは、作業メモとかの箇条書き形式ばかりですが…、わざわざ多機能なnotionを使わなくてもいいんだけど、UIがいいしついついnotionを使っちゃうんですよねぇ。
@keagt0_e5
@keagt0_e5 4 ай бұрын
データベース的に良くなるほど人間が一目で理解しにくくなるって、最初に勉強したときも思ったの覚えてる
@哺乳類食肉目イヌ科
@哺乳類食肉目イヌ科 Жыл бұрын
文系の私としては、水野さんの小数点をつける方法は、論理哲学論考みたいな目次味を感じました笑
@yassu3015
@yassu3015 Жыл бұрын
野菜メモはその後どう管理することにしたのかも聞きたいですね!!
@munji_ccr
@munji_ccr Жыл бұрын
小数でフラグ管理するのおもろいですね。 新しい性質が増えた時に、過去に追加した項目もその性質を持っている、のような時に大変かもしれませんが……
@doyanizado
@doyanizado Жыл бұрын
使いやすい表の定義も、システムの規模や運用者の属性、テーブルの更新頻度や格納するデータの性質など様々な要素によって変わっていきますよね。 統計取ってどの要素が一番正規化への影響が強いか見たら面白そう
@dog--4773
@dog--4773 Жыл бұрын
人間にとって見やすいピボットテーブル的な表のデータをそのままBIツールにくわせても理想のグラフができないで困っている今の私にはめちゃくちゃためになりました。
@todays9890
@todays9890 Жыл бұрын
Notionはスペース押したときにAI機能が勝手に出るのを設定でOFFにできるようにしてほしいのと、バナーみたいに画像を押したらリンク先のページに飛べる機能を実装してほしい
@あいあい-n8e8h
@あいあい-n8e8h Жыл бұрын
3:17 {単語、性質}→{意味、備考}の関数従属性に対して、{単語}→{意味、備考}が成り立つから 第二正規形にもなってなさそうだけどどうなんだろ?
@nitorock2106
@nitorock2106 Жыл бұрын
敢えて二進数のON/OFFをアイデアとして思いつくってすごいなぁ。
@llil7934
@llil7934 Жыл бұрын
12:48  ネ 申 の 一 手
@hw6043
@hw6043 Жыл бұрын
アフターストーリー楽しみにしています。因みに、水野さんよりもっと使いこなしてなかった私がウェブサイト作れる事実を知って、課金ユーザーになりました。
@ofoneDyag
@ofoneDyag Жыл бұрын
水野さんの小数点の案は、2進数でやればプログラミングっぽくなるね。2進数の1桁目が1なら状態A、みたいな。
@jing7968
@jing7968 Жыл бұрын
自動でIDを振るのは賛否ありますね。正規具合は変わらず、入力に対しても挙動が一定じゃないので分散処理や複数環境に向かないため、振らなくても一意になるなら振らない方が良い場合も多いですね。
@軽井沢大吉
@軽井沢大吉 Жыл бұрын
「実践編」と第して、水野さんのデータベース関連のお悩み解決シリーズ見てみたいです!結構ネタありそうですね。
@ツノ-d9g
@ツノ-d9g Жыл бұрын
Notionこんなに便利だったんですね!(反響) 私はゲームエンジニアなんですが、このキャラがこのアイテムを持ってるなどの初期データをNotionで管理するのありかも…となりました
@ch-py7lw
@ch-py7lw Жыл бұрын
ずっと待ってた!
@user-etopen
@user-etopen Жыл бұрын
加藤あいと阿藤快くらい違うよ!ってくりぃむしちゅー上田のツッコミをこんなにナチュラルに使ってるの気持ちいい笑
@akinaka7543
@akinaka7543 Жыл бұрын
Ruby on Railsのhas many throughは、第5正規系なテーブル定義を作らせる方向にアプリ開発者(エンドユーザではなく)を誘導する仕掛け、ってことになるのかな。
@chranness
@chranness 9 ай бұрын
この動画で一番感心したのが 27:07 「JavaとJavaScriptは加藤あいと阿藤快ぐらい違う」でしたw
@RIAFeed
@RIAFeed Жыл бұрын
小数点は残念ながら一般的なDBでは正確には表現出来ないので数値をビットに見立ててやるのが確実かな
@ryoryo9384
@ryoryo9384 Жыл бұрын
何故アクセスはエクセル程の市民権を得ていないのだろうか… 同じMicrosoftのツールなのに
@akinaka7543
@akinaka7543 Жыл бұрын
14:50 IDが自動採番されてくれる仕組の話(人工キー)は、RDBの理論とはまた別の話なような気がするけど、まあ実用的には私もそういう説明が一番しっくりくるので賛成に一票。編集容易性も別話題だけど、もともとあの理論(だけ)だと編集などの運用容易性を考慮してない節が有って"刺さんない"んで
@jiramas
@jiramas Ай бұрын
性質ごとにTrue/Falseのブール値を与えれば「IDが1の単語は朝涼で、語釈が面白いという性質を持っている」の性質の部分を2次元に表現できそう
@済民かなえ
@済民かなえ Жыл бұрын
7:30 情報系なら小数点以下でなくて ビットで立てるところかな?
@yagi-r7m
@yagi-r7m Жыл бұрын
元の表がそこまで複雑じゃなくてまとめて書いちゃっても一覧できちゃうから正規化しすぎると「余計見づらくなった」に感じちゃうんだよね。カラムが大量にあって、かつその全部を同時に利用したいわけじゃない場合とかは正規化するとわかりやすくなったと感じると思う。
@harudoki7665
@harudoki7665 Жыл бұрын
番外編でいいので、ド文系に向けてnotionの使い方教えてください。読書メモのテンプレも配布してくれると嬉しいです。
@しししーしずーあか
@しししーしずーあか 2 ай бұрын
値が 重複してるのが いい表だと思います!! 内部データとかが独自の仕様で過剰に正規化されたの引き継ぐと保守も改造もマジ時間取られる 一種の暗号やろて思ってる
@しししーしずーあか
@しししーしずーあか 2 ай бұрын
おそらく メンバーのレベルが低ければ低いほど正規化でダメージ受ける
@trip-person-of-village0301UA
@trip-person-of-village0301UA 11 ай бұрын
水野さん、細かく聞くのは「利益の圧縮」になるのは短期的には見られますが、それを「親切だからまた行こう」と捉えさせることができれば長期的に売り上げを保証することとなるためプランニング、ブランディングとして「親切にする」は理にかなっているのです。 それによりフローチャートが多くなり複雑化することで我々従業員のメモリ消費が激しいわけですが、、、 このように古典的な習慣でさえも説明を付ければ納得できてしまうので恐ろしいですよね。正直親切にされなくてもこちらからお願いするので、私は従業員の態度の前に顧客としてのリテラシーとモラルをあげることが大切であると考えます。従業員の皆様、いつもお疲れ様です。そしていつもありがとうございます。
@kiyotan-l5q
@kiyotan-l5q 10 ай бұрын
これ聞いてマジでnotion使いたくなった! ISO9000のマネジメントにも使えるみたいです
@user-jo5go4qc2k
@user-jo5go4qc2k Жыл бұрын
NoSQLのNoは否定のNoではなくNot OnlyのNoです
@184a-xx8km
@184a-xx8km Жыл бұрын
それはバクロニムですね。
@ozuretim
@ozuretim Жыл бұрын
今はね.
@arigayas
@arigayas Жыл бұрын
水野さんにNotionの使い方を教える回をやったら面白そう。
@rabutlilriddle1904
@rabutlilriddle1904 Жыл бұрын
水野さんのゼロイチ並べが微妙に好評で、DB屋としてはもにょる。 これ、画期的なアイディアではなく、むしろ古いシステムを中心に チョコチョコ現れる設計で、「あー…、またお前か…」ってなるんですよね…。 で、その設計にアプリ側から見ると一定の妥当性があって、直してもらえないこともあり…。 まあ、これも妥協の芸術なのですかね…。
@HitYoutube
@HitYoutube Жыл бұрын
CPUのFLAGみたいなもので分岐する感じですし コンピュータの能力が低かった時代には便利だったんですよね インデックスレジスタに入れれば命令で256分岐が出来たりしたので。
@erde73
@erde73 Жыл бұрын
26:53 NoSQL、Not(non)SQLじゃなくて Not only SQLだよな...?と思って調べたら、元はnon SQLだったらしく学びになった
@よし44
@よし44 8 ай бұрын
8:30 このあたりの分類はBackRoomsのサブレベルみたいでいいですね。
@いくちゃん-y2z
@いくちゃん-y2z Жыл бұрын
実際のシステムの場合、マシンパワーが追い付かなかった場合は、利用方法に合わせて非正規化という手順が入る場合があります。 ただ非正規化を行うと、データの関係性として二重管理することになるので、関係性に矛盾が生じる危険性が出てきます。 なので、このセルが変更されたらこちらのセルも自動的に変更するといったプログラムを別に作って、矛盾が生じないようカバーしたりします。
@Yuto-el7dz
@Yuto-el7dz Жыл бұрын
分野が少し違うけどDWHのトークもしてほしい。データ分析基盤のデータモデリングも面白いトピックなので
@jyozu
@jyozu Жыл бұрын
ストレージを優先するか、処理速度を優先するかで使い分けますよね。 最近はコードファーストでDBがマイグレできる環境があるんで、 第一正規系になっていない表で列を後から増やす・減らすの手法もありなんじゃないかと思いました。 Notionのバックエンドエンジニアの募集要項はDB系だとこのへん(Memcached、Postgres、Elasticsearch)の知識があることってなってますね。
@tatara_gasa
@tatara_gasa 7 ай бұрын
自分でDB扱うようになると、「列」は自動で増やせないけど「行」は自動で増やせるから、たとえばユーザーが購入したものだとかフォローしてるものだとかを参照するときに、別の表をつくってそこに紐付けるってやる方がいいんよな。結構直感にはんする部分。
@paaaaaaanda
@paaaaaaanda Жыл бұрын
アフターストーリーきになる!
@mentosukoala
@mentosukoala Жыл бұрын
9:10 算術符号のアイディアに近いものがありますね。
@ksk448
@ksk448 5 ай бұрын
うわー。データベース勉強してたときにこの動画を見たかったなぁ
@naiwanaidaroG
@naiwanaidaroG Жыл бұрын
言語オタクがデータベースを駆使し自分だけの辞書を作る物語の始まり
@mxs105
@mxs105 Жыл бұрын
今回のサムネ頑張ってるなあ😂 中身もおもしろかったです
@Dec25Oct31
@Dec25Oct31 Жыл бұрын
単語IDは自然数列と対応させ、性質IDは2の累乗の数列と対応させておいて、まっすぐ並べた後、単語ID n が持つすべての性質IDの総和 S をn番目がSであるような数列として書いておく。 というような、ただ三つの列をまっすぐ並べるメモがスマホの中にあったんですが、後から見て発狂した覚えがあります。 できるだけなんでも少ない文字数で表現したいもんで、思いついたときは、天才だと思ったんですが、計算も参照も面倒すぎましたね。 小数で管理するという水野さんの案は、これと同じ(これの場合は二進数として上の桁を追加していっていますが)ように思えました。
@hykathon
@hykathon Жыл бұрын
8:46 水野さんのアイディア、情報の大きさという欠点があるので現在のコンピューターではなかなか実装されていませんね。 データベースではデータを探しやすいように、検索対象になりうるデータの(メモリ上の)サイズは予め決めておく事が一般的です。 なのでそこに0.1を書けるスペースを用意するのか、それとも0.1の10乗を書けるスペースを用意しておくのかというのは固定しておく必要があります。 途中で変更する場合は今までのデータすべての書き直しが必要ですね。 そこを除けば、予め桁数を決めておいてある桁が1の場合はこういう意味というのは皆さんコメントしていただいているようにデータ圧縮の良い技法で、自分で思いつけるのはすごく頭の良い人なんだろうなという気がします。
@amanohotori
@amanohotori 7 ай бұрын
21:42 ツッコミ入らないから言いますが、堀本氏の言う「パターナリズム」は "(国民や社員に対する)父親的態度,家父長主義" という意味しかなく、「サブウェイ行くたびに俺もっとパターナリズムで(注文を選んで)出してくれていいかもな」という発言の文脈に沿わないように感じられます。 これ、私の家族も同じ意味に間違えていて指摘したのですが、もしかすると「パターナリズム」を「パターン主義(パターンに基づき行う主義)」と誤解されているのかも知れません。特に文学的な婉曲表現でないのだとすれば。 「パターン主義(パターンに基づき行う主義)」という言葉を、ちょうど良い言葉に置き換えるなら、それは「マンネリズム(様式主義、パターンに基づき繰り返す主義)」であるとか、言う言葉にに置き換えるか、「パターンの通りに(注文を)出して欲しい」と、特別な言葉を使わないのが適当でしょう。 少なくとも「パターナリズム」の語は、極めて限定的な文脈で、限定的な意味でしか用いない語なので、恐らく堀本氏の「パターン主義」という意味でのこの用例は、日本でだけいくらか広がりが見られる(少なくとも私の家族と、堀本氏の2人により用いられることが観測された)誤用です。
@i8chang7
@i8chang7 4 ай бұрын
気になったワードをかるめにggりながら聞いてましたが、文脈に沿わない意味しか見つけられなくて一瞬 ❓🫠 となってました。 ありがとうございます。 堀本さんはきっと、パターン+ismって感じで、もしかしたら造語的に話してるけど、こういう響きのちがう言葉があってややこしいことになってたんだ〜💡
@rabutlilriddle1904
@rabutlilriddle1904 Жыл бұрын
3:19 普通に考えると、第二正規型の条件を満たしていない表にみえますが、 これを第三正規型と捉えているということは、意味や補足も行によって変わりうる と、考えているのでしょうか。 となると、この表は何のエンティティまたはリレーションを 表しますでしょうか(堀元さんの言い方では概念設計?) えーっと。すみません。 ゴチャゴチャいいましたが、これ、多分うっかりミスですよね…。
@おれの名は
@おれの名は Жыл бұрын
横槍ですが、 複数の意味を持つ単語が登録されていれば、性質を 2 行に分割したようにして意味も複数行に分かれるので、意味は行によって変わりますね   例:     パラダイム -> 科学理論の枠組み / 言語学での語形変化     トークン -> コンピュータセキュリティでのセキュリティトークン / 言語学での単語単位     ブラックボックス -> 科学技術での未解明な部分 / 航空機のデータ記録装置 同様に、複数の備考を持つ単語が登録されていれば補足も行によって変わります。   上で示した例の場合はどこの領域の用語なのかを備考に書けば複数の備考があると言えます     例:         ブラックボックス -> 未解明な部分 | 科学の用語         ブラックボックス -> データ記録装置 | 航空関連の用語 RDB の表を設計する時は表の一部 (動画で表示されている部分) だけではなく、表全体を見て (もっと言えば将来に渡って重複がないか概念設計で考えて) 設計するので、1:38 の表は第 3 正規形と読んでも良いでしょう
@rabutlilriddle1904
@rabutlilriddle1904 Жыл бұрын
はい。 ご提示いただいたとおり(また、私も最初に記載しているとおり) 行によって意味と補足の内容が変わるなら、 この表を第三正規型ととらえることはできます。 ただ、その場合問題になるのは、この表が何を示しているかです。 ご提示いただいた内容は、たとえば、同じ単語に対して辞書ごとの 意味、補足を保持することを想定されているかと思います。 (厳密には、これでも意味と補足の間に従属があるので✕ですが、置いておいて) とすると、この表が示すのは、辞書と性質に関連があるということです。 たとえば「知らなかった単語」という性質は、この辞書と関係がある (多分、その単語をその辞書で初めて知ったのでしょうね) とか、「語釈が面白い」という性質は、この辞書と関係がある (その辞書の語釈が面白かったのでしょうね)などです。 ただこれは「辞書」というエンティティを仮定しないと成立しませんし 元の表に辞書を示す列がないのも不自然です。 他に自然な解釈もなく、全体の話からみこのような設計を 意図しているわけではなさそうだったので まあ、単純ミスかなぁ、と思った次第です。
@あいあい-n8e8h
@あいあい-n8e8h Жыл бұрын
@@おれの名は すみません、さらに横槍で気になったので質問させてください その設計で行くと、 11:02 の左の表は結合従属性があるから第五正規形になってないですよね?
@rabutlilriddle1904
@rabutlilriddle1904 Жыл бұрын
​​@@あいあい-n8e8h 11:02 の左表が第五正規型かどうかは表の解釈に依存すると思います まず、前提として、単語・意味・備考のセットが主キー(候補キー)を成すことを仮定します。 このとき、 「この単語の意味」と「この単語に対する備考」という考え方でメモを取っており 「この単語のこの意味に対する備考」という考え方でメモを取っているのではない、 のであれば、意味・備考は単語に多値従属しますので、 第四正規型ではなく、したがって、第五正規型でもない、ということになるかと。 逆に「この単語のこの意味に対する備考」という考え方で取っているメモなら 第四正規型にはなりそうです。 で、単語・意味・備考の組み合わせなら、第四正規型になっていれば、 第五正規型にもなっていそうな気がします。 # 少なくとも私は、これらの組み合わせで第四正規型だが第五正規型ではない、 # という例を挙げることができないです。
@えいみー-x4s
@えいみー-x4s 6 ай бұрын
Notion, 使ってみます!🎉
@和歌山みかん-z7p
@和歌山みかん-z7p Жыл бұрын
既定値の概念を独自に考え出す水野さん すごい
@tktk5656
@tktk5656 Жыл бұрын
7:36 同じ手法ならビットフラグで実現することが多いかもね。 ただまぁデータベースだとビットフラグにindexは効かねーだろうから後で堀元さんが仰る外出ししますかねー。
@Fnak202
@Fnak202 Жыл бұрын
コンピュータで扱う浮動小数は、数量的限界(表現可能な範囲)と丸め誤差があるので、ラベル代わりに使うとプログラマーさん達からめっちゃ怒られそう。
@たまおたまさま
@たまおたまさま Жыл бұрын
知恵の深そうな話 楽しいですなあ
@yasayuyu6368
@yasayuyu6368 Жыл бұрын
分けた表をどう結合するかまで欲しかったかも😮
@天才の証明
@天才の証明 Жыл бұрын
確かに 初心者向けの説明としてはちょっと不十分かも
@shomwoys
@shomwoys Жыл бұрын
雰囲気的にゆるくわかったような気分になれば良いのです
@天才の証明
@天才の証明 Жыл бұрын
@@shomwoys 「た」の問題に比べれば、別にそこまで難しい話題でもないぞ 深い所までは突き詰めなければ良いだけだし、それでも十分実用的な内容だよ
@Chloe-1006
@Chloe-1006 Жыл бұрын
社内でNotionの使い方勉強会するために参考にさせてもらいました。もっとやってほしいです!
@Tomo_Kanada
@Tomo_Kanada Жыл бұрын
ノーションをスマホにダウンロードしました。 スマホをメモ帳として使えるようになって、重宝しています。
@Tomo_Kanada
@Tomo_Kanada Жыл бұрын
テンプレートって? なにそれ? おいしいもの?
@天才の証明
@天才の証明 Жыл бұрын
@@Tomo_Kanada notionには「テンプレート」と呼ばれる、様々な用途に応じたデータベースの雛形が保存されてます 例えば「営業日誌」だったり「タスク管理」等の雛形のドキュメントがあって わざわざ自分で一から考えて作る必要がないって感じですね(勿論自分好みに変える事も出来るし、テンプレートを自分で作る事も多分出来る)
@Tomo_Kanada
@Tomo_Kanada Жыл бұрын
​@@天才の証明様 御返信有り難うございます! そう言えば、かつて使っていたLotus123でもテンプレートと言っていたような気がしてきました、 ボチボチですが、少しでも皆さんに近づくように頑張ります。
@yuukostar3129
@yuukostar3129 Жыл бұрын
むっちゃ笑えました。 漫才とか見ているより楽しいかも。
@kotokoto8362
@kotokoto8362 Жыл бұрын
Notion, 数式書くとき別窓ではなく書いた場所に表示できるのがよいです(そういうエディタ少ない) 特にノートパソコンのような小さな画面で作業するときに👍 ショートカットも充実してて、数式と言葉が多く交じる文章を書くには最適
@WinLinux1028
@WinLinux1028 Жыл бұрын
正規化して整合性が取れるようにしつつ、パフォーマンスもある程度取れる方法としてマテリアライズドビューってのはあったりする
@bambooooooooooooooooo
@bambooooooooooooooooo Жыл бұрын
計算機科学と計算機(実物)と計算機の実務は全部違うんですね…
@天才の証明
@天才の証明 Жыл бұрын
notionは入力の段階で重複があるかを自動チェックする機能は欲しいな
@うしおとおら-o5u
@うしおとおら-o5u Жыл бұрын
Notionのデータベース機能初めて知りました。リレーショナルデータベースおじさんなので面白そうだなと思いました
@aods1004
@aods1004 Жыл бұрын
小数点以下つかって拡張性を確保するやつ、 RDBでツリー構造表現するときの入れ子集合モデルがそんな感じだったのを 思い出した!
@nerotas4299
@nerotas4299 Жыл бұрын
Notion、使い始めました。
@yas-156
@yas-156 10 ай бұрын
水野アイディアって、要はビットマップインデックスですね。
@舘津手斗
@舘津手斗 Жыл бұрын
データベース面白かったから非リレーショナルデータベース楽しみ
Каха и дочка
00:28
К-Media
Рет қаралды 3,4 МЛН
UFC 310 : Рахмонов VS Мачадо Гэрри
05:00
Setanta Sports UFC
Рет қаралды 1,2 МЛН
パスワード管理ムズすぎ。セキュリティの専門家が考える対策は?#116
41:09
ゆるコンピュータ科学ラジオ
Рет қаралды 137 М.
ド素人に「ターミナル」の必要性を熱弁する60分【黒画面に白文字のアレ】#137
1:02:12
詐欺的なサイトを鑑賞して楽しもう!!【インターネット地獄めぐり】#145
50:40
ゆるコンピュータ科学ラジオ
Рет қаралды 155 М.
機械オンチに「サーバー」を説明する動画#136
45:37
ゆるコンピュータ科学ラジオ
Рет қаралды 278 М.
小学生でもわかるデータベース設計入門。実際に設計しながら基礎を学ぼう
1:31:28
だれでもエンジニア / 山浦清透
Рет қаралды 136 М.
技術者に怒られないためのエクセル術。セルを結合するな。【データベース3】#89
26:49