プログラマの雑談部屋 ★376 (230ﾚｽ)
プログラマの雑談部屋 ★376 http://medaka.5ch.net/test/read.cgi/prog/1762945137/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
128: 仕様書無しさん [sage] 2025/11/15(土) 22:36:28.64 事業会社なんかはサービスの売り上げ、 （当然だけど）ビジネスありきであるわけだから、求められるのは巧遅よりも拙速であり、データは自然と継ぎ足しに コードはそうしたデータの尻拭い 結果としてのスパゲティ >>126 少なくとも上記のような環境でなけりゃデータの設計しっかりするでしょ http://medaka.5ch.net/test/read.cgi/prog/1762945137/128
129: 仕様書無しさん [sage] 2025/11/15(土) 22:39:03.74 ・時間によってバージョン切り替えするようなマスタをどうやって設計しますか？ 開始時間と終了時間の両方をカラム含めさせますか？ ビューを付けたほうがいいでしょうか？ ・リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？後々面倒はないでしょうか？ ・レコードの版をどうやって管理しますか？結合するときに面倒はないでしょうか？ ・論理削除使いますか？部分的に削除したのと、親ごと削除したのと区別が付きますか。削除した情報を見たいなんて要求があるとき、どうしますか？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/129
130: 仕様書無しさん [] 2025/11/15(土) 22:42:30.81 協力会社の技術力のあるエンジニアを信用して任せてたらその会社の他のプロジェクトが忙しくなってそちらに手を取られて、うちの仕事はそこの外注の初心者みたいなエンジニアに投げられてぐちゃぐちゃなコードを量産しまくられて挙句の果てに協力会社ごと逃げられたことがある。今でもその時のゴミコードでバグが発生してメンテする手間がかかっている。まぁその当時のうちの人間がすべてをレビューしてなかったのも問題だとは思うが（私はいなかったので知らん） http://medaka.5ch.net/test/read.cgi/prog/1762945137/130
131: 仕様書無しさん [sage] 2025/11/15(土) 22:43:40.69 今はAIが全てのベストプラクティスをご存知なのでまだいい 当時はひとつひとつが鬼門だった いや今でもサボったほうが楽なことが多くて後々地獄になる 簡単そうには見えるんだが 個々のSQLの膨らみ具合と こんなはずじゃない勢いのテーブル増加を見て怖気づく http://medaka.5ch.net/test/read.cgi/prog/1762945137/131
132: 仕様書無しさん [] 2025/11/15(土) 22:48:21.17 >>128 まさにその状態の真っ只中にいる。とにかく責任者が思いついたらその機能を2-3日みたいなスパンで投入しないといけないのでじっくり設計とかしている暇はない。いまこれリリースしたらトラブル可能性ありますよと言ってもとにかく機能が欲しい、トラブっても動かしながら直せばいいみたいな感じ まぁ結論としてはまともなエンジニアリングをしている会社で働こう！ということだなw http://medaka.5ch.net/test/read.cgi/prog/1762945137/132
133: 仕様書無しさん [sage] 2025/11/15(土) 22:51:46.60 うそです会社で設計したことない ジジイなので記憶が改竄されてた http://medaka.5ch.net/test/read.cgi/prog/1762945137/133
134: 仕様書無しさん [] 2025/11/15(土) 22:52:00.47 >>131 テーブルやSQLが複雑になってももう気にしなくてもよいのでは？自分で書く時代は終わってAIに任せておけば複雑なSQLも一瞬で仕上げてくれるんだし。必死で勉強して大量にSQL書いてきたけど、まったくもってAIの書くスピードとSQLの内容のスマートさにはかなわんわ http://medaka.5ch.net/test/read.cgi/prog/1762945137/134
135: 仕様書無しさん [sage] 2025/11/15(土) 22:54:25.35 ああそっか… 時代はかわったんだ… http://medaka.5ch.net/test/read.cgi/prog/1762945137/135
136: 仕様書無しさん [sage] 2025/11/15(土) 22:55:40.21 下剤効いて2kg出た http://medaka.5ch.net/test/read.cgi/prog/1762945137/136
137: 仕様書無しさん [sage] 2025/11/15(土) 22:57:31.70 なにもさせてもらえなかった 社会に影響を与えるチャンスは ことごとく足払いをかけられて潰されてきた http://medaka.5ch.net/test/read.cgi/prog/1762945137/137
138: 仕様書無しさん [sage] 2025/11/15(土) 22:58:56.11 >>132 まともなエンジニアリングしてる大手有名会社がそういう事してるからだよ MSとかAppleとかAWSとかGoogleとかMetaとかその他諸々 http://medaka.5ch.net/test/read.cgi/prog/1762945137/138
139: 仕様書無しさん [sage] 2025/11/15(土) 22:59:28.05 自分の状況は悪くはない 悪くはないが結局は社会に消されたんだ http://medaka.5ch.net/test/read.cgi/prog/1762945137/139
140: 仕様書無しさん [sage] 2025/11/15(土) 23:00:20.40 >>129 >時間によってバージョン切り替え バージョンによって、じゃなくてマスタ切り替えではなくて？ >開始時間と終了時間の両方をカラム 判然とせんけどたぶんイエス >ビューを付けたほうがいいでしょうか？ サービスによる >リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？ おつしるとおり軽々に取り入れるのではなく、運用上アンチパターン化することはないか設計時点で考えるべき >レコードの版をどうやって管理しますか？ バージョンカラム？ 危惧されている結合における面倒ごととは？ >論理削除使いますか？ >削除した情報を見たいなんて要求がある このユースケース、要望なら当然論理 物理、保持期間は要件次第 http://medaka.5ch.net/test/read.cgi/prog/1762945137/140
141: 仕様書無しさん [sage] 2025/11/15(土) 23:02:38.39 >>140 標準的な人間の回答をありがとう 見通しが立たなくてわからんから聞いてるんだが結局人間じゃこういう回答が返ってくるよな 当然だ AIなら http://medaka.5ch.net/test/read.cgi/prog/1762945137/141
142: 仕様書無しさん [sage] 2025/11/15(土) 23:33:11.05 テーブル数多くなってきたらGUIかORM使うのが普通になってくるってこと？ CLIとか素のSQL文の管理とかできる気がしないんだけど http://medaka.5ch.net/test/read.cgi/prog/1762945137/142
143: 仕様書無しさん [sage] 2025/11/15(土) 23:33:40.02 テーブル数多い時にね http://medaka.5ch.net/test/read.cgi/prog/1762945137/143
144: 仕様書無しさん [sage] 2025/11/15(土) 23:36:16.42 GUIかORMて http://medaka.5ch.net/test/read.cgi/prog/1762945137/144
145: 仕様書無しさん [sage] 2025/11/15(土) 23:38:29.74 納豆パン作ってみたらめちゃくちゃまずかった 大豆はまだ食えたんだが http://medaka.5ch.net/test/read.cgi/prog/1762945137/145
146: 仕様書無しさん [] 2025/11/15(土) 23:40:05.32 お前らみたいに有能なプログラマーになりたいのでご教授くださいやがれ http://medaka.5ch.net/test/read.cgi/prog/1762945137/146
147: 仕様書無しさん [] 2025/11/15(土) 23:40:23.36 ORMあっても簡単なER図書かない？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/147
148: 仕様書無しさん [] 2025/11/15(土) 23:46:30.49 うんこが便器から飛び出しているかテストするときに ・うんこが完全に便器の中にある ・うんこが半分飛び出している ・うんこが完全に飛び出している ・うんこが便器をまたいで飛び出している の境界テストをすればいいだけなのだが センスのない奴にテスト仕様を書かせると ・うんこがちょっとだけ飛び出している ・うんこがなんとなく飛び出している ・うんこがすごく飛び出している ・うんこが隣の便器に飛び出している などと、同じロジックを通るテストケースを大量に作り出す http://medaka.5ch.net/test/read.cgi/prog/1762945137/148
149: 仕様書無しさん [sage] 2025/11/15(土) 23:50:53.38 >>147 書かない つうか最近のDBツールだとER図みたいな画面持ってるやん なんで書くのよ http://medaka.5ch.net/test/read.cgi/prog/1762945137/149
150: 仕様書無しさん [] 2025/11/16(日) 00:00:10.69 >>149 設計段階でまずどんなん作るか決めなあかんやん そこもDBツールで書いちゃうの？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/150
151: 仕様書無しさん [sage] 2025/11/16(日) 00:01:08.24 テーブルは適度に非正規化しないとパフォーマンス落ちるやろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/151
152: 仕様書無しさん [sage] 2025/11/16(日) 00:05:21.69 長いけどチャッピーに聞いたらこう答えたんだけどどう思う？ ormを使わず生sqlだけでデータベース接続をする場合、どれくらいのテーブル数が適していますか ChatGPT: 結論から言うと 「生SQLだけで運用できるテーブル数には明確な上限はない」 ですが、 実務的には 50〜150 テーブルが限界ラインになり、200〜300 を超えると生SQLだけは非推奨 になります。 その理由と基準を詳しく説明します。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/152
153: 仕様書無しさん [sage] 2025/11/16(日) 00:05:49.15 ✅ 結論：生SQLだけでの運用に適したテーブル数の目安 ■ 〜50テーブル 生SQLだけで十分運用可能 構造も把握しやすい スキーマ変更時の影響範囲も小さい ■ 50〜150テーブル チームと設計次第では生SQLのみでも運用できる ただし クエリがスパゲッティ化し始めるゾーン 接続管理・トランザクション管理は手厚くする必要あり ■ 150〜300テーブル 生SQLだけだとかなりつらくなる スキーマ変更時のクエリ修正の影響範囲が爆発する どこで何のSQLが使われてるか管理しきれなくなる → ORMまたはQuery Builderを部分的に併用すべき ■ 300テーブル以上 生SQLだけはほぼ不可能 保守・修正コストが異常に高くなる 「どのSQLがどのテーブルに影響しているか」が分からなくなる → ORMまたは型付きRepository層が必須 http://medaka.5ch.net/test/read.cgi/prog/1762945137/153
154: 仕様書無しさん [sage] 2025/11/16(日) 00:06:20.23 🔥 生SQLだけで運用すると破綻する理由 1. スキーマ変更の影響範囲が手作業で対応しきれない 例：カラム名1つ変えるだけで数百ファイルに影響する可能性。 ORMならモデル1箇所を直せばよいが、生SQLでは全部探す必要がある。 2. SQLがどこで使われているかコード上から追えない 生SQLは散らばりやすい grep 検索では限界がある 依存関係管理ができない 3. 型・補完などIDEの恩恵が受けにくい コード補完が効かないため、ミスが多発する。 4. 複数人開発でバラバラのSQLが生まれる JOINの仕方が人によって違う N+1問題も起きやすい 共通化が難しい 5. テーブル数が増えるほどリファクタリング不能になる 300テーブルを生SQLで100%管理するのはほぼ無理。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/154
155: 仕様書無しさん [sage] 2025/11/16(日) 00:07:10.27 🔧 実務では何が起きるか？ 100テーブル → 「なんとかなる」 SQLが複雑になっても人間が把握できる 200テーブル → 「構造管理が苦しくなる」 影響範囲調査が辛い スキーマ変更のたびに改修数が膨れ上がる 300テーブル以上 → 「保守不能に近い」 統一ルールなしだと破滅 SQLの共通化や自動生成が必須レベル 🎯 最適解（生SQL中心で行きたい場合） 生SQLを使いたいなら、以下の組み合わせが最強です： RepositoryパターンでSQLを一箇所に集約 SQLテンプレートを作る（共通化） Query Builderを併用（完全ORMは使わない） 型定義（TypeScript・Pydanticなど）をDBと同期 これらを入れれば 150〜200テーブルでも生SQL中心で耐えられる。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/155
156: 仕様書無しさん [sage] 2025/11/16(日) 00:07:20.83 ✅ 最終結論 「生SQLだけ」でやりやすいテーブル数の目安は 〜100 150〜200でギリギリ、300以上は非推奨 ただし以下によって変わります： チーム全員がSQLに強いか？ スキーマ変更が頻繁か？ 分析系か、トランザクション系か？ Query Builder を併用するか？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/156
157: 仕様書無しさん [] 2025/11/16(日) 00:16:21.28 >>152 ～50テーブルでも可能なだけでおすすめしないところがSQLの限界を感じるな ORMは色んな理由で使用推奨やからそこは議論の余地はないと思ってる http://medaka.5ch.net/test/read.cgi/prog/1762945137/157
158: 仕様書無しさん [sage] 2025/11/16(日) 00:29:29.27 5000超えも普通にあるだろ 200くらいが丁度いい それって貴方の感想ですよね http://medaka.5ch.net/test/read.cgi/prog/1762945137/158
159: 仕様書無しさん [sage] 2025/11/16(日) 00:55:05.72 テーブル数が300を超えていたら その現場から逃げよう http://medaka.5ch.net/test/read.cgi/prog/1762945137/159
160: 仕様書無しさん [] 2025/11/16(日) 01:22:46.92 >>153 自分の使っているフレームワークだとEntityとペアになったRepositoryクラスにORMを使って絞り込みとかの機能を持たせたメソッドを書くのが基本になってるな http://medaka.5ch.net/test/read.cgi/prog/1762945137/160
161: 仕様書無しさん [] 2025/11/16(日) 01:26:04.73 >>154 ORM使っていても気をつけないとN+1問題は起きる。最近、人が書いたコードを修正したんだけど、参照しているエンティティを遅延ロードしていたおかげでクエリ数が爆発してた。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/161
162: 仕様書無しさん [sage] 2025/11/16(日) 01:26:07.52 機能境界とかでちゃんとDB分けたりネームスペース設定せい http://medaka.5ch.net/test/read.cgi/prog/1762945137/162
163: 仕様書無しさん [sage] 2025/11/16(日) 01:26:36.43 深夜の背徳トリプルチーズバーガー http://medaka.5ch.net/test/read.cgi/prog/1762945137/163
164: 仕様書無しさん [] 2025/11/16(日) 01:31:01.61 >>162 自分の使っているフレームワークとORMだと複数DBを使える可能性もあるようだけど、なんか面倒なことが起こりそうで誰も手を出さないわ。そもそも複雑に絡み合いすぎていて機能境界なんてないと思う http://medaka.5ch.net/test/read.cgi/prog/1762945137/164
165: 仕様書無しさん [] 2025/11/16(日) 01:33:44.88 マイクロサービス化は？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/165
166: 仕様書無しさん [sage] 2025/11/16(日) 03:21:10.50 MITからChatGPT活用頻度の高い人の脳活性が低いって研究が出た http://medaka.5ch.net/test/read.cgi/prog/1762945137/166
167: 仕様書無しさん [sage] 2025/11/16(日) 07:09:25.48 DB分けたので大失敗した http://medaka.5ch.net/test/read.cgi/prog/1762945137/167
168: 仕様書無しさん [sage] 2025/11/16(日) 08:15:36.48 あたまがぼんやりしてうごかない http://medaka.5ch.net/test/read.cgi/prog/1762945137/168
169: 仕様書無しさん [] 2025/11/16(日) 08:22:39.70 >>168 もう引退しなよ。周りに負担がかかりすぎてる http://medaka.5ch.net/test/read.cgi/prog/1762945137/169
170: 仕様書無しさん [sage] 2025/11/16(日) 08:29:51.77 彡 ⌒ ミ (´・ω・`) ぼんやり見えてこないか眺めてる http://medaka.5ch.net/test/read.cgi/prog/1762945137/170
171: 仕様書無しさん [] 2025/11/16(日) 08:33:42.05 本の誤記を連絡するページに飛んだらメールアドレス必須だったからやめた 誰も計算なんか真面目にやらないだろうからずーっと間違えたままなんだろうな http://medaka.5ch.net/test/read.cgi/prog/1762945137/171
172: 仕様書無しさん [sage] 2025/11/16(日) 08:38:00.20 捏造メアドでも届くは届くだろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/172
173: 仕様書無しさん [sage] 2025/11/16(日) 08:44:45.36 おっぱい http://medaka.5ch.net/test/read.cgi/prog/1762945137/173
174: 仕様書無しさん [sage] 2025/11/16(日) 08:57:47.94 本の誤記に気がつく者だけが真実に辿り着く もうそれでいいじゃないか 本を鵜呑みにして一生悩んでろだよ そもそも正誤表を調べようなんて人も一握りだし http://medaka.5ch.net/test/read.cgi/prog/1762945137/174
175: 仕様書無しさん [sage] 2025/11/16(日) 10:39:05.17 ねむたいから寝る 頭もぼけてるし もうしぬんじゃないかといつもおもう http://medaka.5ch.net/test/read.cgi/prog/1762945137/175
176: 仕様書無しさん [sage] 2025/11/16(日) 10:40:35.33 前頭葉にダメージを負った人間の行動がおれにそっくりだった http://medaka.5ch.net/test/read.cgi/prog/1762945137/176
177: 仕様書無しさん [sage] 2025/11/16(日) 11:14:10.60 顔認証のロック解除って、その人の実物大の顔写真があればできますか？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/177
178: 仕様書無しさん [sage] 2025/11/16(日) 11:53:53.83 そんなものなくてもAIで生成した画像があればできるよ http://medaka.5ch.net/test/read.cgi/prog/1762945137/178
179: 仕様書無しさん [sage] 2025/11/16(日) 12:01:44.76 お前らDBで例えばユーザ管理すりテーブル作るとするやん 社員番号なのか何なのか一意キーとして列作るなら id user_id どっち使う？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/179
180: 仕様書無しさん [sage] 2025/11/16(日) 12:04:29.92 user_id http://medaka.5ch.net/test/read.cgi/prog/1762945137/180
181: 仕様書無しさん [] 2025/11/16(日) 12:04:39.49 idはサロゲートキーにしか使ってねえや http://medaka.5ch.net/test/read.cgi/prog/1762945137/181
182: 仕様書無しさん [sage] 2025/11/16(日) 12:06:29.80 社員番号のような何かはuser_idに入れる。 idはレコードそのものユニークIDを入れる列名として定着してるから、そこに社員番号を入れるのはもはや嫌がらせに近い。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/182
183: 仕様書無しさん [sage] 2025/11/16(日) 12:08:28.96 userテーブルの主キーはidだろ テーブル名がuserだからuser_idは冗長だわ 外部キーとして使う時はuser_idだけど http://medaka.5ch.net/test/read.cgi/prog/1762945137/183
184: 仕様書無しさん [sage] 2025/11/16(日) 12:09:42.50 そんなことより、ユーザ管理すりテーブル が何なのか気になるわ http://medaka.5ch.net/test/read.cgi/prog/1762945137/184
185: 仕様書無しさん [sage] 2025/11/16(日) 12:10:11.32 やめておけ せめてスキーマ内では 同じカラムは同じものを表せるように調整しろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/185
186: 仕様書無しさん [sage] 2025/11/16(日) 12:10:28.23 同じカラム名 http://medaka.5ch.net/test/read.cgi/prog/1762945137/186
187: 仕様書無しさん [sage] 2025/11/16(日) 12:12:54.68 ねえ http://medaka.5ch.net/test/read.cgi/prog/1762945137/187
188: 仕様書無しさん [sage] 2025/11/16(日) 12:16:32.59 じゃあuserテーブルの属性に全部user_のプレフィックスつけるのかよ user_name user_gender user_email user_address user_rank http://medaka.5ch.net/test/read.cgi/prog/1762945137/188
189: 仕様書無しさん [sage] 2025/11/16(日) 12:17:03.89 なんでそう極端なんだよ http://medaka.5ch.net/test/read.cgi/prog/1762945137/189
190: 仕様書無しさん [sage] 2025/11/16(日) 12:20:43.96 db設計むずすぎ http://medaka.5ch.net/test/read.cgi/prog/1762945137/190
191: 仕様書無しさん [sage] 2025/11/16(日) 12:20:58.75 一貫性がある方がいい idにだけuser_ついてるとなんか気持ち悪い http://medaka.5ch.net/test/read.cgi/prog/1762945137/191
192: 仕様書無しさん [sage] 2025/11/16(日) 12:23:35.94 idにだけuserというか、idとuser_idが両方あるのが現代では普通だと思う なので選択肢がない http://medaka.5ch.net/test/read.cgi/prog/1762945137/192
193: 仕様書無しさん [sage] 2025/11/16(日) 12:25:04.46 日本語で整理した時どうしてた？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/193
194: 仕様書無しさん [] 2025/11/16(日) 12:32:49.84 Userテーブルのidなんだからuser.idだろ user_idは他テーブルの外部キーだろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/194
195: 仕様書無しさん [sage] 2025/11/16(日) 12:33:10.08 idは主キーとして使うと思うけど、これが例えば設計の過程で他に会員番号みたいなものがあってこれを主キーにできる場合はそれをコードでも想像しやすいuser_numberとか使うけど、これがドメインで使われる言葉じゃなくてシステムの都合で必要に迫られて生成した項目の場合はそのままidで使うかな http://medaka.5ch.net/test/read.cgi/prog/1762945137/195
196: 仕様書無しさん [] 2025/11/16(日) 12:46:51.30 >>192 だな。ORM使ってるとすべてのテーブルにidがあることが前提だからな もちろん別のカラム名をidの代わりに利用することも可能だけど面倒なだけなので普通はやらない ORM使わなくて自分でSQLがりがり書くなら好きなカラム名で良いが、いまどきみんなidがあること前提で読もうとするから不思議に思われるかもな いつからだろうな。俺はRailsからだけど http://medaka.5ch.net/test/read.cgi/prog/1762945137/196
197: 仕様書無しさん [] 2025/11/16(日) 12:48:43.99 >>196 使用するフレームワークのORMに従ったらそうなるだけだろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/197
198: 仕様書無しさん [sage] 2025/11/16(日) 12:49:24.64 じゃあ例えば受注と明細みたいなヘッダーディテール形式 明細レコードには受注IDが入る 受注テーブルの名前をOrderだとすると明細テーブルに入る受注IDは order_id parent_id どっち使う？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/198
199: 仕様書無しさん [sage] 2025/11/16(日) 12:51:25.32 受注IDなんだからorder_idにきまってる http://medaka.5ch.net/test/read.cgi/prog/1762945137/199
200: 仕様書無しさん [sage] 2025/11/16(日) 13:17:14.07 基本はドメインで使われる言葉（又はその英訳）をそのまま使うだな ユビキタス言語 http://medaka.5ch.net/test/read.cgi/prog/1762945137/200
201: 仕様書無しさん [sage] 2025/11/16(日) 13:34:20.84 DoctrineかRubyOnRailsかは忘れたが、id列はデータの種類やAppドメインとは無関係な内部値にするべきという考え方が広まってな orderテーブルだとしてもid列はただのrow idであってorder idではないのさ http://medaka.5ch.net/test/read.cgi/prog/1762945137/201
202: 仕様書無しさん [sage] 2025/11/16(日) 13:40:57.31 知らない土地で目を覚ましたらスマホも財布も貸与PCも全部盗まれてるって夢を見た http://medaka.5ch.net/test/read.cgi/prog/1762945137/202
203: 仕様書無しさん [sage] 2025/11/16(日) 14:27:04.46 ドメイン分析で主キーになりうる一意な項目があるならそれを主キーにするけどな 時々は複合キーも使う（ヘッダー番号+見出し番号とか） RestAPIのURLだと、〜/bills/101/details/20 みたいな ORマッパーも複合キーに対応するし やむを得ない場合はid使うけどそれ以外は わざわざidの項目増やして管理コスト増やしたくない http://medaka.5ch.net/test/read.cgi/prog/1762945137/203
204: 仕様書無しさん [sage] 2025/11/16(日) 14:29:12.22 誰とでも握手するみたいに、誰とでもセックスする時代になればいいのに http://medaka.5ch.net/test/read.cgi/prog/1762945137/204
205: 仕様書無しさん [sage] 2025/11/16(日) 14:33:00.50 体調崩すからヤダ http://medaka.5ch.net/test/read.cgi/prog/1762945137/205
206: 仕様書無しさん [sage] 2025/11/16(日) 15:08:12.78 そこはうまいことするんだよ http://medaka.5ch.net/test/read.cgi/prog/1762945137/206
207: 仕様書無しさん [sage] 2025/11/16(日) 15:11:10.91 ババアともセックスしなくちゃいけなくなるんだぞ http://medaka.5ch.net/test/read.cgi/prog/1762945137/207
208: 仕様書無しさん [sage] 2025/11/16(日) 15:12:24.60 VRなどで誰とでもセックスできるが実際は誰ともセックスしない世界になるのでほ http://medaka.5ch.net/test/read.cgi/prog/1762945137/208
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 22 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.012s