0327NAME IS NULL2009/09/27(日) 04:40:49ID:??? oracleは絶対落ちないなんてありえない前提なのにpostgreには要求するのかw どんなdbを使おうがフェイルセーフな構成にすればいいって自分で答えだしてるじゃん 0328NAME IS NULL2009/09/27(日) 19:50:33ID:???>>326 なんかあんまし大型案件やった事ないみたいなのでコメントだが。 規模と傾向もあるが基幹系ならIBM(i)とその他のベンダー+Oracleの組み合わせだとIBMの方が半額くらいのコストで開発・運用が可能だ。 無論、Oracleの方がコスト安いケースもあるが、「IBM=高い」と言うのは思い込みだ。 ある程度以上の資金がいるのは事実だが、>>326の意見は「安物買いの銭失い」な思考だ。
そして東証もけっこう落ちてるじゃねーかw 0329NAME IS NULL2009/09/27(日) 20:40:49ID:??? いいよな。天下りで仕事もらえるようなところは。 東証を落としてもお咎めなしだぜきっと。 0330NAME IS NULL2009/09/29(火) 01:30:04ID:??? 逆にIで落ちてたら大変なんじゃねw 0331NAME IS NULL2009/09/30(水) 01:32:27ID:??? 何故データベース設計は軽視されるのか? 0332NAME IS NULL2009/09/30(水) 05:39:47ID:??? 痛い目に会うような複雑なシステムじゃないから or ( 痛い目は末端がくらって表に出ない and それが痛い目だと気が付いていない ) 0333NAME IS NULL2009/09/30(水) 16:53:59ID:??? ちゃんとコスト計算が出来るまともなエンジニアが皆無。 0334NAME IS NULL2009/10/09(金) 23:00:06ID:??? アプローチ使ってるけど、アプリの使い方じゃなくて、データベース設計の初心者本てなんかないかな 0335NAME IS NULL2009/10/10(土) 17:22:36ID:???>>334 デマルコ読め 0336NAME IS NULL2009/10/11(日) 17:53:45ID:???http://www.amazon.co.jp/dp/4822281116
これ読めばいいの? 0337NAME IS NULL2009/11/24(火) 00:12:10ID:??? 賢者に聞いていいですか?
資格取った後も最新動向やら勉強会やらニュースとか読め。 0435NAME IS NULL2009/12/02(水) 00:43:57ID:??? なんだその痛すぎる自己紹介はw 0436NAME IS NULL2009/12/02(水) 01:12:12ID:??? ペーパーでplatinum結構いるよ goldだとやたらいる 0437NIN2009/12/02(水) 01:52:02ID:??? その先生方に確認したんだが、
テーブルの主キーの空きを管理するテーブルを作って、 主キーの空きを管理するっていうことを聞いたんだけど、ほんとかぬ? 0438NAME IS NULL2009/12/02(水) 03:45:08ID:??? OracleのGoldやPlatinumは講習会受けて取る資格だからな 難しいのは確かだけど時間と金がものを言う資格でもある 0439NAME IS NULL2009/12/02(水) 04:26:21ID:??? 国家資格の情報処理試験が評価されてない現実。 0440NAME IS NULL2009/12/03(木) 20:45:05ID:???>>425 1970年1月1日0時0分0秒からの経過秒数をDBに整数型で入れてるってこと?
…それはナイスな方法だな。今度使わせてもらうわ。 0441NAME IS NULL2009/12/03(木) 21:21:06ID:??? データ的には軽いけどトラブル対応時に人間が見て全く意味がわからないから死ねる というか死んだ 0442NAME IS NULL2009/12/04(金) 00:27:24ID:??? その手の変換ツールぐらい準備しておくものだ。プログラマなら簡単にツールぐらい作れるだろ。 0443NAME IS NULL2009/12/04(金) 01:15:07ID:??? いやだから普通にtimestampでいいじゃんて話じゃないのか プログラム上でだっていちいち変換して使わなきゃならんのだし 0444NAME IS NULL2009/12/04(金) 07:26:50ID:??? RDBMSによって実装が違うが、このケースでは普通にtimestampを使えばいいのでは? そういう型がないRDBMSなら仕方ないと思うけど。 0445NAME IS NULL2009/12/04(金) 08:09:50ID:??? Unix系のアプリなら、time_t型を入れると出し入れが便利じゃん。 変換するコストもいらないし。 0446NAME IS NULL2009/12/04(金) 09:21:40ID:??? 画面にそのまま出すのか 入力は? 0447NAME IS NULL2009/12/04(金) 22:45:54ID:??? まあUnix系なら「出し入れ」だけは便利な面はあると思う。 日付や時刻関連でGROUP BYするときにちょっと殺意が沸くくらいだな。 0448NAME IS NULL2010/03/21(日) 14:22:04ID:7Pz5sOZx age 0449NAME IS NULL2010/04/11(日) 16:39:24ID:??? ahe 0450NAME IS NULL2010/05/16(日) 01:23:57ID:LQJdvEO0 有効期間のあるマスタテーブルの主キーってサロゲートキーにできるのかな? 0451NAME IS NULL2010/05/16(日) 02:11:03ID:??? できるよ 0452NAME IS NULL2010/07/31(土) 21:47:51ID:IkDl9wDS age 0453NAME IS NULL2010/10/30(土) 13:29:21ID:??? インデックス10個のテーブルに100万件のデータってやばいですか? 0454NAME IS NULL2010/10/30(土) 14:23:02ID:???>>453 全然普通 0455NAME IS NULL2010/11/02(火) 22:37:47ID:??? それ殿くらいの鯖スペックでの話? 0456NAME IS NULL2010/11/03(水) 08:21:23ID:??? その辺の安鯖でも楽勝なレベル 要求性能にもよるが、10年前のハイエンドクラスだときついだろうね 0457NAME IS NULL2010/11/16(火) 17:14:04ID:??? atom 1.6GHz 2GBメモリで100人ぐらいの共有鯖でもおk? 0458NAME IS NULL2010/11/23(火) 16:06:12ID:lzgg56a3 余裕のヨーコゼッターランド 0459NAME IS NULL2010/11/24(水) 16:00:20ID:??? じゃあ問題出たら損害賠償請求するのでヨロw 0460NAME IS NULL2010/11/24(水) 21:25:35ID:??? じゃあ性能要件を満たす設計をしてあげたからその分の費用請求ヨロw 0.25人月で60万円でおk 0461NAME IS NULL2010/11/24(水) 21:32:17ID:??? 単価安いなw 0462NAME IS NULL2010/11/26(金) 21:57:49ID:??? 1人月240万だろ?充分高いだろ
ロジックとデータ(論理・物理)見てテストして 壁にぶち当たってマニュアルやら仕様書見て ソースとデータ(論理・物理)見てry・・・・ループ この作業以外で技術力を上げる方法なんか存在しない 0467NAME IS NULL2011/12/02(金) 21:33:33.05ID:kohrfEHA 派遣で天才プログラマーが消えた 0468NAME IS NULL2011/12/03(土) 00:57:01.54ID:???>>466 糞ワロタお前の情試の例はよりによってITパス/FEの午前かよw
高度のスペシャリスト系は良く出来てる 所詮知識なので合格即実務で出来る、ではないが 「この程度も知らずに実務やってないよね?」感はある 0469NAME IS NULL2011/12/03(土) 12:43:57.30ID:???>>468 高度がよく出来てる? アホか?回答速報当日出ないような奇問も混じってるわけだが? 0470NAME IS NULL2011/12/03(土) 13:50:27.97ID:???>>469 お前はずっとFE午前レベルの「プラズマテレビの〜」だけやってろw
お前みたいに高度もとれない程度の知識レベルの奴が設計してるシステムとか・・・ 関わってる連中が可愛そうだわ。まさにスレタイにピッタリな人間www 0471NAME IS NULL2011/12/04(日) 00:16:08.13ID:???>>470 難易度低い時に受けてたまたま取れたヤツが偉そうにしてるの見ると痛々しくなるよな。 基本はわかってるが応用効かないし、製品個別の仕様部分を考慮できなかったりロクなヤツがいない。 0472NAME IS NULL2012/04/23(月) 13:48:49.67ID:??? 専板のDB設計スレが保守の末落ちる程だから軽視も致し方ない 0473NAME IS NULL2012/07/15(日) 16:24:28.05ID:??? 大本の設計程制約少ないから楽に作れるもんなんだが、 逆に末端がどんどん依存してくれるから後で変更するのがた〜いへん。 わかってるとこだとDB設計にコストかけてくれる。 わかってないとこだと作る側の営業と使う側の購買が交渉にコストかけてくれる。 後者、会社関係単位で迷惑。
詳細テーブル全てに予めtempカラム群持たせるのって、 個人的にはかなりの糞だと思うんだが・・・ 0474NAME IS NULL2012/07/22(日) 12:59:18.94ID:??? 予備カラム…COBOL脳全開の設計ですな。 0475NAME IS NULL2012/07/22(日) 14:06:03.40ID:C+pjCT8o そこで列指向データーベースですよ 0476NAME IS NULL 2012/07/23(月) 19:43:57.61ID:??? そうそう ところで激安中古CAD専門店っていいの見つけた。 かなり安いし使える 0477NAME IS NULL2012/07/24(火) 22:41:20.78ID:???>>474 何百万レコード級のテーブルを 使ったことはある?
ALTER TABLEだけで何十分とか 当たり前にかかったりするぞ。 それを思えば、ハナからバカにした ものでもない。 0478NAME IS NULL2012/07/24(火) 22:49:28.17ID:???>>477 レコード数が多いからこそ、カラム数を減らすべきだってことが分からないのか? 0479NAME IS NULL2012/07/24(火) 22:55:57.42ID:??? COBOL脳だとRDBにおいてはテーブルサイズが大きくなるとパフォーマンスが加速度的に劣化する場合があることを理解できない。
あいつらなんでもかんでも一行づつ処理しようとする。
処理時間=一行の処理時間(一定)×行数
はRDBじゃ通用しないんだよ 0480NAME IS NULL2012/07/24(火) 23:29:57.10ID:qDs+O0CQ 某H関連会社に訪れた際、若手SEが仕様レビューを受けていた 「ここでSQLのSUM関数で合計を取得します」 「それ信用できるの?ちゃんと一つずつ足さないとダメだよ」
通常これは実在しない。 0562NAME IS NULL2020/12/28(月) 23:56:41.44ID:???>>561 ごめん、何言ってるかわからない 抽象的なデータモデルって何のこと? どっから出てきたの? 0563NAME IS NULL2020/12/29(火) 03:14:05.40ID:??? 更新異常が発生しにくいだけで 考慮する必要がないわけないわな >>561はエアプが即バレして煙に巻きたいのだろう 0564NAME IS NULL2020/12/29(火) 09:14:29.22ID:??? >ソースデータの正規形
これが抽象的なデータモデルを指しているのかと思ったんだが、そうでないなら話は簡単。 DWHは「ソースデータの正規形」が存在することを要求しないんで>>560は正しくない。 データソースが正規化された他のDBであることはあるが、それはそのシステム自身の 要求によって正規化されているだけ。 0565NAME IS NULL2020/12/29(火) 12:56:45.72ID:???>>557 正規化がバカにされてるんじゃなく 正規化を理解してなかったり正規化されてるかどうか以外にDB設計を見る目がないのに ドヤ顔でDB設計を語ろうとしてる人間がバカにされてるんだと思うぞ 0566NAME IS NULL2020/12/29(火) 14:29:23.16ID:??? それな ちょうど当てはまるやつがいるな 0567NAME IS NULL2020/12/29(火) 14:46:08.18ID:??? 頭おかしいやつには下手に触らず黙ってスルー推奨 0568NAME IS NULL2020/12/30(水) 00:27:51.52ID:??? RDBと関係ないRやPython使った統計処理の分野でも 分析をやりやすくするために下準備としてDBで言うところの正規化をしてる 更新異常を考慮する必要は全くないけど 0569NAME IS NULL2020/12/30(水) 09:11:39.06ID:??? そういうのごっちゃにすると話が発散するからやめて。 そもそもその「正規化」って、リレーションの正規化と違ってなにをどうするかきちんと定義されたものじゃないでしょ。 0570NAME IS NULL2020/12/30(水) 09:15:25.16ID:??? それに統計解析向けの加工って、クレンジングは最初に必要かもしれないけどあとは解析しやすいようにJOINしまくるのがふつう。 DWHのスタースキーマから任意に抽出した1つの表の形のデータセット、あれがまさに統計解析向けのもの。 0571NAME IS NULL2020/12/30(水) 18:11:29.74ID:??? エアプDWHの次はエアプ統計解析かよw なんでろくにやったこともない事を語りたがるのかね 0572NAME IS NULL2020/12/30(水) 18:23:27.87ID:??? データベース設計は軽視されるの原因と エアプ野郎が語りたがる原因の一つに 素人に毛が生えたような人間には難しさが分からず 自分でもできそうに思えてしまうところにある 0573NAME IS NULL2020/12/30(水) 22:22:42.93ID:???>>571 誰のどのレスに対して言っているのか曖昧でよくわからんが、とりあえずどのレスの どこがどう違っているのかはっきり書いたら? 反論は受けたくないけどマウントだけ取った気分になりたい中学生じゃなけりゃ。 0574NAME IS NULL2020/12/31(木) 00:08:25.03ID:??? エアプ素人さんはスタースキーマのファクトとディメンションがそれぞれ第何正規形か考えると良いと思うよ
>>565の言葉を借りれば正規化すら理解してないのにドヤ顔で語ろうとしてるのが丸わかりだから 0575NAME IS NULL2021/01/02(土) 16:36:20.20ID:2lMlvbHe ど底辺の土方グラマーだけどDB設計させられて「なんでちゃんとしたDB屋に頼まないんだよ、DBって根幹部分で大切だろ!」って疑問だったけどここ見て納得。 日本の企業が作る(使う)システムがクソな理由も・・・ 0576NAME IS NULL2021/01/02(土) 18:35:41.55ID:??? ある意味当たってる。 そうやってしばらくして、曲がりなりにもER図書いたり正規化ができるようになって いっぱしのDB屋を気取れるようになったら彼等の仲間入り。 0577NAME IS NULL2021/01/03(日) 14:52:40.06ID:???>>575 根幹部分だからこそDB中心のシステムを作る開発者なら誰もが身につけておくべきスキルだぞ
要件定義や基本設計を含めて依頼するならともかく DB設計だけを外部に依頼するのは今の時代にはそぐわないので設計専業のDB屋は絶滅危惧種 0578NAME IS NULL2021/01/04(月) 05:23:06.48ID:THUOMM/C ホンマにうわさ以上に凄いのが金さんの億様株レシピて投資ブログ。 ここまじで神すぎる! めちゃ当てまくる。 おすすめなのは危険な銘柄と宝石の銘柄て記事に出てくる銘柄。 0579NAME IS NULL2021/01/12(火) 12:19:00.49ID:??? プログラム組まないやつが設計すると保守性重視になるよな… 人間がパッと見て理解しやすい設計にしがち ナチュラルキー多用したり 0580NAME IS NULL2021/01/12(火) 15:18:33.28ID:???>>579 ナチュラルキーを多用してるにもかかわらず保守性が高いならいいんじゃね 0581NAME IS NULL2021/01/12(火) 16:22:51.65ID:???>>580 >>579は「保守性」と言っちゃってるが、実はたぶん保守性の話やないな。 初見のわかりやすさしか見えてないような、困ったちゃんの話なんやろな。 0582NAME IS NULL2021/01/12(火) 17:06:29.79ID:??? そうすると保守性を理解してない>>579が困ったちゃんってことになる 0583NAME IS NULL2021/01/12(火) 17:48:57.44ID:??? すまん、保守性って言葉が悪かったな プログラムの保守性ではなくて ユーザーからの問い合わせ時にデータ見てパッとわかるテーブル構造を好む 0584NAME IS NULL2021/01/12(火) 20:38:59.75ID:??? 人間にとっての見やすさというかわかりやすさも重要な品質要素だからね それを犠牲にして得られるメリットとのバランス次第 何と何をトレードオフしようとしてるのか理解してないうちはまともな設計は期待できない 0585NAME IS NULL2021/01/12(火) 21:08:10.26ID:??? パッと見理解しやすくて保守性も高いならいいことずくめに読めるが。
たぶん言いたいことは逆になにか問題があるということなんだろうけど 結論書いてないから何を言いたいのかわからない。 0586NAME IS NULL2021/01/12(火) 21:28:46.10ID:???>>585 理解力なさすぎ。 人工キー+JOIN前提みたいな、不慣れだとややこしげに見えるテーブルを組みたがらない素人の話なだけやろ。 0587NAME IS NULL2021/01/12(火) 21:37:08.48ID:??? だから、そこで自然キーの欠点や人工キーの利点を説明しなきゃ何を言いたいのかわからんだろ。 人工キーが自然キーより優れているのは自明だと思ってるとかそんなとこかね。 0588NAME IS NULL2021/01/12(火) 21:45:26.42ID:???>>587 SQL書くときに条件や結合は少ないほうがバグが発生しにくい プログラマにとってはサロゲートキーの方がわかりやすい
しかしサロゲートキーだと生データを見たときにわかりにくいことがある
ナチュラルキーとサロゲートキーの代表的なメリットデメリットだと思うけど…
その辺天秤にかけてこのテーブルはサロゲートキー、このテーブルはナチュラルキーと決定できるのは 設計もプログラムも保守もやる人。 どれか一つしかやらない人はこのへんのさじ加減わからないのでは。 0589NAME IS NULL2021/01/12(火) 21:57:42.32ID:??? こうやってブレイクダウンするとどこに誤解があるか見えてくる。
複合キーは扱いづらいのでかわりにサロゲートキーを使うことはあるが 自然キーだと一律にサロゲートキーより扱いづらいなんて理由はないだろう。 0590NAME IS NULL2021/01/12(火) 22:30:44.50ID:???>>589 おっしゃる通り複合キーの場合だな 大変失礼しました
設計と保守しかしない年配のSEさんはサロゲートキーを知らずに複合キーを使いまくる傾向にある プログラマは若かったり雇われだったりなので口出しできずにクソシステムの出来上がり 0591NAME IS NULL2021/01/12(火) 22:34:47.77ID:???>>589 めんどくさ。 そんな話じゃなかったやろ。。。
おまえは、自分が理解できない話を、自分が理解できるようにしたいだけ。w 何が「ブレイクダウン」や。w 0592NAME IS NULL2021/01/12(火) 22:41:52.84ID:??? >そんな話じゃなかったやろ。。。
どういう話なのか、お前はまず言いたいことを結論からハッキリ書くようにしろ。 0593NAME IS NULL2021/01/13(水) 00:21:46.78ID:??? 呼び名はともかく人工キーは80~90年代でも普通に使われてただろうから年配だろうが知らないわけない
複合キーは見てわかりやすいわけじゃないが 人工キーに比べると整合性を維持する設計が簡単なんだよ SQL書く時は面倒くさいから嫌がられるけど不整合が発生するのに比べればマシだから 0594NAME IS NULL2021/01/13(水) 00:38:42.76ID:???>>592 自分の理解力を棚に上げんなよ。 0595NAME IS NULL2021/01/13(水) 00:53:04.45ID:???>>593 不整合はユニーク制約つければいいんでないの 0596NAME IS NULL2021/01/13(水) 08:06:07.69ID:??? 同じ型の単純キー同士なら、それが自然キーか人工キーかで扱いやすさが変わることはないやね。 0597NAME IS NULL2021/01/13(水) 08:13:51.20ID:???>>596 変わらない 複合キーが問題 0598NAME IS NULL2021/01/14(木) 02:05:44.63ID:???>>593 ちょっと、「整合性を維持する設計」について詳しく説明してくれ 0599NAME IS NULL2021/01/20(水) 22:55:59.22ID:LfU5rlWt>>557 仕様変更に強いかどうか。それと人間にとってわかりやすいかどうか。正規化の話はもっともらしいが、ちゃんとしたテストと運用・保守をやっていれば、ただの非現実的な理屈だとわかる。 0600NAME IS NULL2021/01/20(水) 23:01:10.32ID:LfU5rlWt>>593 論理的な整合性をアプリケーションで担保する。そうでないとアプリケーションのテストも難しい。 0601NAME IS NULL2021/01/20(水) 23:02:58.59ID:LfU5rlWt>>598 彼はアプリ屋と壁を作るタイプだから、かかわらない方がいいよ。 0602NAME IS NULL2021/01/20(水) 23:16:12.27ID:???>>599 アホなの? 0603NAME IS NULL2021/01/22(金) 08:45:35.16ID:???>>599 このちゃんとした ってのがどれだけ難しいか 0604NAME IS NULL2021/01/25(月) 05:16:41.94ID:cGhuaVFN よく読め 06055752021/06/22(火) 17:07:34.18ID:??? ははは・・・ 晴れて?「DB屋()」の仲間入りしそうだ・・・ PostgreSQL9.3とSQLServer2005を、プライベートで、弄ったことあるだけなのに(実務ではOracle11の炎上案件の燃料として放り込まれたぐらい) 7月からPostgreSQL12がフロントエンドで、Oracle(ナンバリングは効いてない)がバックエンドで動いてる「工場のFAのすごいやつと思えば間違いじゃない(スマートファクトリー)」とかいう謎の説明されたシステムのDBチームに配属になったわ・・・ メカ系や移動体通信系のファームしか経験ないつにいきなり・・・ ズブの素人よりはマシかもしれないけどDBそのもののスキルだったらそこらの学生以下だよ俺・・・orz. 0606NAME IS NULL2021/06/22(火) 18:09:02.74ID:??? いまどきDBでチームがあるのか ある意味すごいな 0607NAME IS NULL2021/06/22(火) 18:59:21.66ID:wVCfrFWc>>606 開発対象が、工場の機械からデータ受け取る中継ボックスみたいなところから、工場の中間サーバから複数の工場の情報をまとめるサーバまで一貫してるんだそうな。 そして中継ボックス、中間サーバ、全体の情報あつめるサーバってのを全部面倒見てる10人ほどのチームとのこと。 まだ現場に入ってないから実態判らんけど、門外漢な俺を採用しちゃうところだし、上下どころか横の連携もまともにとれないようなカオスなところでもおかしくないって個人的な経験則が言ってる。
他に仕事ないから受けたけど、今から「どんなとこかなー? 抜けるとしたらどうやって抜けようかなー?」って考えてるw 0608NAME IS NULL2021/06/22(火) 21:26:23.41ID:??? もし関係者が見たら、特定できそうやな。w ほどほどにしとけよ。 0609NAME IS NULL2021/06/26(土) 18:20:28.11ID:??? データベースのテーブル設計書ってどうしてる? エクセル方眼紙にしてかいてるんだけど、なんかいいのないのかな 0610NAME IS NULL2021/06/26(土) 23:14:34.00ID:???>>609 MySQL Workbenchはどや? 最近は使ってないから知らんが。 0611NAME IS NULL2021/07/03(土) 17:38:43.26ID:R35jReGz>>609 A5Mk-Uがよく使われている。 0612NAME IS NULL2021/10/13(水) 12:36:34.50ID:??? データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや? 教えてくれ 0613NAME IS NULL2021/10/13(水) 13:54:50.17ID:??? 特にどのDBMSをターゲットにしてるとかないぞ 一般的なBTreeを前提にしてるだけ 0614ド底辺PG2021/11/10(水) 22:00:45.28ID:KaB0M86I プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT(可変長文字列)をPKにしてINDEX張ってて「パフォーマンス出ねぇ!」ってやってんですけど・・・ ちょう乱暴に描くと CREATE TABLE T_TAGS( JPN AS TEXT NOT NULL, ENG AS TEXT, ・・・品詞とか同義語とかの定義いろいろ・・・ PRIMARY KEY(JPN) ) て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ?
ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの?」ぐらいの疑問はあるんだけど、 これって「データベースあるある」だったりするの? 0615NAME IS NULL2021/11/10(水) 22:40:02.10ID:??? 遅いのがTEXTのせいだってどうやって判断したの? 0616NAME IS NULL2021/11/11(木) 00:02:07.19ID:???>>614 >これって「データベースあるある」だったりするの? 文字列をPKに使うかどうかは状況による 絶対避けるというほどのものでもない 個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ 全部可変長で揃えてても特に問題なかったりする
PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん? 0617NAME IS NULL2021/11/11(木) 19:06:31.16ID:NSxyRLjO>>614 あなたの言っていることは頭がおかしいくらい変なことを言っている。
たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか?
念を押すと、頭のおかしい発言だぞ。 0618NAME IS NULL2021/11/11(木) 19:36:50.37ID:NSxyRLjO>>614 そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな? 0619NAME IS NULL2021/11/11(木) 20:16:55.16ID:???>>617 そこまでやないやろ。w テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。