のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,898人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【PHP】Laravel【フレームワーク】 Part.9

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    151 = :

    広い世界知ってるから「切り捨てた設計思想」って言ってんだろ
    LaravelはサクッとWebシステム作るためのツールだからな
    おぉまぁえぇはあぁほぉかぁ

    152 = :

    複合キー使いたかったらクエリビルダ使えばええだけやぞ
    laravelで複合キー使えないとか雑魚の戯言

    153 = :

    うちにも意識高くてスキル低い若手とかおるけど、そういうのに限ってフレームワークの設計思想無視して
    DDD!とかクリーンアーキテクチャ!とかやるよね

    それで案の定ひどいもの作ってプロジェクトやり直しになってたわ

    154 = :

    ただ複合キー使いたいだけなのに
    高度に抽象化されたORMの作法を捨てなければいけないとか、

    ポンコツですかwww

    155 = :

    >>154
    OSSなんだから気に入らなきゃ実装してプルリクでも出せばいい
    ばかなの?

    156 = :

    複合キーは使えるよ
    複合プライマリーキーがデフォルトではサポートしていないだけ
    Trait追加すりゃ別に複合プライマリーも出来るし
    そもそもサロゲートキーがデフォなのに複合プライマリーなんていらんのよw
    頭悪いからこの辺理解出来ない奴www
    オートインクリメントすら理解出来ないジジィの事だけどw

    158 = :

    >>154
    高度に抽象化されているから
    複雑性が増すわりに需要の低い複合キーを受け入れないって話だよ?
    一度issueで提案されたの蹴ってたぐらいだしバカには難しかったか?

    159 = :

    DB設計ガチ勢に聞きたいんだけど実際複合主キーになるようなテーブル設計はしないほうがいいの?

    160 = :

    >>159
    DBの設計としては普通にありえる
    抽象化するコストが高いだけ
    直接触るならサルでもつかえる

    161 = :

    >>159
    SQLをあまり書かない設計者は複合主キーを平気で勧めてくるけど
    実務だとバグの温床になるし業務要件の変更に振り回されやすいのでやめとけって話
    それだけのデメリットに見合うだけのメリットなんて無いし

    162 = :

    定期的に具体的な話が全くできない「Laravelは複合主キー使えない」
    って煽り散らかすだけの人が現れるから考えた事もなかったんだけど
    あんまりガチで考えたくないけど
    もしかしたらポリモーフィック関連のメソッド流用したら
    そんなに手間かからないで実装できんじゃね?
    って思うんだけどどうだろうか・・・

    163 = :

    DB板の連中に聞いたら「要件次第」で一刀両断される話だな

    164 = :

    >>157
    階層化したいって話だけなら
    パンくず系のライブラリでいいんじゃない?
    何のデータを階層化するのかわからんから何とも言えないわ

    165 = :

    > DBの設計としては普通にありえる
    > 「抽象化するコストが高い」だけ

    これが、Laravelerの能力の低さを物語っている…

    166 = :

    データが1:N:Nとか階層になっていて途中のデータで複合ユニークにする事は
    あるにしても複合プライマリーにする理由が全く無い
    Laravelだとサロゲートキーとしてidを使う事がデフォルトで
    親のサロゲートキーを子が持つ事で階層にするが
    サロゲートキーを使わないとそういう実装がそもそも複雑化するから
    基本的にはサロゲートキーでやった方が複雑なテーブルも対処出来る
    何でもナチュラルキーwとか逆に時代遅れやろ

    167 = :

    >>166

    親のキーが変わったら全部破綻するクソ設計乙

    168 = :

    >>167
    親のキーが変わることなど無いのだがw
    ナチュラルキーしか使えないバカが言いそうな言葉だw
    お前複合ユニーク大量のデータのツリーとか子もその複合ユニークと同じだけデータ持たせるの?www

    169 = :

    結局Laravelって個人が利用するようなシステム作るには便利だけど
    業務アプリ作るとなると全然ダメってことでOK?

    170 = :

    そんなもん作るやつの技量次第だろ
    訳の分からない煽り方して何て言って欲しいのよ?

    171 = :

    >>170
    自演楽しいかい?

    172 = :

    Laravel9の変更点まとめてくださっているぞ
    http://qiita.com/ucan-lab/items/7bde88a5d29a4e56085d

    173 = :

    そんなもん、投稿初日にみてるやろ

    174 = :

    いきなりPHP8必須かよ
    現時点で使える環境ほとんどないだろ

    176 = :

    バカLaravelerの子孫テーブルって、テーブル単体では機能しないクソテーブルなんだよなぁ…。

    178 = :

    >>174
    むしろ8.1も出てるから、そろそろ7とはお別れの時期やぞ

    182 = :

    複合主キー嫌いアルヨ

    184 = :

    Laravelが複合主キー対応していないってのは本当なの?
    マイグレーションファイルで複合主キーのテーブル作れるみたいだけど

    188 = :

    >>178
    まだ5のクライアントとか、こないだ頼まれて7にしたばかりの客とかいるわ

    195 = :

    laravelならすでにoptionalヘルパがあるからな
    まぁそれでもこっちのほうが使い勝手良いのは事実か


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について