DB設計を語るスレ 11

**NAME IS NULL** · 2021/08/28(土) 22:08:57.33

語れ

前スレ
DB設計を語るスレ 10
https://mevius.5ch.net/test/read.cgi/db/1495438711/

**NAME IS NULL** · 2023/05/26(金) 23:45:05.50

そこはまあ理解できる範囲だけどな

これから作るシステムの概念モデルと出来上がったシステムの概念モデルが同じになるかというと必ずしもそうじゃない
物理モデルを作る時に論理レベルでの修正が発生したら普通は論理モデルも修正するけど
同じことを概念モデルでもやるかといえばやらないことのほうが多いのが実情だから

**NAME IS NULL** · 2023/05/27(土) 08:46:56.22

概念データモデルまでさかのぼってメンテすることはないでしょ
後の工程で作成するデータモデルはよりシステムにあった内容に落とし込むものだし
なので少なくとも概念データモデルにあるのに論理・物理データモデルにその影すらないというのはありえない

**NAME IS NULL** · 2023/05/27(土) 10:21:15.93

それらのモデルを設計段階の違いとみなすか抽象度の違いとみなすか、それぞれ考え方が違うってことだろ。
概念モデルは単なるラフスケッチだとする流儀もあってもいいと思うがそれしかないってこともないと思う。

**NAME IS NULL** · 2023/05/27(土) 11:49:13.65

>>200
物理データモデルのテーブル定義、外部キーなどのリレーション、その他の制約まで論理データモデルどころか、概念データモデルに反映するから、設計の過程がなくなってタイトル違いのドキュメントを作るらしい。

概念データモデルでのエンティティ名と論理データモデルのエンティティ名は一致するものと一致しないものが混ざり、エンティティ定義は同じ、そのエンティティの属性名は同じなんだって。

**NAME IS NULL** · 2023/05/27(土) 12:29:41.12

それはそれはエキセントリックな方々をお仕事をされてて微笑ましい

**NAME IS NULL** · 2023/05/27(土) 13:03:46.27

>余談だけど「リレーション」の使い方がおかしいのはちゃんと学んだことがない証拠。

あぁ、これ。

**NAME IS NULL** · 2023/05/27(土) 13:54:54.25

>>206
そこは単に手抜きで書いただけ

**NAME IS NULL** · 2023/05/27(土) 16:32:11.30

シェルスクリプトのことをシェルと手抜きで書くみたいな？

いやいやいやｗ

**NAME IS NULL** · 2023/05/27(土) 16:33:45.47

さすがにシェルスクリプトのことをシェルとは言わない。

なんでみんなシェルスクリプトのことをシェル、シェルと言うのかわからないよな。

**NAME IS NULL** · 2023/05/27(土) 16:52:23.10

私はシェルになりたい

**NAME IS NULL** · 2023/05/27(土) 16:58:24.31

WindowsバッチファイルのことをDOSバッチと呼ぶ会社があるけど、なんでDOSなんだよと思っている。

**NAME IS NULL** · 2023/05/27(土) 17:06:31.24

wikipediaをwikiと略すようなものだな。
そういう略し方をしたらバカと思われることを知っている人は当然やらない。

**NAME IS NULL** · 2023/05/27(土) 17:13:01.14

一部の閉鎖的グループだとバカだとか言い出すのかな？

**NAME IS NULL** · 2023/05/27(土) 17:24:17.74

面前では言わんだろ。心の中で思うだけで。

**NAME IS NULL** · 2023/05/27(土) 17:29:59.92

私には、心の中の声が聞こえる！

**NAME IS NULL** · 2023/05/27(土) 17:42:28.43

>>215
気がふれた？

**NAME IS NULL** · 2023/05/27(土) 17:49:01.82

>>212
wikipediaはwikiの一種だから文脈によっては全く問題ない
リレーションシップとリレーションやシェルスクリプトとシェルは
関係はあっても包含関係にはない別のものだからJavaScriptのことをJavaと呼ぶレベルの誤用

とマジレスしてみたけどジョークだったかな？

**NAME IS NULL** · 2023/05/27(土) 18:20:16.24

頭の中ではわかってても書いたり口にしたりしたときに端折ってしまっていることはないこともない
ただそれを指摘されたら親しい間柄なら「ごめんごめんリレーションシップのことね」で済ませればいいと思うが
ここは隙あらば見たいな人が多いから注意しないとなｗ

**NAME IS NULL** · 2023/05/27(土) 18:31:27.06

そこは「ごめん、知らなかった。教えてくれてありがとう。」だろ？

**NAME IS NULL** · 2023/05/27(土) 18:36:45.84

本当、物知りだよねｗｗｗ

**NAME IS NULL** · 2023/05/27(土) 20:25:27.41

結構進んでるからDB設計の話ししてるかと思ったら・・・・

**NAME IS NULL** · 2023/06/07(水) 09:01:55.08

要件定義を突き詰めれば突き詰めるほど、ネットだけでは完結しないね
利用者の声はあまりネットで拾えないから、リアルの経験が必要になる

**NAME IS NULL** · 2023/06/07(水) 22:28:23.68

ネットサービスの要件定義の話ならスレ違いだと思うが

**NAME IS NULL** · 2023/06/08(木) 01:07:19.44

>>221
いちいち読んでないところから読み直すのかよw

**NAME IS NULL** · 2023/06/08(木) 07:48:06.88

お前ら批判ばかりだな

**NAME IS NULL** · 2023/06/19(月) 01:21:03.70

ものを教えるよりケチを付ける方が楽だし、楽しい

**NAME IS NULL** · 2023/06/19(月) 11:50:27.16

教えようよ。損するわけでもないんだし

**NAME IS NULL** · 2023/06/19(月) 20:32:11.12

俺は教えてるよ？聞け。

**NAME IS NULL** · 2023/06/21(水) 16:39:17.93

DB設計をAIに相談したら「要件次第」ってお前らみたいなこと言われるんだけど、
要件ってどこまで突き詰めればいいの？

たとえば、ユーザー数やアクセス頻度などを想定していたとしても
運用していくうちに当初の想定と異なるってケースはよくあるじゃん？
小規模だからテーブル数少なくしてたら、レコードが肥大化したり、
大規模だからテーブルを細かく分けたら、保守が大変になったり。

**NAME IS NULL** · 2023/06/21(水) 17:16:59.27

>>229
人間がわかりやすい単位でテーブルを作ればいい
テーブルが多いとたいへんという感覚がわからない。
データモデルが単にわかりにくいだけじゃないのか？

**NAME IS NULL** · 2023/06/21(水) 18:02:43.23

AIは人間から学習しててケースバイケースだと断って始まる記事がほとんどだからな

**NAME IS NULL** · 2023/06/21(水) 21:21:16.30

>>229
>たとえば、ユーザー数やアクセス頻度などを想定していたとしても

そういう性能要件は逆に設計初期段階では気にしすぎない方がいい。

**NAME IS NULL** · 2023/06/21(水) 22:09:02.77

>>232
じゃ、要件次第ってのは何を見ればいいの？

**NAME IS NULL** · 2023/06/21(水) 22:30:36.16

データベースに入れる必要があるデータにはどいういうものがあってそれらの意味や関係がどうなっているか。

**NAME IS NULL** · 2023/06/21(水) 22:31:23.73

>>229
>要件ってどこまで突き詰めればいいの？
要件がすべて出揃って固まってから初めてDB設計をしようとしちゃダメ
ハイレベルのDB設計は要件定義と同時並行で進めるものなので
DB設計上が要件をもっと突き詰めなければいけない状況が出てきたらその都度深めていく

小規模だからテーブル数を少なくとか大規模だからテーブルを細かく分けるというのは意味がわからない
設計時の想定と全く異なる状況になって設計が合わなくなったなら変更すればいいじゃん
最初から当然予測しておくべき変化だったのかどうかは設計力向上のためには重要なポイントにはなるけど

**NAME IS NULL** · 2023/06/21(水) 22:37:39.65

>>235
何かやりたいことができたとき、それをどう実現するか考えるだろ？
DB設計とプログラミングを同時に構想すると思うが、
見通しが立たないなら同時並行で進められないじゃん
設計後に「その要件無理だよ」ってなったらどうするのよ

**NAME IS NULL** · 2023/06/21(水) 22:41:14.85

>>236
DB設計とプログラミングを同時に構想？

設計後にってのはよくわからんが
設計中に要件が実現不可だって判明したなら
要件を変えるかプロジェクトを中止するしかないじゃん

**NAME IS NULL** · 2023/06/21(水) 22:52:23.43

じゃ、意味がないじゃん。考えるだけ無駄だじゃん

**NAME IS NULL** · 2023/06/22(木) 08:48:23.24

開発途中に仕様が変わるなんてことは普通にあるから最初から完璧なものを求めなくてもいいと思うけど
作るシステムがどんな運用をしたいかは最初の時点で分かるからそれをまとめるのが要件定義だし
そこから落とし込むのが設計では？
要件にないものを設計する必要はないんだから要件次第っていうのは当たり前だと思うが

**NAME IS NULL** · 2023/06/22(木) 10:38:13.59

要件定義って一口で言っても色々段階がある

**NAME IS NULL** · 2023/06/22(木) 11:14:08.29

>>239
今、1ヶ月ぐらい要件考えてから設計に落とし込めないってのを繰り返してるわ
単純なものなら考えなくても設計できるけど、単純なものは既製品にあるからな
金だしてコンサルに聞いても答えは見つからないし、ドツボにはまってる

**NAME IS NULL** · 2023/06/22(木) 11:33:49.31

要件から設計に落とし込めないってことはそもそも要件がおかしいからじゃね

**NAME IS NULL** · 2023/06/22(木) 13:15:47.45

いや、要件はおかしくないよ。実現してるサイトやアプリもあるし
それがどうやって作られてるのか設計が思い浮かばないんだよ

**NAME IS NULL** · 2023/06/22(木) 15:25:57.80

なんじゃそりゃｗ

**NAME IS NULL** · 2023/06/22(木) 15:41:03.76

じゃあ設計者が無能ってことだな
残念っ！

**NAME IS NULL** · 2023/06/22(木) 17:40:16.39

会員ランクまだ悩んでたのか

**NAME IS NULL** · 2023/06/22(木) 18:49:20.76

そもそも金出す所違うよな
コンサルなんかにはらうより設計してくれる技術者にだせよｗ

**NAME IS NULL** · 2023/06/22(木) 19:06:54.63

いやまあコンサルでも設計してくれるところはいくらでもあると思うが
普通のところなら思い浮かばないってことはないだそうな

**NAME IS NULL** · 2023/06/22(木) 23:15:47.96

俺もコンサル出せる予算もらえてるならコンサル料より安いこじんまりしてるけど経験豊富な小さい設計屋に投げるわ
そういう小さいとこだとガチガチの要件出さないでもヒアリングからよしなにしてくれるとこも多い
そのデザインを解析して良ければそのまま使って必要があれば手を加える
実例から学ぶのが1番早い

**NAME IS NULL** · 2023/06/22(木) 23:22:39.72

そりゃ安くてうまい信頼できる業者を知ってるんならそっちに頼むだろ。

**NAME IS NULL** · 2023/06/23(金) 00:48:38.59

実例じゃなくて実務から学ばないとダメなんだよ
といったところでたぶん違いがわからないんだろうが

**NAME IS NULL** · 2023/06/23(金) 00:51:47.95

>金だしてコンサルに聞いても答えは見つからないし
「(予算はないけどもし仮に)金だしてコンサルに聞いても(たぶん)答えは見つからない(だろう)し」
おい！

**NAME IS NULL** · 2023/06/23(金) 07:45:51.49

うちもとあるシステム開発の際にコンサルに依頼したことあるけど
システム構築にあたって
コンサルが最初から教えてくれたもの７
教えてくれたものをもとにさらにこちらから質問して回答を得たもの３
ぐらいで作ったな
相手によるんだろうけどコンサル側から最初から１０引き出すには相応の金が必要か相手との信頼関係が必要かもね
まあスレチでしたね

**NAME IS NULL** · 2023/06/23(金) 10:45:42.75

要件定義の中身や要件定義とDB設計の関係は
こういう要件定義系の書籍を読むととある程度イメージできると思う
https://www.ipa.go.jp/publish/tn20191220.html

がっつりウォーターフォールのフルスペックなやり方だから
そのままやる必要はないんだけどどういう項目が必要かは分かるはず

**NAME IS NULL** · 2023/06/23(金) 11:01:29.74

241だけどみんな誤解している
外部の意見を聞くために金だしてコンサルに聞いてるんだよ
第三者の声を聞かないと良い製品・サービスなんて作れないからな

で、設計者に金出せって言うけど、俺が開発するのに意味がないだろ
金が湯水のようにあるならとことん相談して、納得行く設計してくれるだろうが、
そうじゃないから自分で設計できなきゃいけない

**NAME IS NULL** · 2023/06/23(金) 12:37:42.60

だから無能な設計者（あなた）のかわりになる人間にも金を出せって話

**NAME IS NULL** · 2023/06/23(金) 13:02:20.01

>>255
>第三者の声を聞かないと良い製品・サービスなんて作れないからな
んなわけない
寧ろ逆でコンサル雇わないと良い製品・サービスを作れないと思ってる会社は良い製品・サービスを作れない

**NAME IS NULL** · 2023/06/23(金) 13:53:53.06

>>256
だから順番が逆だろ。お前らいつも「要件次第」って言ってるだろ
要件決まらないのに設計者に金出せないだろ

>>257
もちろんコンサルに金出した上で語ってるんだよな？
他人の意見を叩くためだけに「こうしろ」って言ってるんじゃないよな？

**NAME IS NULL** · 2023/06/23(金) 14:11:50.07

ごめん、無能な設計者は認めるわ。有能な設計者に出せる金が無いのも認めます

**NAME IS NULL** · 2023/06/23(金) 18:31:19.53

＞今、1ヶ月ぐらい要件考えてから設計に落とし込めないってのを繰り返してるわ
このレスはそもそも要件が決まらないのか要件は決まったけど設計ができないのかどっちなの？
まあどっちにしても決められないのはそいつが無能だからなわけだから
要件決められないならそんなシステム作るのはあきらめたほうがいいし、設計できないなら金出して設計できる人雇えばいい
その際に金をだせないならシステム作るのあきらめろ
それだけの話でこのスレでダラダラやる話じゃねーわｗ

**NAME IS NULL** · 2023/06/23(金) 21:18:24.60

>>255
もしかして、地道にユーザーにインタビューすれば要件が出てくる業務システムのようなものじゃなくて
エンドユーザー向けサービスの話だったりするのかな。

**NAME IS NULL** · 2023/06/23(金) 21:46:54.97

>>258
そもそも要件が設計に落とし込めないって話だったはずだが
つまり要件は決まってる前提の話だろ

**NAME IS NULL** · 2023/06/23(金) 23:32:49.14

設計をするのに十分と言える要件に落とし込めてるかどうか
それを判断できないということなんだろう

**NAME IS NULL** · 2023/06/24(土) 10:02:13.93

いつまでもうんうん悩んで書きかけの検討メモばっか量産してるんだろ
叩き台という言葉を知らんのか

**NAME IS NULL** · 2023/06/24(土) 10:16:41.32

ここは悩み事相談室

**NAME IS NULL** · 2023/06/24(土) 14:01:38.01

>>258
別に「こうしろ」とは言ってない
良い製品・サービスを作るのに第三者の声、特にコンサルが必要だと思ってるのが間違いだと言ってるだけ
コンサルを雇う側コンサルとして雇われる側どちらの経験もあるよ

**NAME IS NULL** · 2023/06/24(土) 14:36:37.56

コンサルは同業他社のものを押し付けてくるだけだしな

**NAME IS NULL** · 2023/06/24(土) 16:58:06.88

たとえばツリー構造の設計があるだろ？入れ子集合モデルみたいな。

親カテゴリ
└子カテゴリ
　└孫カテゴリ

要件（複数カテゴリ）はわかるけど、ツリー構造に落とし込めない場合
実現できない（設計できない）となるわけじゃん。

で、知識ある設計士に「複数カテゴリを実現するテーブル設計書を作って」
と依頼すれば作ってくれるだろうけど、概念を理解できないと開発ができない

こう説明すればわかってくれるか？
なお、「複数カテゴリが必要か否か」みたいな要件を、
その道に詳しいコンサルに相談したっていう意味な

**NAME IS NULL** · 2023/06/24(土) 17:46:31.09

>要件（複数カテゴリ）はわかるけど、ツリー構造に落とし込めない場合
>実現できない（設計できない）となるわけじゃん。

そのギャップが埋められない理由があよくわからんな。
要件定義でその「カテゴリ」というものがどう振舞わなければならないのか分析が足りてないんだと思うが
そこをコンサルがやってくれなかったってことなのかな。

**NAME IS NULL** · 2023/06/24(土) 18:05:31.47

それができないなら、まずその複数カテゴリがホントに入れ子のツリーなのか考えたほうが良いよ
やってることが逆で、設計（ツリー）に要件（複数カテゴリ）を当てはめようとするからできないんだよ

で、できる人に頼んだら出来上がった設計物の概念が理解できないってか？
それなら作成も金出して頼めよ
お前には無理ってやつだ

**NAME IS NULL** · 2023/06/24(土) 18:37:35.54

アイデアとられそうとかそういうのを回避したいのかもしれんが
自分がやってることを言えばいいものをたとえ話出すとかいみわからんわ

そもそも概念で設計者に作ってもらおうとするからできないんだろｗ
要件作れよｗ

ツリー構造の話で言えば一般的には
親キー、子キーの情報を持つテーブルと
それぞれのキーが持つ情報のテーブルだけじゃね

そもそも君には無理だと思うからあきらめたほうがいいんじゃない
要件定義時点ならまだ後戻りできるでしょ

**NAME IS NULL** · 2023/06/24(土) 18:45:23.72

あー、会員ランクの人か。まだやってたのかｗ

**NAME IS NULL** · 2023/06/24(土) 22:33:27.90

みんなの予想通り要件定義ができてなかったパターンだったね

**NAME IS NULL** · 2023/06/24(土) 22:41:00.87

カテゴリの構造はDB実装とは関係のないビジネス要件
ツリー構造だとしても使われ方によってRDBMSでもいろんな実装方法がある

**NAME IS NULL** · 2023/06/24(土) 23:32:20.22

>>274
実装がDB設計の事をいってるんだとしたら>>271書いたの俺なんだけど
自分も何個も設計したわけじゃないし設計した場合は99%これなんだけど
これ以外の設計ってどんな感じなのがあるのかね

ツリーとは少し違うんだけど
1階層目は固定で2-5階層（最大5階層まで）っていう制約があるものだけ
1-5階層の項目を持ったテーブル設計したぐらいだわ

**NAME IS NULL** · 2023/06/24(土) 23:44:20.68

>なお、「複数カテゴリが必要か否か」みたいな要件を、
>その道に詳しいコンサルに相談したっていう意味な

コンサルってECコンサルかよ
しかも必要か否かはコンサルが決めることじゃないだろｗ
DB設計以前に経験が無さ過ぎるみたいだから
どこかで丁稚奉公して出直すことをオススメする

**NAME IS NULL** · 2023/06/25(日) 00:52:13.32

>>275
一番よく使われてるのは隣接リストモデル(単に親IDもしくは子IDのカラムを付与して管理するやつ)
多対多が必要なら>>271のようにする(これはClosureテーブルというやり方)
他には>>268に書いてる入れ子集合モデルや経路列挙モデルなんかがある
SQL ServerのhierarchyidやPostgresのltreeが経路列挙モデルを簡単に扱えるようにしたもの

**NAME IS NULL** · 2023/06/25(日) 08:36:28.39

>>276
ECコンサルではない
たとえば弁護士ドットコムみたいなサイト作るのに
弁護士の人にお金出して教えてもらうって感じだ

ツリー構造は例で出したのに、相変わらずそこだけ切り取るのな
俺より論理的に考えられる設計士のはずなのに
こういうところでは短絡的なんですね

**NAME IS NULL** · 2023/06/25(日) 08:49:08.99

そもそもだけど、俺（241）は話の流れで「要件定義でこういう悩みがある」
って自分の経験を語ってるだけで、悩みを相談してるわけじゃないぞｗ
なぜか悩み相談者みたいな扱いうけてるけど

**NAME IS NULL** · 2023/06/25(日) 10:16:04.61

それはすまんな
ネタに飢えているだけだ

**NAME IS NULL** · 2023/06/25(日) 15:21:36.77

>要件（複数カテゴリ）はわかるけど、ツリー構造に落とし込めない場合
>実現できない（設計できない）となるわけじゃん。

これってもしかして
階層の深さを限定しないツリー構造が必要になる要件があった場合に
設計者がRDBでのツリー構造の実現方法(例えば入れ子集合モデル)を知識として持ってなければ
要件が明確でも設計に落とし込めないだろ、という例として書いてるのかな？

だとするともう少し日本語どうにかしないと伝わらないぞ

**NAME IS NULL** · 2023/06/25(日) 17:10:50.53

>>281
いや、日本語わからないのは都合の良い箇所を切り取ってるからだろ
端から「たとえば～」って書いてるのに
なぜかその部分だけ切り取って批判してるじゃん

**NAME IS NULL** · 2023/06/25(日) 18:04:01.15

そのたとえ話で主張したい点がどこなのかがよくわからないってことだと思うぞ。
俺>>281じゃなくて>>269だけどやっぱりよくわからん。
で>>281は単なる批判じゃなくて助け舟を出していると思うがそれも伝わらないのか。。。

**NAME IS NULL** · 2023/06/25(日) 19:07:22.45

設計自体が思い浮かばないって話は全く理解できないけど
知識不足が原因でキレイな設計や性能が十分出る設計に落とし込めないという話なら理解できる

そういうことが言いたかったんだろうということで好意的に解釈しとくわ

**NAME IS NULL** · 2023/07/06(木) 20:59:46.52

契約者、契約など、こんな入れ物の単位も思いつかない人間が多い。

**NAME IS NULL** · 2023/07/06(木) 21:01:04.67

Excelで資料を作らせると、シート間の関連すらわからないドキュメントを作る人間には、DB設計なんて無理です。

**NAME IS NULL** · 2023/07/08(土) 14:05:38.11

ポータルサイトによくある「検索条件を保存する」って機能。
検索フォームと同じだけのカラムを用意するんじゃなくて、
JSON型のカラムに詰め込むやり方でも問題ないよね？

**NAME IS NULL** · 2023/07/08(土) 17:53:16.96

問題ないかどうかはデータの使い道次第
まあ要件次第と同じだなｗ

**NAME IS NULL** · 2023/07/08(土) 18:51:20.51

あれほど要件定義をしろと言われたのに・・・

**NAME IS NULL** · 2023/07/08(土) 19:43:28.12

でもまぁここで考慮する必要があるのはそのフォーム定義情報の内部を検索に用いたり
部分的に更新したりする必要があるかどうかくらい。
それがなければjsonでまとめても問題ないんじゃね。

**NAME IS NULL** · 2023/07/08(土) 22:36:44.73

顧客のふわっとした要望からいきなり特定の実装方法に飛びつきすぎ

「問題ないよね？」なんて聞く前に
どういう選択肢があってそれぞれメリットデメリットは何かくらいは考えよう
その上で状況に一番適切と思われる選択肢を選ぶのが設計というもの

**NAME IS NULL** · 2023/07/10(月) 06:09:15.71

>>290
「検索条件を保存する」って要件にその懸念はおかしくね？
どういう想定したら、検索条件を再検索するんだ？
部分的に更新にしても、検索フォームに反映した後に再保存するだけでは？

なんか無理やり難癖つけて答える気がないようにしか見えない

**NAME IS NULL** · 2023/07/10(月) 07:51:03.23

>>292
>どういう想定したら、検索条件を再検索するんだ？
>部分的に更新にしても、検索フォームに反映した後に再保存するだけでは？

逆にあれだけの説明からそのへんの有り無しを断言しようもないと思うが。
俺からすると「なんでそこ勝手に決めつけちゃうの？」と思う。

>なんか無理やり難癖つけて答える気がないようにしか見えない

難癖に見えるかねぇ？
それに、その条件次第でjsonで問題ないとちゃんと回答してるんだが？

**NAME IS NULL** · 2023/07/10(月) 09:32:22.15

>>293
与えられた材料で検討するのが要件定義だろ
本人がそれ以上言ってこないんだから決めつけるしかない

「◯◯したいのですがどうすれば良いですか？」→Aにしろ
「いえ、Aだと無理です。××も必要になります」→Bにしろ

みたいなやりとりでいいんだよ。仕事じゃないんだから

**NAME IS NULL** · 2023/07/10(月) 09:33:50.08

条件次第とかふわっとしすぎなんだよ。優柔不断かよ
単なる便所の落書きで会社みたいな要求するなよ

**NAME IS NULL** · 2023/07/10(月) 10:47:09.23

読み手が内容を解釈できるレベルですらなければ何を言っても無駄だね
仕事ならすぐ違う人間に交代させられるんだけど

**NAME IS NULL** · 2023/07/10(月) 11:31:31.40

>>292
>どういう想定したら、検索条件を再検索するんだ？
ポータルサイトによくある「検索条件を保存する」って機能で保存された検索条件が検索されてないとでも思ってるの？
むしろどういう想定してるんだ？

>部分的に更新にしても、検索フォームに反映した後に再保存するだけでは？
インタラクティブに1件ずつ再保存する以外に更新されることが無いなら良いんじゃね？

例えば仕様変更によって保存された検索条件とフォームとの互換性がなくなる場合
データを更新しないならアプリ側に異なるバージョン間での互換性を保つ機能が必要になる
そのためには各バージョンのスキーマを定義して参照できるようにしておかないとすぐ破綻する
(一般的にシリアライズフォーマットのschema evolution対応と呼ばれる類のもの)

アプリ側で対応するのが面倒ならデータを更新するしかないが
DBMSが対応してる部分更新の範囲でなければ単純なSQLでは対応できないから
1件ずつデリシアライズして変更して再シリアライズする専用の更新プログラムを用意することになる

**NAME IS NULL** · 2023/07/10(月) 11:34:34.18

要はJSONを1つの文字列(もしくはバイナリ)データとして扱うのみで
DBレイヤーでは”将来を含めてJSONの中身を構造化データとしては一切扱わない”なら大きな問題ないということ
一部でも構造化データとして扱う必要があるならトレードオフの判断が必要

ユースケース(CRUD)とデータ(中身と構造)からそれを判断可能にするのが要件なんだが
「検索条件を保存する」というふわっとした要望ではその判断が不可能
だから要件と呼べるものではない

要件定義をしろって言われる理由が少しは分かってもらえるといいんだが

**NAME IS NULL** · 2023/07/10(月) 14:22:15.99

ポータルサイトによくある「検索条件を保存する」って機能。
検索フォームと同じだけのカラムを用意するんじゃなくて、
JSON型のカラムに詰め込むやり方でも問題ないよね？

[ChatGPT]
はい、JSON型のカラムに検索条件を詰め込む方法は、ポータルサイトでの検索条件保存機能として一般的な手法の一つです。この方法を使用することで、検索条件のデータを1つのフィールドにまとめて保存し、後で必要なときに取り出すことができます。

JSON型のカラムに検索条件を保存する場合、以下のような利点があります。

1. 柔軟性: JSON型のカラムは、異なる検索条件のセットを保存できます。たとえば、検索フォームに追加された新しいフィールドやオプションがあっても、データベーススキーマの変更が不要です。

2. シンプルさ: 検索条件を1つのフィールドにまとめることで、データベーステーブルの構造がシンプルになります。これにより、テーブルの設計やクエリの作成が容易になります。

3. 拡張性: JSON型のカラムは、必要に応じて追加の情報を含めることができます。たとえば、保存された検索条件にタイトルや作成者の情報を含めることもできます。

ただし、注意点もあります。

1. 検索条件の検索効率: JSON型のカラムに保存されたデータは、データベース内での検索やフィルタリングが難しくなる場合があります。特定の検索条件でデータを絞り込む必要がある場合は、適切なインデックスを作成するか、別途テーブルを使用して条件を保存する方法を検討することが重要です。

2. データの整合性: JSON型のカラムに保存されたデータは、データベースがその内容を理解することはありません。そのため、データの整合性やバリデーションを確保するための追加の処理や制約が必要になる場合があります。

以上が、JSON型のカラムに検索条件を保存する方法の一般的な考え方です。具体的な実装やデータベースの設計には、使用しているデータベースシステムやアプリケーションの要件に応じて適切な対策を行う必要があります。

**NAME IS NULL** · 2023/07/10(月) 14:23:12.68

ポータルサイトによくある「検索条件を保存する」って機能。
検索フォームと同じだけのカラムを用意するんじゃなくて、
JSON型のカラムに詰め込むやり方だと問題あるよね？

[ChatGPT]
JSON型のカラムに検索条件を保存する方法は、一般的には適切な方法ではありません。以下に、JSON型のカラムに検索条件を保存することに関連する問題点をいくつか挙げます。

1. 検索条件の構造変更の難しさ: JSON型のカラムに検索条件を保存すると、検索条件の変更や追加が困難になります。検索条件が単一のフィールドにまとめられるため、個々の条件を独立して変更することができません。検索条件の修正や特定の条件を削除する場合には、JSONを解析して変更する必要があります。

2. インデックスの効率性の低下: 検索クエリを実行する際に、JSON型のカラムに含まれるデータを解析する必要があります。データの解析は処理コストが高く、パフォーマンスに影響を与える可能性があります。一方、各検索条件を個別のカラムとして保持すれば、データベースのインデックスを最適に活用して高速な検索が可能になります。

3. クエリの複雑性と可読性の低下: JSON型のカラムに検索条件が格納されている場合、検索クエリの作成が複雑になります。クエリ内でJSONの操作や条件の解析を行う必要があり、可読性が低下します。また、JSON内に格納されたデータの形式によっては、検索条件の抽出や比較が困難になる場合があります。

以上の理由から、検索条件を保存する場合は、各検索条件を個別のカラムに分割して保存することをおすすめします。これにより、データの構造変更の柔軟性やクエリの効率性、可読性が向上し、より効果的な検索が可能になります。