Розмір відео: 1280 X 720853 X 480640 X 360
Показувати елементи керування програвачем
Автоматичне відтворення
Автоповтор
初めまして！今転職を考えていて、ノーコードに興味を持ったのでこの1~3を見て勉強させてもらってます！EXCELに通ずる知識があったりするので楽しませてもらってます！
感想・質問・リクエストなどお気軽にコメントください😀「共有」ボタンから、同僚やSNSへのシェアもお願いします👍
素晴らしい動画をありがとうございます！来年度春からSE・プログラマーとして就職予定です。基本情報や応用情報といった資格試験の勉強はしていました（しています）が、実務と資格試験は別物だと思っており「実際の実務ではどのようにやっていくのか」を知りたくてこの動画シリーズにたどり着きました。非常に参考になる動画をありがとうございます！パート４以降の動画も見させていただきます。
いい動画ですねえ、、ありがとうございます！
めちゃくちゃわかりやすい。ありがとうございます！
具体例が実際の業務でもありそうで、すごくわかりやすかったです(^^♪ありがとうございます！！
12:00~この時点でpurchase_detail_historiesテーブルに、購入したitemの個数のカラムは設定する必要はありますか？「ユーザーa」が「100円の商品A」と「200円の商品B」を500円で買ったとしたら、それぞれの個数って分かりますか？簡易的な図だから詳細に設定していないだけなのか、気になります。また、itemsテーブルの「purchase_detail_histories_idカラム」は必要なのですか？
はじめまして、初めてコメントします。ポートフォリオ を開発するにあたり、せお丸様の動画を何度も見させて頂きました。ありがとうございます。参考文献として、こちらのURLをシェアさせて頂きますこと連絡いたします。
シェア大歓迎です！コメントありがとうございます😊
いつも大変分かりやすい解説ありがとうございます！一点気になりました🤔itemsには複数の購入履歴に含まれる可能性があるので、itemsとpurchase_detail_historiesは1:nの関係ではないですかね？そしてitem_idカラムは外部キーになりそうですがどうでしょう？
コメントありがとうございます😀itemsとpurchase_detail_historiesは1:nではなく、1:1になります。なぜかというと、>itemsには複数の購入履歴に含まれる可能性があるこの場合は、purchase_detail_historiesに複数itemを持たせるのではなく、purchase_detail_historiesが複数レコードになるからです。purchase_detail_historiesは正規化されたテーブルなので、あくまでitem_idを1つしか持たない設計になっています
はい、purchase_detail_histories.item_idは外部キーになります👍
@@seomaru ご回答いただきありがとうございます。purchase_detail_historiesとitemsの関係についてもう少し自分で考えてみます！
@@seomaru横からすみません。何度か読み直してみたのですが腹落ちせずのため質問させてください。＞purchase_detail_historiesが複数レコードになるからです。こちらは複数アイテムの購入履歴が1レコードで表現されるのではなく、1アイテムごとに購入履歴レコードが作成されるということだと理解しました。ですが上記はitemsとpurchase_detail_historiesの関係がN:Nではなく1:Nになる、という説明に思えます。items.idが1である購入履歴レコードは複数存在し得ませんでしょうか？理解が足りず申し訳ありませんがご回答いただけると幸いです。
@@taka-lq7ye 多分ですが、Itemsの行が物理的な1商品ではなく、商品の種類を示すので1対Nという説明になっているのだと思います。stock列があるのがその根拠です。
何のカテゴリーが何のカテゴリーと何対何の関係になるのか慣れないと判断つかなそうですね。
正規化に慣れてくると判断つくようになってきます👍ua-cam.com/video/WEmY9s0Ky88/v-deo.html
laravelでポリモーフィックリレーションというデータベースの考えがあるのですがこれはなんですか？
ポリモーフィックは、一つの関連付けで複数のタイプのモデルに所属できる関連付けになりますreadouble.com/laravel/5.8/ja/eloquent-relationships.html#one-to-one-polymorphic-relations
ＤＢ設計を仕事にしているものです。主キーのカラム名が全て id というのは、何かの制約でしょうか。一般的には shop_id といった名称にすると思うのですが。
私も仕事でDB設計をすることが多いのですが、RubyonRailsなど最近のフレームワークでは制約的にプライマリキーがidとなり、shop_idなどは、外部キーとして使う、という制約があります。ただし、データベース的にはどちらを主キーとして使っても問題ないと思います。(単に宗教的な話だと思います＾＾；)
接頭辞は賛否両論ありますよね。僕はつけるほうが好きです（長くなるけど）
VARCHARの桁数を2の累乗数で付けるべき理由はどうしてなんでしょうか、、？
日本語はマルチバイトだからではないでしょうか。
こんにちは！いつも動画拝見させていただいてます。質問重複かもですが確認させてください。もともとitemとpurchase_historiesはn対nの関係にあって、その中間テーブルとしてpurchase_detail_historiesができたと理解したのですがこの理解は間違ってますでしょうか？もしこれが正しければ、itemsとpurchase_detail_historiesは1対nの関係であると思うのですが、どうでしょうか。。。過去動画で似た状況を扱ってらして気になってしまいました。ua-cam.com/video/T6g-DLWHscw/v-deo.html
初めまして！
今転職を考えていて、ノーコードに興味を持ったのでこの1~3を見て勉強させてもらってます！
EXCELに通ずる知識があったりするので楽しませてもらってます！
感想・質問・リクエストなどお気軽にコメントください😀
「共有」ボタンから、同僚やSNSへのシェアもお願いします👍
素晴らしい動画をありがとうございます！
来年度春からSE・プログラマーとして就職予定です。
基本情報や応用情報といった資格試験の勉強はしていました（しています）が、実務と資格試験は別物だと思っており「実際の実務ではどのようにやっていくのか」を知りたくてこの動画シリーズにたどり着きました。
非常に参考になる動画をありがとうございます！
パート４以降の動画も見させていただきます。
いい動画ですねえ、、
ありがとうございます！
めちゃくちゃわかりやすい。ありがとうございます！
具体例が実際の業務でもありそうで、すごくわかりやすかったです(^^♪
ありがとうございます！！
12:00~
この時点でpurchase_detail_historiesテーブルに、購入したitemの個数のカラムは設定する必要はありますか？
「ユーザーa」が「100円の商品A」と「200円の商品B」を500円で買ったとしたら、それぞれの個数って分かりますか？
簡易的な図だから詳細に設定していないだけなのか、気になります。
また、itemsテーブルの「purchase_detail_histories_idカラム」は必要なのですか？
はじめまして、初めてコメントします。ポートフォリオ を開発するにあたり、せお丸様の動画を何度も見させて頂きました。ありがとうございます。参考文献として、こちらのURLをシェアさせて頂きますこと連絡いたします。
シェア大歓迎です！コメントありがとうございます😊
いつも大変分かりやすい解説ありがとうございます！一点気になりました🤔
itemsには複数の購入履歴に含まれる可能性があるので、itemsとpurchase_detail_historiesは1:nの関係ではないですかね？そしてitem_idカラムは外部キーになりそうですがどうでしょう？
コメントありがとうございます😀
itemsとpurchase_detail_historiesは1:nではなく、
1:1になります。
なぜかというと、
>itemsには複数の購入履歴に含まれる可能性がある
この場合は、
purchase_detail_historiesに複数itemを持たせるのではなく、
purchase_detail_historiesが複数レコードになるからです。
purchase_detail_historiesは正規化されたテーブルなので、あくまでitem_idを1つしか持たない設計になっています
はい、
purchase_detail_histories.item_idは外部キーになります👍
@@seomaru ご回答いただきありがとうございます。purchase_detail_historiesとitemsの関係についてもう少し自分で考えてみます！
@@seomaru
横からすみません。
何度か読み直してみたのですが腹落ちせずのため質問させてください。
＞purchase_detail_historiesが複数レコードになるからです。
こちらは複数アイテムの購入履歴が1レコードで表現されるのではなく、1アイテムごとに購入履歴レコードが作成されるということだと理解しました。
ですが上記はitemsとpurchase_detail_historiesの関係がN:Nではなく1:Nになる、という説明に思えます。
items.idが1である購入履歴レコードは複数存在し得ませんでしょうか？
理解が足りず申し訳ありませんがご回答いただけると幸いです。
@@taka-lq7ye
多分ですが、Itemsの行が物理的な1商品ではなく、商品の種類を示すので1対Nという説明になっているのだと思います。stock列があるのがその根拠です。
何のカテゴリーが何のカテゴリーと何対何の関係になるのか慣れないと判断つかなそうですね。
正規化に慣れてくると判断つくようになってきます👍
ua-cam.com/video/WEmY9s0Ky88/v-deo.html
laravelでポリモーフィックリレーションというデータベースの考えがあるのですがこれはなんですか？
ポリモーフィックは、一つの関連付けで複数のタイプのモデルに所属できる関連付けになります
readouble.com/laravel/5.8/ja/eloquent-relationships.html#one-to-one-polymorphic-relations
ＤＢ設計を仕事にしているものです。
主キーのカラム名が全て id というのは、
何かの制約でしょうか。一般的には shop_id といった名称にすると思うのですが。
私も仕事でDB設計をすることが多いのですが、
RubyonRailsなど最近のフレームワークでは制約的にプライマリキーがidとなり、
shop_idなどは、外部キーとして使う、という制約があります。
ただし、データベース的にはどちらを主キーとして使っても問題ないと思います。
(単に宗教的な話だと思います＾＾；)
接頭辞は賛否両論ありますよね。
僕はつけるほうが好きです（長くなるけど）
VARCHARの桁数を2の累乗数で付けるべき理由はどうしてなんでしょうか、、？
日本語はマルチバイトだからではないでしょうか。
こんにちは！いつも動画拝見させていただいてます。質問重複かもですが確認させてください。
もともとitemとpurchase_historiesはn対nの関係にあって、その中間テーブルとしてpurchase_detail_historiesができたと理解したのですがこの理解は間違ってますでしょうか？
もしこれが正しければ、itemsとpurchase_detail_historiesは1対nの関係であると思うのですが、どうでしょうか。。。
過去動画で似た状況を扱ってらして気になってしまいました。ua-cam.com/video/T6g-DLWHscw/v-deo.html