DB設計を語るスレ 10 [無断転載禁止]©2ch.net

[1 NAME IS NULL 2017/05/22(月) 16:38:31.52 ID:???]

語れ

前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/

[2 NAME IS NULL 2017/05/22(月) 17:22:02.30 ID:???]

１ちょつ

[3 NAME IS NULL 2017/05/22(月) 21:59:23.81 ID:???]

乙

[4 NAME IS NULL 2017/05/23(火) 09:06:17.88 ID:1YMhep2r]

乙

[5 NAME IS NULL 2017/05/25(木) 15:57:16.88 ID:???]

「複合主キーにしろ」野郎、うぜー

[6 NAME IS NULL 2017/05/26(金) 22:01:38.57 ID:???]

どれのことかよくわからんけど、たぶんバカが逆切れしてるんだろうなぁ。

[7 NAME IS NULL 2017/05/29(月) 19:54:48.57 ID:???]

おつ！

[8 NAME IS NULL 2017/08/23(水) 00:45:19.03 ID:???]

カッペラッパー最高

[9 NAME IS NULL 2017/08/25(金) 05:55:35.66 ID:???]

かっぺラッパー最高

[10 NAME IS NULL 2017/10/31(火) 23:10:54.44 ID:???]

例えば食料品の情報をテーブルに入れるとすると
キッコーマン醤油 500ml 300円 塩分8%
ネスカフェ 300g 450円
菊正宗 1.8L 1000円 アルコール度数15
こんなデータだと、商品名や単価は各データに共通ですが、それ以外は共通点が有りません。
こう言う場合どんなカラムを持つテーブルを作成すべきですか?

[11 NAME IS NULL 2017/10/31(火) 23:55:10.31 ID:???]

各数値をなにかに使うならカラムを作ればいいし
単なる文字情報なら商品名に突っ込んどけばいい

[12 NAME IS NULL 2017/11/01(水) 00:01:10.65 ID:???]

>>11
＞各数値をなにかに使うならカラムを作ればいいし
商品名 単価 塩分 アルコール度数 、、、
みたいにするって事ですか?
＞単なる文字情報なら商品名に突っ込んどけばいい
それだと例えば 15<アルコール度数 みたいな検索がやり辛いですよね？

[13 NAME IS NULL 2017/11/01(水) 00:12:16.37 ID:???]

その例だけ見ると内容量も共通

アルコール度数や塩分濃度みたいな商品の詳細情報で
精度・性能ともに高いレベルのフィルタリングが必須なら
そういう分類で別途ククリだす

価格.comの検索とかで
商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
あのイメージ

[14 NAME IS NULL 2017/11/01(水) 07:07:56.85 ID:???]

>>13
＞そういう分類で別途ククリだす
＞
＞価格.comの検索とかで
＞商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
＞あのイメージ
まだよくわからないんですが、一つのテーブルでは無くて、複数のテーブルに分けるようなイメージですか？
そうだとしても、よく分かりません。

[15 NAME IS NULL 2017/11/01(水) 14:40:35.09 ID:???]

>>14
「データベース 派生関係」でググって

[16 NAME IS NULL 2017/11/01(水) 16:39:16.89 ID:???]

>>10
EAV

商品 (商品ID, 商品名, 単価)
商品属性 (商品ID, 属性名, 値, 単位)

[17 NAME IS NULL 2017/11/01(水) 17:15:33.60 ID:???]

EAVはRDB的にはほぼ例外なくアンチパターン

[18 NAME IS NULL 2017/11/01(水) 18:05:43.74 ID:???]

>>17
ならより良い解答してあげて

[19 NAME IS NULL 2017/11/01(水) 18:08:06.97 ID:???]

jsonで入れとけばよくね？

[20 NAME IS NULL 2017/11/01(水) 19:18:20.98 ID:???]

>>17
お前みたいな低能にはそうなんだろうな...

[21 NAME IS NULL 2017/11/01(水) 20:18:17.14 ID:33PRYza3]

ただの入れ物にしていく時代に逆行するパターンだなw

[22 NAME IS NULL 2017/11/01(水) 20:46:47.43 ID:???]

実際価格コムだとどうしてんだろうね
基本マスタとカテゴリごとのマスタに分けてる感はあるけど

[23 NAME IS NULL 2017/11/01(水) 21:10:54.54 ID:???]

>>18
派生関係

[24 NAME IS NULL 2017/11/01(水) 21:18:05.38 ID:???]

>>22
金融商品やプロバイダは別として
家電やPC系は共通マスタと派生マスタで管理してると思うよ
パフォーマンスのための最適化は別途してるかもしれないけどね

http://kakaku.com/pc/note-pc/itemlist.aspx?pdf_Spec101=39
http://kakaku.com/kaden/lcd-tv/itemlist.aspx?pdf_Spec301=42-46

↑この辺比べるとよく分かる

[25 NAME IS NULL 2017/11/01(水) 21:46:09.22 ID:???]

>>23
商品の種類だけテーブルを増やしていくんだな
買った商品一覧を詳細付きで取ってきたい時とかすげぇ面倒そうだ

[26 NAME IS NULL 2017/11/01(水) 21:49:42.43 ID:33PRYza3]

>>25
そんな要件があると思えない。

[27 NAME IS NULL 2017/11/01(水) 22:24:52.60 ID:???]

>>26
仮定の話なんで
ちなみにやる事になったらどんな実装で対応する？
後学のために知っておきたい

[28 10 2017/11/01(水) 22:58:04.66 ID:???]

皆さんありがとうございました。
>>24
この価格コムの場合、
[最安価格][売れ筋][レビュー評価][クチコミ件数][登録日][スペック情報]
のようにしておいて、
[スペック情報]の部分でパソコンやテレビなどのカテゴリーの事なる製品の
情報を保管するわけですね。
そう言うのを共通マスタと派生マスタと言うんですか？
ググって勉強してみます。
疑問点があればまた質問しますので、よろしくお願いいたします。

[29 24 2017/11/01(水) 23:50:31.77 ID:???]

自分で言っといてなんだが共通マスタと派生マスタという呼び方はあまり一般的ではないかも
>>22の書いてる基本マスタとカテゴリ別マスタみたいな呼び方のほうが多いかもね
とりあえずデータベースの派生関係とか継承でググれば解説してるサイト出てくるよ

[30 NAME IS NULL 2017/11/04(土) 01:17:17.38 ID:???]

派生マスタってじつは見たことない
たいていカラム増やすか予備カラムにまとめてぶっこんでる

[31 NAME IS NULL 2017/11/04(土) 14:30:10.74 ID:???]

>>30
>予備カラムにまとめてぶっこんでる
そんなの手抜きシステムだろ

[32 NAME IS NULL 2017/11/06(月) 15:55:51.67 ID:???]

>>19
そんなの有り？

[33 NAME IS NULL 2017/12/13(水) 20:21:33.68 ID:id+unZ0U]

名簿みたいなデータではPKを何にしたら良いでしょうか？
電話番号だと電話が無い人もいるし。

[34 NAME IS NULL 2017/12/13(水) 23:20:33.63 ID:???]

ほんとになにもないなら自分で連番振っとけばいいんじゃね

[35 NAME IS NULL 2017/12/14(木) 10:20:17.61 ID:???]

まー名寄せというのは名前が付くくらい昔からある根深い問題だよな

[36 NAME IS NULL 2017/12/14(木) 11:24:40.98 ID:???]

ハッシュを使うのはどうなん？

[37 NAME IS NULL 2017/12/14(木) 22:30:10.07 ID:???]

同じことだよ。ハッシュで区別できるためには元のデータで区別できなきゃならん。
連番も似たようなもの。

[38 NAME IS NULL 2017/12/15(金) 01:33:41.72 ID:???]

一般的なハッシュってのは
違う物に対して同じ値を生成するんだぜ
元のデータで区別できたとしても、ハッシュかけた段階で区別できなくなる可能性があるんだが
そんなものを主キーにするとか狂気のさただな

[39 NAME IS NULL 2017/12/15(金) 09:28:07.27 ID:???]

>>38
>一般的なハッシュってのは
>違う物に対して同じ値を生成するんだぜ
そんなハッシュあるのかｗ

[40 NAME IS NULL 2017/12/15(金) 11:30:27.39 ID:???]

まったくないとは言わんが
天文学的に小さいな

[41 NAME IS NULL 2017/12/15(金) 12:21:10.16 ID:???]

つまりハッシュ値と連番は本質的に全く別物

[42 NAME IS NULL 2017/12/15(金) 12:22:24.34 ID:???]

ハッシュ衝突は理屈上あるが
元データさえ違うなら心配する確率ではないね
とはいえ、PKに使うものじゃないと思うし連番で十分じゃないかな

[43 NAME IS NULL 2017/12/15(金) 20:41:37.20 ID:6QrkU8mN]

いや元が同じだったら衝突とは言わんからw

[44 NAME IS NULL 2017/12/15(金) 22:00:00.19 ID:???]

ハッシュが衝突しないとか言ってる奴はMD5みたいな奴しか知らんのか？
理屈上どころか衝突前提のハッシュなんていくらでもある

[45 NAME IS NULL 2017/12/16(土) 07:09:25.86 ID:E1KHECAF]

>>44
おまえは何の勘違いをしとるんやw

[46 NAME IS NULL 2017/12/16(土) 08:06:02.76 ID:???]

>>45
はあ？
衝突前提のハッシュ知らんのか？
せめてここでも見とけよ
https://ja.m.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0

[47 NAME IS NULL 2017/12/16(土) 12:38:08.13 ID:???]

>>46
で、それ見て何を勘違いしたんやお前はw

[48 NAME IS NULL 2017/12/16(土) 13:13:01.80 ID:???]

なんだ、単なるレス古事記かよ

[49 NAME IS NULL 2017/12/16(土) 14:38:38.92 ID:???]

文脈やと思うけどなぁ

[50 NAME IS NULL 2017/12/16(土) 15:28:06.06 ID:???]

MD5辺りを単にハッシュと書いたアホが引っ込みつかなくなってるだけでしょ

[51 NAME IS NULL 2017/12/16(土) 16:16:42.51 ID:???]

というか、MD5はハッシュだし
MD5だって衝突の可能性はあるわけだが

[52 NAME IS NULL 2017/12/16(土) 21:36:50.89 ID:E1KHECAF]

おいおいMD5はハッシュ関数やぞw

[53 NAME IS NULL 2017/12/16(土) 22:34:42.89 ID:???]

>>52
こんなアホな突っ込み久々に見たわ w

[54 NAME IS NULL 2017/12/16(土) 22:56:10.26 ID:E1KHECAF]

>>53
やっとわかったわ
お前勘違いやなくそもそも根本的に何もわかっとらんやろw

[55 NAME IS NULL 2017/12/16(土) 23:00:47.03 ID:???]

友達いないんだろうな...
まあ頑張って一人て吠えてなよ w

[56 NAME IS NULL 2017/12/16(土) 23:06:48.97 ID:E1KHECAF]

>>55
いやお前がもっと頑張れやw
最初の勢いはどうしたw

[57 NAME IS NULL 2017/12/17(日) 08:05:30.02 ID:???]

また吠えてるよ...
技術的な話じゃなくなると勢いあるな w

[58 NAME IS NULL 2017/12/17(日) 12:37:49.59 ID:???]

>>57
え？技術的な話じゃなかったのかw
お前のその深い勘違いの根っこは一体どこにあんねんw

[59 NAME IS NULL 2017/12/17(日) 14:02:17.70 ID:???]

>>58
俺は技術的な話のつもりだったけど
「勘違い」としか連呼できないアホが絡んできたってだけのこと

[60 NAME IS NULL 2017/12/17(日) 19:39:41.63 ID:GmUw4YSY]

>>59
しゃあないやろ勘違いをしとるんはお前なんやからw自業自得やぞw

[61 NAME IS NULL 2017/12/18(月) 04:59:23.82 ID:???]

ほらね w

[62 NAME IS NULL 2017/12/19(火) 16:42:48.07 ID:N2E99BBw]

>>61
どや？そろそろ耳の火照りもひいた頃合いやろからお前の勘違いを全部さらけだしてみたらどうや？
間違ってるとこおしえたるでw

[63 NAME IS NULL 2017/12/19(火) 19:29:26.17 ID:???]

>>62
> 間違ってるとこおしえたるでw
書いてからほざけよ w
どうせ頓珍漢なことしか書けないから引っ張ってるだけだろ？

[64 NAME IS NULL 2017/12/19(火) 19:59:07.34 ID:N2E99BBw]

>>63
アホかとっくにしびれをきらしとるわw
いいから早くお前がハッシュを何だと思ってるのか書けよ
お前の勘違いしてるとこ教えてやるからw

[65 NAME IS NULL 2017/12/19(火) 22:29:33.59 ID:???]

どうせハッシュ関数とハッシュ値は違うとか言い出すんだろ
文脈で判断しろよ、バーカ w

[66 NAME IS NULL 2017/12/20(水) 08:25:59.98 ID:LkqKP4ic]

>>65
それはもう教えてやったやつやろw頓珍漢はお前やわw
てかそんなに恥かくの嫌やったらはじめから何も言うなやw
ホンマにカスやなお前w

[67 NAME IS NULL 2017/12/20(水) 08:46:00.54 ID:???]

言い当てられて顔真っ赤やん w

[68 NAME IS NULL 2017/12/20(水) 08:57:14.74 ID:LkqKP4ic]

>>67
また動揺してエセ関西弁うつっとるでw恥ずかしいのぉ〜w

[69 NAME IS NULL 2017/12/20(水) 12:55:06.94 ID:???]

>>68
まだ粘着してるのかよ w
勘違いと言い張るならどこのレス見てどう勘違いしてると思ったのか書けよ
それが書けないからいつまでも勘違いを連呼するしかないんだろ w

[70 NAME IS NULL 2017/12/20(水) 15:28:12.50 ID:LkqKP4ic]

>>69
お前なあwメッチャ自分の勘違いが気になっとるくせになんで素直に聞けんのやw
粘着しとるのお前やでw恥ずかしいのぉ〜w

[71 NAME IS NULL 2017/12/20(水) 17:47:08.79 ID:???]

はいはい、具体的なにも指摘できないならいちいち絡んでくるなよ w

[72 NAME IS NULL 2017/12/20(水) 18:50:24.06 ID:LkqKP4ic]

>>71
何かうやむやにしたいみたいやけど悔しくてレス返さんと気がすまんのやなw
てかそもそも誰もお前がスキル高い奴だなんて思っとらんからそんなに悔しがる意味もないんやけんどなw

[73 NAME IS NULL 2017/12/20(水) 19:09:52.02 ID:???]

>>72
>>71

[74 NAME IS NULL 2017/12/20(水) 20:03:30.28 ID:???]

何のためにもならない罵り合いになってるので、もうやめたら？

[75 NAME IS NULL 2017/12/20(水) 20:29:25.30 ID:LkqKP4ic]

>>73
まだレス返すんかwどんだけ悔しいんやw
無理してそんな煽りレスばっかしとらんと素直にハッシュについて言えばいいやんけw
教えてやるって何度も言っとるのにw

[76 NAME IS NULL 2017/12/20(水) 21:17:35.06 ID:???]

>>75
>>46
煽りしかできないアホの出る幕じゃねーよ w

[77 NAME IS NULL 2017/12/21(木) 07:29:56.41 ID:m6k27wgo]

>>76
おいおい何ふりだしに戻しとるんやw
やっぱり何もわかっとらんから自分の言葉で言えんやんけw
で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
言ってみ？教えてやるからw盛大にバカにした後でやけどなwww

[78 NAME IS NULL 2017/12/21(木) 08:07:26.64 ID:???]

当事者じゃないけど、うざいよ。

ハッシュテーブルのこといってるんじゃないの？グルーピングの用途でハッシュ関数使うって意味で

[79 NAME IS NULL 2017/12/21(木) 10:05:36.30 ID:???]

データベースの用途で、グループ分けしたい時に
多対一の変換に意味があるのか？

[80 NAME IS NULL 2017/12/21(木) 10:22:53.47 ID:???]

>>79
多対1じゃなくて、多対n。結合するときにないぶてきに使われるhash joinとかこの方式だよね。

[81 NAME IS NULL 2017/12/21(木) 10:24:46.30 ID:???]

衝突前提じゃないハッシュは完全ハッシュとかいわれて普通はただのハッシュとは違う扱いなわけだが

いいかげん具体的な指摘なしで勘違いとしかほざけないやつはうざいわ

[82 NAME IS NULL 2017/12/21(木) 10:49:25.14 ID:o/6FHTRS]

今日のお弁当にはハッシュドポテトが入っています

[83 NAME IS NULL 2017/12/21(木) 12:54:19.84 ID:???]

>>77
> で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
前提なしでハッシュって書いたら衝突するケースを想定するのは当たり前
そう言うことを知らなかった>>39が暴れてるだけだろ

[84 NAME IS NULL 2017/12/21(木) 12:57:47.83 ID:cIfjA39h]

おやおやようやく勘違いの全貌が見えて来よったなw
後で教えたるからなw
とりあえずそれまでみんなで>>81を盛大にバカにしときw

[85 NAME IS NULL 2017/12/21(木) 15:07:28.11 ID:???]

しつけえよ馬鹿

[86 NAME IS NULL 2017/12/21(木) 15:50:38.56 ID:???]

で結局33の質問に対して正解は何？

[87 NAME IS NULL 2017/12/21(木) 19:55:49.52 ID:???]

何の名簿か知らんけど、会社でも社員コードってのがあるんだから>>34で良いじゃん。
何揉めてんだか
>>33はそれの何が不満なんだよ。

[88 NAME IS NULL 2017/12/21(木) 20:28:48.83 ID:???]

なんだこれ。

PKを連番じゃなくてハッシュ値にすべきって散々煽ってたのか。どんな回答するのかすげー気になるわ。

[89 NAME IS NULL 2017/12/21(木) 21:31:06.81 ID:???]

>>86
>>87の言う通り社員番号とかのユニークキーがあればそれを使えばいい
なんにもなければ>>34の言うように連番を振るとかyymmdd+枝番とか要件によってユニークな番号を振ればいい
とりあえずハッシュバカは無視でいい w

[90 NAME IS NULL 2017/12/21(木) 22:13:21.18 ID:m6k27wgo]

>>89
お？バカ少しおとなしくなったやんけw完全ハッシュはどうしたw

[91 NAME IS NULL 2017/12/21(木) 22:40:25.61 ID:???]

なんだ、ただのキチガイか。

[92 NAME IS NULL 2017/12/21(木) 22:42:05.48 ID:???]

安易に連番ってのもたいていバカだけどな。

[93 NAME IS NULL 2017/12/21(木) 22:50:31.46 ID:???]

適切なものがなければ、作らなくて良いと思うが

[94 NAME IS NULL 2017/12/22(金) 00:27:00.22 ID:???]

>>90
完全ハッシュについて調べてこいよ w

[95 NAME IS NULL 2017/12/22(金) 00:30:58.20 ID:???]

>>92
もっといい解があるなら示してみてよ

>>93
> 適切なものがなければ、作らなくて良いと思うが

> PKを何にしたら良いでしょうか？
って言ってるのにバカですか？

[96 NAME IS NULL 2017/12/22(金) 00:48:01.41 ID:???]

PKを指定しなければDB側で良きに計らってくれるんじゃ？

[97 NAME IS NULL 2017/12/22(金) 03:07:52.25 ID:???]

連番を良きに計らってくれる機能は多くのDBMSで実装されてるが
PKを指定しないときによきに計らってくれるDBMSなんてみたことないわ

と言っといて、ACCESSとか勝手に連番でPK作ってくれた気もするな

すくなくともRDBMSの基本理念においては、すべてのテーブルはPKを持つべしっとなってる

[98 NAME IS NULL 2017/12/22(金) 03:28:06.91 ID:???]

実際プライマリーキーのないテーブルが作れるんだから
持つべしってことはないでしょ

[99 NAME IS NULL 2017/12/22(金) 05:48:11.28 ID:???]

住所、氏名を複合PKにするとか

[100 NAME IS NULL 2017/12/22(金) 07:21:44.64 ID:KAIeoRcz]

>>94
ええでその調子やwビビらんともう少しその勘違い晒せやへたれw

[101 NAME IS NULL 2017/12/22(金) 08:14:52.49 ID:???]

>>95
例えば、レコードとして実在の個人を表現したいのに氏名しかないから同姓同名の人が
区別できない、なんてのはそもそもシステム設計の失敗。
それを単に連番振れば解決するかのように言う奴はバカだし有害。

有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。

[102 NAME IS NULL 2017/12/22(金) 08:43:18.68 ID:???]

>>101
> 個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
> 仕組みも必要。。
そんな当たり前のことを力説されても困るわ w

[103 NAME IS NULL 2017/12/22(金) 10:45:03.07 ID:???]

>>101
>有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
>(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
>個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
>仕組みも必要。。

すまんが、これって連番振るのと何が違うの？

[104 NAME IS NULL 2017/12/22(金) 11:01:13.97 ID:???]

>>103
俺もそう思うんだよね。
連番であってもなくてもいいけど、社員コードが社員の識別に役立てないとでも思ってんのか

[105 NAME IS NULL 2017/12/22(金) 12:45:16.02 ID:KAIeoRcz]

おいおい>>101と>>102は勘違いバカやぞw

[106 NAME IS NULL 2017/12/22(金) 14:56:17.28 ID:???]

>>105
さっさと、PKにハッシュ値を設定すべき理由を教えてくれや

[107 NAME IS NULL 2017/12/22(金) 18:50:39.54 ID:???]

>>101,104
要件による前提をかってに決めないで話してくれ

[108 NAME IS NULL 2017/12/22(金) 19:45:03.18 ID:KAIeoRcz]

>>106
さすが勘違いバカやなwお前には一体何が見えとるんやw

[109 NAME IS NULL 2017/12/22(金) 20:36:34.50 ID:???]

>>107
この要件は

名簿みたいなデータではPKを何にしたら良いでしょうか？

これ以外質問者からは提示されていない。
ウスラバカのお前こそ勝手に決めつけんな

[110 NAME IS NULL 2017/12/22(金) 21:19:47.34 ID:???]

>>103
重要なのはA=1,B=2なのかA=2,B=1なのか特定できてるってこと。
そうじゃない単なるユニークなだけのキーを振っても意味ない。

[111 NAME IS NULL 2017/12/22(金) 22:01:01.41 ID:KAIeoRcz]

>>110
おまえキチガイのふりしたいみたいやけんどわざとらしすぎていまいち萌えんのうw

[112 NAME IS NULL 2017/12/22(金) 22:24:18.98 ID:???]

なんか変なのが居ついてるな。

[113 NAME IS NULL 2017/12/22(金) 22:43:39.26 ID:???]

>>110
すまん、やはりよく分からない
特定できることにどのようなメリットがあるの？

[114 NAME IS NULL 2017/12/22(金) 23:30:49.60 ID:???]

>>108

>>36
が見えてんな

[115 NAME IS NULL 2017/12/22(金) 23:34:05.23 ID:???]

でも、もういいよ。消えてくれ。

わかったよ。ハッシュでPK最高ー！

[116 NAME IS NULL 2017/12/22(金) 23:53:46.12 ID:KAIeoRcz]

>>114
おまえなあwエセ関西弁使う奴が全部俺やと勘違いしとるやろw
さすが勘違いキングやなwww
てかお前完全に名前を主キーにして大目玉くらうタイプやなw
どんな腐った脳ミソしとったらハッシュを知らんお前をバカにしとる俺と
ハッシュを知らん発言の>>36が同一人物に見えんねんwww

[117 NAME IS NULL 2017/12/23(土) 00:05:28.58 ID:???]

>>116
へーっ。まじっすか。まじはんぱねーっす。

自分、すげー尊敬しちゃうんで、何に噛み付いてんのかまじ教えてほしいっす。

[118 NAME IS NULL 2017/12/23(土) 08:01:51.82 ID:???]

>>113
特定できるとメリットがあるというより、AなのかBなのか判別できないデータじゃ意味ないだろうと。
ユニークキーが存在しない状態と変わらんじゃん。

[119 NAME IS NULL 2017/12/23(土) 11:03:50.26 ID:???]

たとえば山田太郎さんが二人いて
山田太郎Aと山田太郎Bを区別しないといけないなら
そのためのカラムを持つべき
そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
単なるユニークなだけのキーを振っておけばいい

今ここで連番を主キーにしろって主張は自然キーの候補がないならって前提だぞ

そもそも主キーが要らないだろって話は別の議論な

[120 NAME IS NULL 2017/12/23(土) 12:25:57.35 ID:V+00B+qt]

フリだけかと思ったらガチキチっぽいやんコイツw

[121 NAME IS NULL 2017/12/23(土) 12:47:20.20 ID:???]

>>120
へーっまじっすか。まじはんぱねーっす。早く何に噛み付いてるか教えてくださいよ。

[122 NAME IS NULL 2017/12/23(土) 15:22:28.35 ID:???]

とりあえずWikipediaの主キーの項を
100回読んできたら？
あとデータベーススペシャリストに合格するくらい勉強したら、良いと思うよ

[123 NAME IS NULL 2017/12/25(月) 21:50:56.03 ID:???]

>>119
> 山田太郎Aと山田太郎Bを区別しないといけないなら
> そのためのカラムを持つべき

横からだが、それがサロゲートキーだろ

[124 NAME IS NULL 2017/12/26(火) 02:36:23.97 ID:???]

>>123
サロゲートじゃなくて、自然キーで区別できるようなカラムが必要だろって事だろ

[125 NAME IS NULL 2017/12/26(火) 07:14:12.54 ID:???]

>>123
むしろサロゲートキーは
> そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
> 単なるユニークなだけのキーを振っておけばいい
の方だろ

[126 NAME IS NULL 2017/12/26(火) 08:25:45.48 ID:???]

>>124,125
なるほど住所や何かで複合主キーにしろという事か
読解力がなくて悪かった

それでも不便な自然キーを優先させようとは理由がない限り思わんが

[127 NAME IS NULL 2017/12/26(火) 11:22:36.49 ID:???]

複合PKが正解？

[128 NAME IS NULL 2017/12/26(火) 12:09:06.71 ID:???]

住所はダメよ
同じ住所の可能性はゼロじゃないから

[129 NAME IS NULL 2017/12/26(火) 12:36:20.97 ID:???]

だから名寄せは難しいと

[130 NAME IS NULL 2017/12/26(火) 12:59:30.71 ID:???]

>>127
要件による
てか、何と何の複合でやろうとしてるのかすらわからんのに正解かどうかきかれてもな

[131 NAME IS NULL 2017/12/26(火) 13:00:41.95 ID:???]

>>128
そもそも住所は引っ越しとか町村合併で結構頻繁に変わるし

[132 NAME IS NULL 2017/12/26(火) 17:44:38.01 ID:???]

ORMの都合とかで、すべての主キーを単独の連番にってのはみたことあるな

[133 NAME IS NULL 2017/12/26(火) 21:57:54.33 ID:???]

>>127
複合キーでできるならそれでいいが、ハンドリングしにくいならそのサロゲートでもいい。
ただし複合キーでもユニークに特定できないものはサロゲートにしたところでやっぱりダメ。

[134 NAME IS NULL 2017/12/26(火) 22:43:04.71 ID:???]

>>130
氏名 住所 年齢
くらいで十分じゃあないの？

[135 NAME IS NULL 2017/12/26(火) 22:58:10.93 ID:???]

>>134
生年月日ならまだしも年齢とか変わっていくものをPKの一部にするとか変わってるな

[136 NAME IS NULL 2017/12/26(火) 23:03:51.55 ID:???]

いいじゃん毎年発生するデータなら。健康診断結果テーブルとか。

[137 NAME IS NULL 2017/12/26(火) 23:17:18.41 ID:???]

それぞれの誕生日に更新しないと

[138 NAME IS NULL 2017/12/27(水) 08:04:26.05 ID:???]

>>136
Aさんのここ５年間の情報頂戴って言われたらどうするつもりなんだ？ w

[139 NAME IS NULL 2017/12/27(水) 08:12:27.79 ID:???]

やりたいこと次第で「できます」か「できません」のどっちかでしょ？

「Aさんは今何歳？」
「今年は西暦何年？」
「今年は昭和何年？」

[140 NAME IS NULL 2017/12/27(水) 10:25:59.08 ID:???]

お前等の自然キーにかける情熱はどこから来るんだ

[141 NAME IS NULL 2017/12/27(水) 12:19:03.35 ID:5EZatHLU]

情熱てw単なる無理解やんけw

[142 NAME IS NULL 2017/12/27(水) 12:46:24.97 ID:???]

>>134
年齢を生年月日にするにしても
同姓同名の誕生日も同じ人が
ルームシェアで同じ家に住んでる可能性がある以上
十分とはいえない

[143 NAME IS NULL 2017/12/27(水) 14:18:50.57 ID:???]

同姓同名、同じ誕生日で同じ場所に住む人が2人居ても良いと思うし、
そういう風にDBに入るなら、間違いではないし誰も困らない

[144 NAME IS NULL 2017/12/27(水) 14:26:47.16 ID:???]

そもそもの>>33の名簿という要件を満たすのそれ

[145 NAME IS NULL 2017/12/27(水) 14:48:03.83 ID:???]

まだ続いてんだ、これ。
>>33すら放棄してんのに
お前らヒマなんやな w

[146 NAME IS NULL 2017/12/27(水) 14:55:09.55 ID:???]

提示されていない条件を仮定しても意味が無いと思うけど

[147 NAME IS NULL 2017/12/27(水) 19:19:41.67 ID:lvRR+7xm]

氏名も住所も年齢もすべて値が変化するものだと気づかない時点でダメだな。

[148 NAME IS NULL 2017/12/27(水) 21:05:50.80 ID:???]

この世に変化しないものなんかないんだから主キーだって変化すればいいじゃない

[149 NAME IS NULL 2017/12/27(水) 21:22:32.89 ID:???]

「昨日？そんな昔の事は忘れた。
明日？そんな先の事は分らない」

[150 NAME IS NULL 2017/12/27(水) 21:23:22.17 ID:???]

>>146
それな
なのに>>101が連番ではダメと難癖つけたから脱線しただけだよ

[151 NAME IS NULL 2017/12/27(水) 22:01:00.99 ID:???]

「連番付けとけばいい」「連番じゃダメ」
どっちが一方かだけが提示されていない条件を仮定したかなんて決められるもんかねぇ。

[152 NAME IS NULL 2017/12/27(水) 22:20:42.71 ID:???]

「連番じゃなきゃダメ」はどこいった？
唯一の条件を問わない正解なのに

[153 NAME IS NULL 2017/12/28(木) 17:05:27.38 ID:???]

>>146
回答するに当たって条件があるなら示しとかないとな

>>147
>>101は自然キー（候補キー）の必要性の問題を連番が問題だと勘違いしてるからな

>>152
>「連番じゃなきゃダメ」
そもそもそんな主張がどこにあった？

[154 NAME IS NULL 2017/12/28(木) 17:17:30.46 ID:???]

それは「唯一の条件を問わない正解」なんて言っている時点で触っちゃダメな人。

[155 NAME IS NULL 2017/12/29(金) 11:03:53.55 ID:dtNZwIie]

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

NULCDBFZ4S

[156 NAME IS NULL 2017/12/31(日) 10:46:46.28 ID:???]

DB勉強中です。
Primary Keyがないテーブルを使うと何か問題が起こりますか？

[157 NAME IS NULL 2017/12/31(日) 18:11:01.37 ID:rWX012Ww]

テーブルが問題を起こすのではない
おまえが問題を起こすのだ

[158 NAME IS NULL 2017/12/31(日) 18:32:52.59 ID:???]

例えば同姓同名の人がいたとして
その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない（＝人間）
全部書き換えようとする（＝DB）
こんなことが起こる

普通は一意性を確保するために、
社員IDやら学生IDやらマイナンバーやら
他と重ならないキー情報を用意して、
それをPKにしている。

[159 NAME IS NULL 2017/12/31(日) 18:54:16.62 ID:XZEULNad]

>>158
そういうのは履歴を取る設計にするのが普通なんだよ。

[160 NAME IS NULL 2017/12/31(日) 19:11:39.10 ID:???]

マスターは最新の状態で良いと思う
そんなに頻繁に変えるとは思わないし
履歴は履歴レコードで残せば

[161 NAME IS NULL 2017/12/31(日) 20:03:47.84 ID:???]

>>159
お前は何を言ってるんだ？

[162 NAME IS NULL 2017/12/31(日) 20:47:09.37 ID:rWX012Ww]

>>161
あくまで俺の予想だけど
そういうのは履歴を取る設計にするのが普通なんだよ。
って言ってるんだと思う

[163 NAME IS NULL 2017/12/31(日) 21:23:49.22 ID:???]

>履歴を取る設計にするのが普通

すっげーー含蓄のある台詞でした
来年はこれを使おう

[164 NAME IS NULL 2017/12/31(日) 21:28:58.37 ID:???]

>>162
>>158からそれが読み取れるとしたらよほど天才か知ったかのアホとしか思えんが w

[165 NAME IS NULL 2017/12/31(日) 21:44:37.10 ID:rWX012Ww]

>>164
勘違いクンはお口にチャックやでえwwww
おまえほんまにアホやなあwww

[166 NAME IS NULL 2017/12/31(日) 21:49:45.03 ID:???]

またこのパターンかよ...
具体的になにも指摘できないなら絡んでこなきゃいいのに w

[167 NAME IS NULL 2017/12/31(日) 21:57:51.30 ID:rWX012Ww]

>>166
絡んできたのお前やろがwww
脳ミソおかあちゃんのアナルに忘れてきたんかお前はwwwww

[168 NAME IS NULL 2017/12/31(日) 22:16:24.92 ID:???]

　　　　　　 ,､‐'''''''''ヽ､
　　　　　/:::::;;-‐-､:::ヽ 　　　　　　　　　　　 _,,,,,,,_
　 　　　 l::::::l　　_,,､-‐"iiiiiilllllllllllliiiiii､__ゞ:::::::::::｀ヽ,
　　　　　ヽ::｀／: :::..: iiiiiilllll||llllliiiiii: : : : ヽｲ~`ヽ:::::::i
. 　　　　　／;,..-;;;;;;;;;,,,,, : l|l: : : : : : : : : : : : : ＼　ﾉ:::::}
　　 　　 /: /: : ""　　""::::.....　;;/´: ｀ヽ : : : : : :ヽ:::ノ
.　　　　 !: : : .,,ぇzv､..,::;:　　:::: '^W;;a=z_: : : : : : :.!
　　　　 |: : : :.`'':::.:;;'`::.;　　 .:.:: 　-z-a:、,, : ::＜iiii|
　　　　 |: :　　　　　 ::.　　 ..:::::..　`.':::':::''^ ´ : : : :.|　　　みんないいこだから
　 　　　|:::.....　　　 .;''　　 '::::::;;i;..　　　　　 ..:;; : : :i　　　　けんかはやめよう
　　　　/:.ト;;;;;;;;.......'ヾ　::.::;iii;;ノ: :..　　　 ..;;,.イ: : :.i
　　 ￣|: ::';;;`':::;'　　 　,,、`,,'　　'::::;;,,,,;;;::'''::::＜iii/
.　　　／!.: ::.　 　ヽ.'',,,,::;;;v;;;;;:....　　　''''　　:-─/─
　　　　　ヽ　:.　.... ヾ;i;f",,i",_i.j;;;''"".. 　　,,:ヽ／
　　　　　　＼;:::　　 ヾ';;;;;;;;;;;::'''　...::'':: ,,::::::／＼
　　　　　 　 ｀''‐､､__ ￣￣　　　__,,,,､-‐"
.　　　　　 ／/:::::/ヽ￣￣￣￣ノ::::/＼
.　　　　／　/:::::/　 ｀￣￣￣/:::::/.　　＼

[169 NAME IS NULL 2018/01/01(月) 14:02:21.33 ID:KcPEsTvV]

運用の経験がないとデータの変化を追えないとたいへんなのがわからないのだろう。

[170 NAME IS NULL 2018/01/01(月) 15:50:18.06 ID:???]

データの変化を追えなかった、その経験談良かったらここに書いて貰えます？

[171 NAME IS NULL 2018/01/01(月) 20:56:53.06 ID:iMl2Nb4o]

>>170
人的データパッチミス、プログラムの変更、追加によるバグが変なデータを作り出す。

[172 NAME IS NULL 2018/01/01(月) 21:23:07.91 ID:???]

それはすごいシステムだ
そんな所利用したくない

[173 NAME IS NULL 2018/01/01(月) 21:26:43.18 ID:???]

>>169
ふーん。全てのデータをinsertとフラグ列のupdateとかで更新してくってこと？

[174 NAME IS NULL 2018/01/01(月) 22:30:38.24 ID:g9MeygUN]

大規模なシステムに関わったことがないと理解できないだろう

[175 NAME IS NULL 2018/01/01(月) 22:32:52.66 ID:g9MeygUN]

>>173
履歴レコードの話だよ。マスタデータでもトランザクションデータでも追跡できないのは運用で困る。何がどうなったのか他人に説明できないだろうが。

[176 NAME IS NULL 2018/01/01(月) 22:56:14.39 ID:QeD1IQaw]

トランザクションデータてそれ自体がログやからトランザクションなんやで
トランザクションの記録を更新すんなアホw

[177 NAME IS NULL 2018/01/01(月) 23:08:31.05 ID:g9MeygUN]

UPDATEと誤解してるのか

[178 NAME IS NULL 2018/01/01(月) 23:08:36.63 ID:???]

この人のシステム、怖くて触りたくない
よっぽど酷い人たちで開発してそう

[179 NAME IS NULL 2018/01/01(月) 23:10:08.13 ID:g9MeygUN]

世の中には常に数百人が関わってるシステムがあるんだよ。こういうシステムだと何が起こるかわからない。

[180 NAME IS NULL 2018/01/01(月) 23:41:53.03 ID:???]

>>156
履歴を記録しろと言い出す謎の勢力が襲い掛かってくる

[181 NAME IS NULL 2018/01/01(月) 23:46:18.18 ID:???]

履歴が一種のイベントとして成立しているなら記録すべきだよね
（例えば売上とか）
そうじゃないなら必要性が理解できない

[182 NAME IS NULL 2018/01/02(火) 00:05:50.83 ID:???]

テロリスト集団が巣くっているシステム？

[183 NAME IS NULL 2018/01/02(火) 00:21:32.94 ID:???]

ここ設計スレだし
履歴が必要なら履歴とるように設計すればいい

履歴とるように設計されてないから苦労したとかならしらんから
運用の話は別スレでやってくれ

[184 NAME IS NULL 2018/01/02(火) 00:28:00.40 ID:???]

トランザクションって言葉のイメージする範囲が広すぎてかみ合ってないところがあるな

単にマスタじゃないデータという意味合いでトランザクションって言ってる場合があるけど
この場合は当然そのテーブルが更新されたりする

もっと狭い意味でトランザクションって言ってるなら、トランザクションなんだから追加しかありえないだろ
それを更新するとかありえないって設計もある

[185 NAME IS NULL 2018/01/02(火) 07:23:53.00 ID:???]

まあ履歴が必要なシステムもあるんだろうけど>>158からいきなり履歴とか数百人が関わるシステムとか言い出してて笑える

[186 NAME IS NULL 2018/01/08(月) 07:44:30.25 ID:???]

業務的な必要とＳＱＬの仕様ってだいぶ乖離してるよな

ＤＤＬは基本１件ずつしか触れないようにしといてほしかった
手動で操作するのこわい

[187 NAME IS NULL 2018/01/08(月) 10:32:22.05 ID:???]

DMLじゃなくてDDL?
業務でどんなSQLを実行してるんだ？

まあDMLにしても1件ずつとかありえんけどな
SQLは手続き型じゃないんだよ

[188 NAME IS NULL 2018/01/24(水) 13:49:08.82 ID:8ow/svL2]

運用中のテーブルにカラムを追加する場合、どこに追加しますか？
末尾に追加しますか？それともデータ型やカラム名が合う場所に追加しますか？


くだ質ですが、気になるので教えてください。

[189 NAME IS NULL 2018/01/24(水) 14:29:33.12 ID:???]

末尾で問題があるのかって話だよ

[190 NAME IS NULL 2018/01/24(水) 15:20:39.28 ID:8ow/svL2]

>>189
問題はありません。
ですが、DB設計的に揃えるのが通常かな？と思いまして

[191 NAME IS NULL 2018/01/24(水) 17:51:33.77 ID:Hghj+DlT]

>>190
そもそも間に挿入できると思っているのか？

列順が変わることを想定していないプログラムへの影響、列順が違うのだけなのに運用を止める、データの移行のミス等、面倒なことばかりで普通はやらない。

[192 NAME IS NULL 2018/01/24(水) 19:47:51.39 ID:???]

>列順が変わることを想定していないプログラムへの影響

さすがにそこまでは面倒見きれんw

[193 NAME IS NULL 2018/01/24(水) 20:08:03.01 ID:???]

本来のリレーショナルデータベースなら, 列の順序はないのでは？
実装上で問題があるケースってあるのかな？

[194 NAME IS NULL 2018/01/24(水) 20:09:48.86 ID:???]

select * を使用禁止にする

[195 NAME IS NULL 2018/01/24(水) 20:38:49.43 ID:ibathY67]

【30歳で自殺】　スピードスケート代表　≪ほら死んだ≫　マイトＬーヤ「競争は殺人」　【五輪は犯罪】
http://rosie.5ch.net/test/read.cgi/liveplus/1516779817/l50

[196 NAME IS NULL 2018/01/25(木) 16:14:20.92 ID:???]

たとえばカラム一覧が
id,name,address,telephone,comment,date

だとする。そして「携帯電話」を追加したい。
こういった要件の場合、
id,name,address,tel,mobilephone,comment,date

ってしたくならないか？
id,name,address,telephone,comment,date,mobilephone

だとなんか納まりが悪いじゃん

[197 NAME IS NULL 2018/01/25(木) 16:16:11.62 ID:???]

修正。2番めに書いたのが無駄に削ってしまった。
id,name,address,telephone,mobilephone,comment,date

[198 NAME IS NULL 2018/01/25(木) 16:22:13.38 ID:???]

それは趣味の話であって、設計の話ではない

[199 NAME IS NULL 2018/01/25(木) 17:12:08.82 ID:???]

>>196
言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない

[200 NAME IS NULL 2018/01/25(木) 17:14:48.52 ID:???]

>>198-199
いやだから、気になりませんか？って話です。
本質とかルールがどうこうではなく、心情的な面で。

[201 NAME IS NULL 2018/01/25(木) 17:22:02.78 ID:???]

気になるもクソもRDBってのは「集合」を扱うもんなの
そして集合には順序なんて概念はないの

[202 NAME IS NULL 2018/01/25(木) 17:23:25.83 ID:???]

>>199
もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ

[203 NAME IS NULL 2018/01/25(木) 17:25:46.44 ID:???]

じゃ、テーブル設計書作ってるときとかphpMyAdminを利用してるときとかなんでも良いです。
順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか？

単に気持ちの問題ならどうでもよくても、仕様書にした場合、
順序がバラバラだとミスや勘違いの原因になりやすいのではないでしょうか？

[204 NAME IS NULL 2018/01/25(木) 17:30:24.66 ID:???]

>>203
気にはなるけどリレーショナルデータベースとはそうしたもんだ

仕様とはまったく別の話
ある順序通りに列を並べたいというのが仕様にあればアプリ側で対応すべき話であって
その順序をDBに持ち込むことがおかしい

[205 NAME IS NULL 2018/01/25(木) 17:32:15.39 ID:???]

>>204
つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone

で良いということですか？
これは順序も何も考えて無くて、単に末尾に追加しているだけです。

[206 NAME IS NULL 2018/01/25(木) 17:38:50.08 ID:???]

>>205
何度も言っているように、DBはそれで良い
というか、そこで順序にこだわることがおかしい
ユーザ側に見せる時には、プログラミング言語(JavaやC#やPHPでもなんでも)で調整すべき

[207 NAME IS NULL 2018/01/25(木) 17:39:52.94 ID:???]

205はリレーショナルモデルの勉強をした方が良いのでは

[208 NAME IS NULL 2018/01/25(木) 18:03:00.90 ID:???]

エクセルに切り替えれば解決

[209 NAME IS NULL 2018/01/25(木) 18:05:52.91 ID:???]

順序にこだわるのは、>>203にも書いたとおり、
仕様書なり設計書なりを見た人物（自分含む）が
誤認しないか？正しく伝わるか？と思ったからです。

過去にカラム追加が必要だと思ってたら、既にあったということがありました。
正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
とかく順序を意識して行いと、そういった不具合や誤認が生まれます。

リレーショナルデータベースとしては何が正しいか・正しくないかではなく、
扱うのは人間です。人間にわかりやすいのが一番だと思っています。
その上で出た疑問です。

[210 NAME IS NULL 2018/01/25(木) 18:08:44.34 ID:???]

たとえばMySQL「AFTER」というコードが有るのも、「指定位置に追加したい」
という需要があったからこそ用意されたのではないでしょうか？
そうでなければ末尾でも良いわけです。

[211 NAME IS NULL 2018/01/25(木) 18:12:05.73 ID:???]

何のためにほとんどのアプリでUIが別途あると思っとる
そういう整形はフロントエンドの役目

[212 NAME IS NULL 2018/01/25(木) 18:13:18.10 ID:???]

>>209
まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている？
(そんなはずはない、と思いたい)

>カラム追加が必要だと思ってたら、既にあったということがありました
というのは、単にモデリングの欠陥を言っているだけで、

>正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
これもよくあるアンチパターンで、1テーブル100カラムというのはほとんどが設計ミス

>人間にわかりやすいのが一番だと思っています
とか言い訳しているけど、単なる知識不足にすぎないのでは

[213 NAME IS NULL 2018/01/25(木) 18:19:21.67 ID:???]

teratailを見ると以下のように回答している人がいました。

「カラム位置のパフォーマンスへの影響ですが、一般的にRDBMSは可変長カラムを後ろに持っていった方が性能は良いです。可変長カラムより後ろのカラムに対しては、実際のデータ長を見て毎回オフセットを計算する必要があるためです。」

これを読み解くと、カラム位置って大事じゃないんですかね？
この回答者が間違っていると言われればそれまでですが。

[214 NAME IS NULL 2018/01/25(木) 18:26:41.60 ID:???]

>>213 DBの実装に依存する
これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ

[215 NAME IS NULL 2018/01/25(木) 18:41:36.73 ID:???]

どうしてもやりたきゃ
別テーブル作ってそこにコピーしてリネームすれば

[216 NAME IS NULL 2018/01/25(木) 18:54:38.23 ID:???]

それこそ無駄じゃないですか？

MySQLに順序変更に関するコマンドがある以上、
私の質問ってそんな的外れじゃないと思うんですけどね
「DBに順序という概念はない」っていう意味はわかりますけども。

[217 NAME IS NULL 2018/01/25(木) 19:13:05.84 ID:???]

DBに依存する処理だけど、やりたければやれば良いのだと思うよ
>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの？

[218 NAME IS NULL 2018/01/25(木) 19:36:37.81 ID:???]

まあしかし、心情的には理解できなくもない
最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる

ＤＢＭＳ的にはカラムは後ろにしか追加できない場合がほとんどだろうけど
ＧＵＩ系の管理ツールだとテーブル作り直して間に追加したかのごとくしてくれる物もあるぞ

[219 NAME IS NULL 2018/01/25(木) 19:37:01.16 ID:Kd6btbkD]

>>216
また馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw

×：「DBに順序という概念はない」
○：「関係モデルに順序という概念はない」

RDBMSの標準SQLでは定義された列の順番が存在する

よってお前の質問は全く的外れではないし
後から途中に列を挿入するという仕様変更も間違いではない

[220 NAME IS NULL 2018/01/25(木) 19:40:17.60 ID:???]

>>219
「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない？

[221 NAME IS NULL 2018/01/25(木) 19:52:49.07 ID:???]

>>220
少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。

[222 NAME IS NULL 2018/01/25(木) 19:55:46.45 ID:???]

返信が前後しますが、>>218さんみたいな意見があれば「やっぱり切なくなりますよね」
って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。

ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。

[223 NAME IS NULL 2018/01/25(木) 19:57:33.96 ID:???]

>>221
>>216でそう言っているよね？ 正解は>>219の通りだけど

>>199 や >>201 や >>204 も, みんな同じことを言っていると思う

[224 NAME IS NULL 2018/01/26(金) 02:01:50.61 ID:???]

>>222
MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて

[225 NAME IS NULL 2018/01/26(金) 02:15:25.24 ID:???]

カラム数が100近くになるというのは、そこからしてメンテ困難な状態でしょう
順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う

[226 NAME IS NULL 2018/01/26(金) 02:18:38.09 ID:???]

>>222
カラムの順番が重要視される会社で開発しているとしよう
同僚のコードはテストを通っていたが、マージはリジェクトされてしまった
あなたが先にマージしたコードのせいで、カラムの位置が不適切になったためだ
同僚はコードを修正する事より、規約を考えたあなたを殴る事を優先するだろう

[227 NAME IS NULL 2018/01/26(金) 02:35:15.34 ID:???]

>>218
心情的にはこれに同意だな

実務的な話をするなら、工程による。設計中なら、気の済むようにしたらいいけど、運用後の仕様変更だと、間に挟む為だけにテーブル作り直すとは客に説明できん..

MySQLは使ったことないけど、便利な機能があるんだな

[228 NAME IS NULL 2018/01/26(金) 12:46:04.91 ID:pxozcjcA]

>>222
後から追加した列だとわかるメリットもあるけどな。

[229 NAME IS NULL 2018/01/26(金) 12:47:20.40 ID:pxozcjcA]

>>227
それたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。

[230 NAME IS NULL 2018/01/26(金) 13:23:06.33 ID:???]

>>225
たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係（必ずJOINする）ならテーブルを分ける必要ないと思います。
それは正規かと違うような。

>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。

>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。

DBはMySQL、PostgreSQL、SQLiteぐらいしか知らないので
SQL ServerとかAccessとかはどうかわかりません。
だから私の質問が「こいつ何言ってんだ？」レベルに感じたのだと思います。

[231 NAME IS NULL 2018/01/26(金) 14:12:40.47 ID:???]

>>230
>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。

ここ詳しく

[232 NAME IS NULL 2018/01/26(金) 15:30:10.66 ID:???]

不動産のテーブルって言っても色々考えられるけどな
不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか

[233 NAME IS NULL 2018/01/26(金) 15:58:11.99 ID:???]

これも見た目だけの話になるんだろうけど、PKは先頭にないと違和感があるw

[234 NAME IS NULL 2018/01/26(金) 16:21:41.44 ID:???]

カラムの見た目の位置が気になるのはSELECT *した時だけでしょ？
あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん

あと業務要件で都度カラムが増えるのはさすがに設計がおかしい

[235 NAME IS NULL 2018/01/26(金) 16:28:53.58 ID:???]

わかる

[236 NAME IS NULL 2018/01/26(金) 20:41:14.34 ID:???]

実カラム名書くようなレベルの設計書が実テーブルのカラム順序と違うのはないわ

別にどんな分野でもいいけど、要件が変わってないのにカラム増えるのはさすがにおかしい
要件変更があれば当然増える事もあるだろう

[237 NAME IS NULL 2018/01/26(金) 20:45:05.81 ID:gcOPp+C3]

コーダーにとっては詳細設計が要件だという驚愕の真実w
てか物理設計て言葉くらい覚えようねw

[238 NAME IS NULL 2018/01/26(金) 21:53:37.57 ID:HiY2mRrM]

【株FX】　トレーダーが経済A級戦犯　≪朝生ゴミ、経済成長は宗教≫　世界2/3貧困を救済しろ　【NEET】
http://rosie.5ch.net/test/read.cgi/liveplus/1516959000/l50

[239 NAME IS NULL 2018/01/30(火) 17:06:10.21 ID:???]

やりすぎ防犯パトロール、特定人物を尾行監視　2009年3月19日19時7分配信 ツカサネット新聞
http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci

この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです

掻い摘んで説明すると

・創価学会は、町内会や老人会、ＰＴＡ、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
　９０年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた

・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
　防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった

・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
　創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
　防パトに尾行や監視、付き纏いをさせるようになった

・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
　不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった

・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
　私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
　防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた（防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官）
　※これに加えて防犯要員が同様のお願いをして回る

・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った

つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕

詳細は下記スレをご覧下さい
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/

[240 NAME IS NULL 2018/02/13(火) 16:59:54.49 ID:???]

>>230
1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは

意図的に非正規化した場合を除けば
カラム数が100を超えるようなテーブルは
本来別途管理すべきエンティティが埋もれてることが大半

[241 NAME IS NULL 2018/02/14(水) 03:12:25.25 ID:kUpzGWTP]

>>230
テーブルは意味のあるまとまりで作るのであって1：1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。

[242 NAME IS NULL 2018/02/14(水) 13:23:36.19 ID:???]

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

[243 NAME IS NULL 2018/02/15(木) 19:48:19.21 ID:L39WhMJw]

>>241
俺はおまえ、の日本語がわか、らなくなる

[244 NAME IS NULL 2018/02/20(火) 15:44:48.62 ID:???]

DBになったからといって、なにが違うの
順次編成、ISAM VSAM
DB

項目つけるだけでしょ
それと関連性

[245 NAME IS NULL 2018/02/20(火) 17:15:24.81 ID:???]

>>244
扱いやすさが桁違い

Comparison of DB2 and VSAM
http://search400.techtarget.com/tip/Why-DB2-is-better-than-VSAM

[246 NAME IS NULL 2018/02/20(火) 19:14:03.16 ID:???]

さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど

[247 NAME IS NULL 2018/02/21(水) 23:27:11.35 ID:???]

順次SAMは総なめしたり
Trに振りまら混ぜたりたいへんだから違うのはわかりますが

相当まーじとか冗談言っていた時代が懐かしいｗ

[248 NAME IS NULL 2018/02/21(水) 23:29:59.45 ID:???]

振り分け

[249 NAME IS NULL 2018/04/07(土) 17:29:50.05 ID:???]

経理システムは一つの仕分けテーブルに借方も貸方も詰め込んでフラグで分別してると思うけど
これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか？
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。

[250 NAME IS NULL 2018/04/07(土) 17:51:30.32 ID:???]

>>249
インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ

[251 NAME IS NULL 2018/04/07(土) 18:32:05.17 ID:???]

振替伝票1枚ごとに伝票番号振るとすると、
貸方か借方で違うテーブルに入るのはどうなのかな

[252 NAME IS NULL 2018/04/25(水) 14:23:33.67 ID:???]

マスタデータをJavaServletのアプリケーションスコープ変数に格納して
そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな？

[253 NAME IS NULL 2018/04/25(水) 17:25:06.73 ID:0kFJEAdZ]

>>252
コンピュータの仕組みを勉強してください。

[254 NAME IS NULL 2018/04/27(金) 19:37:20.55 ID:???]

>>253
未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね

[255 NAME IS NULL 2018/04/28(土) 06:14:34.24 ID:???]

え、逆にIT業界で省略しないとかあるの？
問題起きたことないんか？

[256 NAME IS NULL 2018/04/28(土) 10:38:35.05 ID:???]

>>255
おじいちゃんなの？
そもそも問題ってなに？

[257 NAME IS NULL 2018/04/28(土) 10:56:07.06 ID:???]

>>255
今は2018年ですよ

[258 NAME IS NULL 2018/04/28(土) 11:09:37.85 ID:???]

＞マスターデーターをJavaServletのアプリケーションースコープー変数に格納して

こう？

[259 NAME IS NULL 2018/04/28(土) 12:28:02.71 ID:???]

それ面白いの？

[260 NAME IS NULL 2018/04/28(土) 13:02:27.58 ID:???]

なあ、俺と知識をシェアーしようぜ！

[261 NAME IS NULL 2018/04/28(土) 13:29:20.62 ID:???]

わざわざ慣用に逆らう必要性説明できる？
もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな

[262 NAME IS NULL 2018/04/28(土) 14:03:16.12 ID:???]

別にコンピューターだろうがコンピュータだろうが気にしないけど慣用に従ってないじゃねーかとか言うような取引先だと国の指針やMSの方針変更も知らなくて大丈夫か？って不安になるわ w

http://www.mext.go.jp/b_menu/hakusho/nc/k19910628002/k19910628002.html
http://www.atmarkit.co.jp/news/200807/25/microsoft.html

[263 NAME IS NULL 2018/04/28(土) 14:11:16.33 ID:???]

>>262
これと個々のIT企業との関連は？

[264 NAME IS NULL 2018/04/28(土) 14:14:36.67 ID:???]

>>263
関係ないと思う

って言うような取引先なんて余計に不安になるだろ

[265 NAME IS NULL 2018/04/28(土) 14:15:31.78 ID:???]

>>264
なぜ？

[266 NAME IS NULL 2018/04/28(土) 14:24:05.30 ID:???]

最近思うんだけどみんな無知な奴を相手にし過ぎ。
みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。

常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。

[267 NAME IS NULL 2018/04/28(土) 14:32:49.38 ID:D5cEBG7Q]

無知には教えたくない()教えたがりのジレンマwいじらしいのおwww

[268 NAME IS NULL 2018/04/28(土) 14:32:59.28 ID:???]

>>266
常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ

[269 NAME IS NULL 2018/04/28(土) 16:27:41.26 ID:???]

長音符号はJIS的にはどっちでもいいはずだけど、
つける派にもつけない派にも妙なこだわりがある人が混じってる
文化庁のやつにも慣例に応じて省略可能とちゃんと書いてある
https://ging.co.jp/tips/57001/
http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/gairai/honbun06.html

[270 NAME IS NULL 2018/04/28(土) 16:36:14.55 ID:???]

知ってるか？ここ実はDB設計スレなんだぜ……

[271 NAME IS NULL 2018/04/28(土) 18:13:36.79 ID:???]

>>270

おおっっっそれは知らなかった！

[272 NAME IS NULL 2018/05/12(土) 07:21:49.70 ID:???]

共同ツール 1
https://seleck.cc/685

https://trello.com/
ボードのメニュー → Power-Upsから拡張可能 Slack DropBoxなど
Trello Chrome拡張機能　elegant
ttp://www.kikakulabo.com/service-eft/
trelloのオープンソースあり

共同ツール 2
https://www.google.com/intl/ja_jp/sheets/about/

共同ツール 3
https://slack.com/intl/ja-jp
https://www.dropbox.com/ja/
https://bitbucket.org/
https://ja.atlassian.com/software/sourcetree
https://sketchapp.com/extensions/plugins/
ttp://photoshopvip.net/103903

ttps://goodpatch.com/blog/sketch-plugins/

[273 NAME IS NULL 2018/05/25(金) 21:13:08.94 ID:Jccz1Fx2]

論理削除否定派のヤツが設計したシステム
取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。

[274 NAME IS NULL 2018/05/25(金) 21:15:53.50 ID:???]

削除データの扱い方、議論始めると荒れるんだけど

[275 NAME IS NULL 2018/05/25(金) 21:21:20.27 ID:Jccz1Fx2]

だけどその議論はいつも、ユーザーデータはみんなで使ってる共有資産であるという重要な視点が抜けてる。

[276 NAME IS NULL 2018/05/25(金) 21:24:01.69 ID:???]

君の個人情報もみんなで共有しよう

[277 NAME IS NULL 2018/05/25(金) 21:26:30.82 ID:Z93MyXqj]

そんなゴミはいらん
おまえ一人で共有しとけ

[278 NAME IS NULL 2018/05/25(金) 21:34:37.41 ID:???]

>>273
必要ないからdeleteしてるんでしょ？

[279 NAME IS NULL 2018/05/25(金) 21:54:12.06 ID:Jccz1Fx2]

>>278
それが必要だったから大トラブル

[280 NAME IS NULL 2018/05/25(金) 22:01:35.26 ID:Z93MyXqj]

つまり必要なデータを削除してしまったマヌケを論理削除の問題だと勘違いしてしまったもっとマヌケな>>273
というおはなしやな
少々笑えた

[281 NAME IS NULL 2018/05/25(金) 23:10:40.85 ID:???]

postgresで一切vacuumしないで運用したらいいんじゃね。time machineで任意の時点に戻れるぞ。

[282 NAME IS NULL 2018/05/25(金) 23:17:56.83 ID:TatbyLnb]

>>273
同じテーブルに残す方がわかりにくい。

[283 NAME IS NULL 2018/05/25(金) 23:20:27.43 ID:TatbyLnb]

>>281
実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。

[284 NAME IS NULL 2018/05/25(金) 23:25:58.38 ID:???]

具体例で考えた方が良いと思う
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している

[285 NAME IS NULL 2018/05/25(金) 23:47:38.82 ID:TatbyLnb]

>>284
言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。

単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。

[286 NAME IS NULL 2018/05/26(土) 00:50:49.12 ID:bRsNkwI2]

>>280
制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・

[287 NAME IS NULL 2018/05/26(土) 06:48:26.89 ID:???]

>>286
いやそれ削除フラグ云々以前のレベルやろ...

[288 NAME IS NULL 2018/05/26(土) 07:04:47.67 ID:n2n4g8U4]

延々と削除フラグの話を続けるんだね w

[289 NAME IS NULL 2018/05/26(土) 08:11:25.72 ID:bRsNkwI2]

>>287
削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる

[290 NAME IS NULL 2018/05/26(土) 08:32:39.78 ID:???]

制約も知らんアホは黙ってなよ... w

[291 NAME IS NULL 2018/05/26(土) 08:41:20.21 ID:???]

考慮漏れで問題を起こす可能性を考えたらなんでもありだろう。
削除フラグを見落として処理するコードが混入していて大混乱、とかね。

[292 NAME IS NULL 2018/05/26(土) 09:43:20.38 ID:bRsNkwI2]

>>291
それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。

[293 NAME IS NULL 2018/05/26(土) 10:04:04.12 ID:???]

面会記録は跡形もなく消します

[294 NAME IS NULL 2018/05/26(土) 19:39:28.98 ID:Pmk3UmpV]

レコードの削除をしても他のテーブルで保管するのが普通。

同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。

[295 NAME IS NULL 2018/05/26(土) 21:36:41.88 ID:???]

>>294
ソース

[296 NAME IS NULL 2018/05/26(土) 21:55:41.58 ID:Pmk3UmpV]

>>295
集合演算子を知らない。

[297 NAME IS NULL 2018/05/26(土) 22:16:19.76 ID:???]

>>296
何言ってんのこいつｗｗｗ

[298 NAME IS NULL 2018/05/26(土) 23:00:10.53 ID:???]

削除して良い要件と、削除方法は別の話なんだが
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話

これが理解できない奴が削除フラグの話をかきまわしてるだけ

[299 NAME IS NULL 2018/05/26(土) 23:11:28.11 ID:???]

継続して議論したいなら、コテハン付けるなりトリップ表示させなよ

[300 NAME IS NULL 2018/05/26(土) 23:21:53.44 ID:???]

削除フラグの話題にすらついてこれない人がどうしてこのスレにいるの？

[301 NAME IS NULL 2018/05/27(日) 10:01:04.63 ID:???]

ちゃんと削除フラグの話題で進めばいいけど>>286とか>>294みたいに頓珍漢なこと持ち出してグダグダになった過去が何回もあるからなぁ w

[302 NAME IS NULL 2018/05/27(日) 10:57:41.83 ID:0Fr+f65w]

>>301
おまえの事やぞw

[303 NAME IS NULL 2018/05/27(日) 11:14:49.09 ID:???]

>>302
本人降臨乙w

[304 NAME IS NULL 2018/05/27(日) 15:55:32.12 ID:8hLmukSL]

>>298
ステータスならフラグという持ち方は変。

[305 NAME IS NULL 2018/05/27(日) 15:57:15.03 ID:8hLmukSL]

ひとつのレコードにたくさんフラグ項目を持っていて、それを複雑な条件で判断するようなやつは死ねよ！

[306 NAME IS NULL 2018/05/27(日) 18:20:01.00 ID:???]

>>304
状態がオン／オフしかないようなものならフラグでおかしくない

>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑

[307 NAME IS NULL 2018/05/27(日) 21:18:51.26 ID:8hLmukSL]

>>306
>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。

[308 NAME IS NULL 2018/05/27(日) 21:20:22.92 ID:8hLmukSL]

>>306
おまえ、ジジイだろ？

そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。

[309 NAME IS NULL 2018/05/27(日) 21:25:12.75 ID:???]

削除フラグの泥沼スレという名前のスレを建ててそこでやれよ。

[310 NAME IS NULL 2018/05/27(日) 22:50:53.39 ID:Cl/1K8fE]

だいたい削除フラグなんていらないしな。

とにかく汎用機ジジイがリレーショナルデータベースを使うとこうなる。

またはExcelシートだと思っている素人が考えるとこうなる。

[311 NAME IS NULL 2018/05/28(月) 12:33:38.94 ID:JjIEU8hM]

何故突然エクセルwバカってこわいwww

[312 NAME IS NULL 2018/05/28(月) 21:04:44.29 ID:ZV4d+P4d]

>>311
リレーショナルデータベースをExcelと同じようなものと考えている人は多いぞ。

[313 NAME IS NULL 2018/05/28(月) 22:09:34.92 ID:HWd426F6]

>>305
一つの項目がステータスを表し、0〜9の値を持ち、2と7が削除扱いという設計を見たことがある。
2が取引先からのキャンセル、7がこちら都合のキャンセル。
嫌になった。

[314 NAME IS NULL 2018/05/31(木) 21:41:41.10 ID:???]

毎日の果物の価格を記録するデータベースを作りたいんですがどういうテーブルをつくったらいいですか？とりあえずitemsテーブルに果物の種類とidのカラムを作ります。
毎日の価格はどういうテーブルにしたらいいですか？

[315 NAME IS NULL 2018/05/31(木) 21:59:40.22 ID:???]

>>314
itemテーブルはそんなものだろうと思う。

毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う

[316 NAME IS NULL 2018/05/31(木) 22:14:59.09 ID:???]

>>315
価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。

[317 NAME IS NULL 2018/05/31(木) 22:20:51.12 ID:???]

その高値と安値の取得は、システム側でリアルタイムに行うのか、
それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね

[318 NAME IS NULL 2018/05/31(木) 22:23:34.53 ID:???]

更新は一日に一回だけです。

[319 NAME IS NULL 2018/05/31(木) 22:26:08.06 ID:???]

では、難しく考える必要はない
記録したい項目をテーブルに用意して終わりでしょう

[320 NAME IS NULL 2018/05/31(木) 23:07:07.03 ID:???]

例えばこんな感じかな
item_id
high_price
low_price
date

他に必要な項目があれば追加

[321 NAME IS NULL 2018/06/01(金) 04:08:11.91 ID:???]

>>320
プライマリキーは要らないんですか？
あとテーブル名ってどんな感じに付けますか？

[322 NAME IS NULL 2018/06/01(金) 04:10:01.84 ID:???]

必要かどうか分からないが、
どうしてもキーを付けるなら、
一意になりそうな日付かな？
テーブル名はお好きにどうぞ

[323 NAME IS NULL 2018/06/01(金) 11:25:16.22 ID:???]

果物取引実績(果物取引実績ID PK, 果物ID NN, 取引年月日 NN, 取引価格 NN)
チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)

select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日

[324 NAME IS NULL 2018/06/01(金) 14:29:47.30 ID:???]

>>323
そうだね、一意にするためには日付だけではなく
itemIDとセットにしないといけなかった

[325 NAME IS NULL 2018/06/01(金) 21:03:43.61 ID:???]

しかし>>323はindex付けただけでuniqueにはしていないという

[326 NAME IS NULL 2018/06/01(金) 21:04:55.21 ID:???]

販売実績だからユニークにしなくていい
同じ果物が何度も売れてもいい

[327 NAME IS NULL 2018/06/01(金) 21:48:46.17 ID:???]

要件ガン無視ﾜﾛﾀ

[328 NAME IS NULL 2018/06/01(金) 22:16:10.56 ID:???]

質問者を放置して持論展開はいつもの事

[329 NAME IS NULL 2018/06/01(金) 22:30:46.29 ID:???]

客は要件わかってないからな
要件そのまま聞くとまあ後でおかしくなるよ
この場合だと、その日の最後に入力するので取引実績をメモしておかないといけないんだけどめんどくさい、だとか
最大最小を計算するのめんどくさいからどうにかして、といった具合

[330 NAME IS NULL 2018/06/01(金) 23:15:49.45 ID:???]

入手できるデータが取引単位なのか日単位なのかなんて開発者が勝手に決められるわけないわな。

[331 NAME IS NULL 2018/06/02(土) 00:24:27.89 ID:gAkF9Xc4]

夢見る乙女もまんぐり返る妄想力やなw

[332 NAME IS NULL 2018/06/02(土) 00:54:08.86 ID:???]

どうしても日単位の最大最小でしかデータを入れられないなら
insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる

[333 NAME IS NULL 2018/06/02(土) 01:03:54.25 ID:???]

>>332
それだと、レコード一つだけ見たときにそｒが最高値か最安値か分からないだろう

[334 NAME IS NULL 2018/06/02(土) 07:10:37.22 ID:???]

こういう、なにがキーかわからないテーブルを設計してしまうID厨

[335 NAME IS NULL 2018/06/02(土) 07:36:22.88 ID:???]

>>332
どうやったらこんなアホな発想に至るんだろう...

[336 NAME IS NULL 2018/06/02(土) 07:39:23.98 ID:???]

>>333
>>323

[337 NAME IS NULL 2018/06/02(土) 07:44:01.56 ID:???]

>>334
どう見てもidがキーとわかる
果物idと日付をキーにする派閥もあるが
後で見た人は同じ日に同じものが売れたらどうなるんだ？と疑問を感じざるをえない

[338 NAME IS NULL 2018/06/02(土) 07:44:49.55 ID:???]

>>335
せめて反論の形にしないと敗北宣言と同じだよ？

[339 NAME IS NULL 2018/06/02(土) 07:48:00.32 ID:???]

データベースは1行に1つの事実を保存する
基本中の基本
最大値や最小値を1行に保存するということはこれに反する
統計値とは複数の事実から導き出されるものだからだ

[340 NAME IS NULL 2018/06/02(土) 07:49:44.49 ID:???]

>>338
え゛っ、マジで言ってるの？
値を参照するだけで>>323相当のSQL要るし、既に>>320みたいなまっとうな例もでてるのに w

[341 NAME IS NULL 2018/06/02(土) 07:53:31.65 ID:???]

>>339
基地害ｷﾀ━(ﾟ∀ﾟ)━!

[342 NAME IS NULL 2018/06/02(土) 07:55:18.85 ID:???]

>>340
統計値を参照するのに集計クエリが要るのは正常

>>320はまっとうじゃないよ
手作業で出した集計値を保存するという暗黙の手続きの上にかろうじて成立しているだけ
それと試しにこのテーブルにまっとうな名前をつけてみなさい

[343 NAME IS NULL 2018/06/02(土) 07:55:39.30 ID:???]

>>341
>>338

[344 NAME IS NULL 2018/06/02(土) 08:01:53.58 ID:???]

形式だけ正規化して満足してしまう人が多すぎる
彼らは形式しかみないから>>320のような歪なテーブルを受け入れてしまうがそれはダメだ
意味的にも正しく正規化すべきだ

[345 NAME IS NULL 2018/06/02(土) 08:05:20.94 ID:???]

そろそろ最初の質問者である>>314が出てきて要件について後出しでも何でも良いから（というか思ってることでもいいから）
はっきりさせるべきだな。

[346 NAME IS NULL 2018/06/02(土) 08:13:57.12 ID:???]

>>344
「正規化」って用語を「正しいテーブル設計」の代名詞みたいに使う人は相変わらずいるねぇ。
意味的に正しい正規化ってなんだろう。

[347 NAME IS NULL 2018/06/02(土) 08:19:27.67 ID:???]

>>342
要件を間違えてる
「高値/安値を求める」のではなく「求められた高値/安値を記録」するってこと ⇒ >>316
統計関係ない
テーブル名？
果物取引実績 とかでいいだろ w

[348 NAME IS NULL 2018/06/02(土) 08:21:54.17 ID:???]

休日の早朝から議論
おまいら健康的だな

[349 NAME IS NULL 2018/06/02(土) 08:22:47.57 ID:???]

>>346
第一正規化とか でググれ
１つの列に>>332みたいに違う意味の情報を入れるのは最悪の設計であることがわかると思う

[350 NAME IS NULL 2018/06/02(土) 08:32:59.12 ID:???]

>>346
例えばhoge(id, foo_1, foo_2, foo_3)のようなテーブルは形式的には正規形だが意味的にはおかしなことだ
古いエンジニアは平気でこういうテーブルを書いてしまう
集計値を格納するのも同様に形式しか見ずに設計した酷いテーブル構造だ

[351 NAME IS NULL 2018/06/02(土) 08:33:46.46 ID:???]

>>344が言っているのは>>320のことだが。
>>332は属性の意味が定まらんという、正規化以前の問題。

[352 NAME IS NULL 2018/06/02(土) 08:37:51.48 ID:???]

>>350
だから、形式的に正規形だったら正規形なんだよ。意味的におかしいというのは別の話。
それを「正しい正規形じゃない」と言うのが変なだけ。

[353 NAME IS NULL 2018/06/02(土) 08:54:32.67 ID:???]

>>347
記録するという行為の本質を見誤ってるな
Aという事実から直ちにBという事実が導き出される場合に
Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
Aを記録したからといってBを記録していないということにはならない

例えば歩く速度と歩いた時間を記録すれば歩いた距離も記録したも同然だな
それと同じでここの取引価格を記録するということは同時に最安値・最高値を記録することでもある
要件には全く反していないということだな

それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
まっとうなテーブルじゃないからまっとうな名前をつけられない

[354 NAME IS NULL 2018/06/02(土) 09:00:43.48 ID:???]

>>349
あくまで苦肉の策だということ
手作業で集計値を出すまでに個々のデータは必ずあるのだから、その個々のデータを入れるのが正しいあり方だ
しかし、どうしても最安値・最高値だけ保存してそれ以外は手作業で計算したいという奇特なユーザーのためにこういう手もないことはないと提示しただけ

ちなみにこの最高値・最安値のレコードだけを登録する回避策は厳密には間違いではない
なぜなら最安値の取引実績も最高値の取引実績も実際に存在する事実だからだ
間違いがあるとすれば他にも存在したはずの事実の記録を怠った運用の仕方にある

[355 NAME IS NULL 2018/06/02(土) 09:05:34.37 ID:???]

>>351
完璧に定まってる
いつ、何が、幾らで取引された、という事実を単純明快に表している
そして、それぞれの事実を識別するための最もシンプルな手段であるidを導入した
時刻はアイデンティティを示すキーの一部にはならない

[356 NAME IS NULL 2018/06/02(土) 09:07:03.57 ID:???]

速度計を持っているかどうかもわからんのに速度を入力しろとか。

[357 NAME IS NULL 2018/06/02(土) 09:07:23.66 ID:???]

>>352
それは派閥による
セルコは意味的な部分にも踏み込んで正規化としているね

[358 NAME IS NULL 2018/06/02(土) 09:11:43.30 ID:???]

>>356
くだらないレスはやめよう
歩いた距離と時間を記録すれば速度を記録したようなものだ
これで速度計は不要になったね
次はなんだ？時計がないってか？
付き合いきれん

[359 NAME IS NULL 2018/06/02(土) 09:12:48.97 ID:???]

>>353
> Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
だから中途半端な>>332はバカだって言う話な

> それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
> まっとうなテーブルじゃないからまっとうな名前をつけられない
>>332に言ってやれよ w

[360 NAME IS NULL 2018/06/02(土) 09:14:38.57 ID:???]

>>354
必要もないのに苦肉の策をとるバカ乙

[361 NAME IS NULL 2018/06/02(土) 09:27:03.02 ID:???]

言い返せなくなると罵倒する
ここらで決着かな

[362 NAME IS NULL 2018/06/02(土) 09:36:48.83 ID:???]

>>357
そう？
少なくとも「プログラマのためのSQL」じゃ形式的な正規形についてしか説明していないようだけど。

曰く
「正規形は、データベースで真のデータを破壊したり、偽のデータを作成したりすることがないように
しようというのが目的です。」

[363 NAME IS NULL 2018/06/02(土) 10:02:51.95 ID:???]

>>361
> 言い返せなくなると罵倒する
> ここらで決着かな
ひょっとして「必要もないのに」って言われてる意味がわかってないとか？
てか既に決着してるだろ w

[364 NAME IS NULL 2018/06/02(土) 19:53:26.96 ID:???]

意味の正規化って，数学的に言うとどういうこと?

[365 NAME IS NULL 2018/06/02(土) 20:25:43.70 ID:gAkF9Xc4]

バカの障り

[366 NAME IS NULL 2018/06/03(日) 17:50:56.72 ID:???]

回答ありがとうございました

>>345

>>320さんを参考に
テーブル作ってみたんですが

https://ideone.com/y6urpx

itemテーブルに同じ名前で重複してかきこまれてしまいます。

[367 NAME IS NULL 2018/06/03(日) 18:21:59.24 ID:???]

>>366
取引した日付と商品IDで重複しなくなるから、
その二つを使ってPrimary Keyを指定する。

PRIMARY KEY(`transaction_date`,`items_id`),

#varcharって書くと、サイズ1になるんだっけ？

[368 NAME IS NULL 2018/06/05(火) 01:29:12.15 ID:G6hVbWAV]

>>367
primary key にすれば自動的にunique制約されるんですね

[369 NAME IS NULL 2018/06/05(火) 13:48:16.07 ID:???]

そういうことになるね
それをキーにして何通りも取得できたら
おかしいことになるだろうし

[370 NAME IS NULL 2018/06/09(土) 06:56:35.90 ID:Icn+Lx+K]

皆さんがアンケートの答えを格納するテーブルを作るとしたら
未回答は、nullを想定しますか？0を想定しますか？
理由も教えてください！

[371 NAME IS NULL 2018/06/09(土) 07:24:58.49 ID:???]

It depends on the situation.

[372 NAME IS NULL 2018/06/09(土) 08:20:27.48 ID:???]

ナイーブに考えると、行なしだろ?

[373 NAME IS NULL 2018/06/09(土) 10:32:23.91 ID:???]

任意項目への未回答は空文字か、回答無し値（事前に決めた値）にする

[374 NAME IS NULL 2018/06/09(土) 17:01:40.73 ID:???]

要件次第だな
事前に決めた値で問題ないならそうするかもしれんが
まあnullだな

[375 NAME IS NULL 2018/06/09(土) 18:03:57.54 ID:hcbikbxQ]

>>370 は未回答という状態が存在しているとしているのなら、未回答という状態のレコードが存在しないとおかしい。

[376 NAME IS NULL 2018/06/09(土) 18:27:03.88 ID:Icn+Lx+K]

説明不足でした

Q1 性別 1.男 2.女
Q2 参加して 1.よかった 2.どちらとも 3.悪かった
Q3 よかったもの(複数回答可) 1.下着 2.靴 3.帽子
こんなアンケートの結果を
man int, ans1 int, ans2 int, ans3_1 bool, ans3_2 bool, ans3_3 bool
のカラムを持つテーブルに記録しようと思っています
manは1番から自動で割り振りのpkです
ans3_?はTRUE,FALSEで判断して未回答はFALSEと同義になります
問題はans1, ans2の未回答に0かnullのどちらを使うかです

[377 NAME IS NULL 2018/06/09(土) 18:44:19.45 ID:???]

性別に man って...

[378 NAME IS NULL 2018/06/09(土) 18:55:06.75 ID:???]

アンケートで、「答えたくない」って選択を用意しているときがあるな
未回答を避け、こういう選択肢を用意すると言うのも方法だと思う

[379 NAME IS NULL 2018/06/09(土) 18:56:49.19 ID:???]

適当に安価なオブジェクトストアを建ててそのまま保存かな
どうせしばらく経ったら丸ごと捨てるんだろ？

[380 NAME IS NULL 2018/08/11(土) 20:14:14.25 ID:HUdhIw+b]

>>332
カラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん
最高値と最安値はその都度、SQL文書いて取り出せばよくない？
MaxとMinをいちいち記録する必要ある？
複雑化するだけじゃん。

[381 NAME IS NULL 2018/08/11(土) 20:15:06.24 ID:???]

>>332
最大、最小しかデータ入れられないのか
糞レスしてごめん

[382 NAME IS NULL 2018/08/11(土) 20:48:43.90 ID:???]

糞レス以前に遅レスすぎる

[383 NAME IS NULL 2018/08/12(日) 01:13:04.21 ID:444bh0X0]

>>380
ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。

最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。

[384 NAME IS NULL 2018/08/18(土) 19:03:47.85 ID:???]

一日毎のレコードで最大最小が確定するんだったら
日替わりのタイミングで取得して別テーブルに登録したいね

[385 NAME IS NULL 2018/08/23(木) 20:53:10.04 ID:5PrJS+b6]

ここまで全部アプリケーション設計の話題

[386 NAME IS NULL 2018/08/26(日) 10:09:20.42 ID:???]

普通、設計って運用面も考えるんじゃないの？

[387 NAME IS NULL 2018/08/26(日) 10:12:25.44 ID:l1qaluN3]

>>386
実際は、運用や移行無視の機能要件しか満たさないような設計も多い。
テスト工程の終盤で気付いて火を噴く

[388 NAME IS NULL 2018/08/27(月) 03:53:49.73 ID:???]

DB設計に限れば運用ってバックアップ／リストアぐらいしかないんじゃね
統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる？

[389 NAME IS NULL 2018/08/27(月) 07:07:36.29 ID:???]

パッチ

[390 NAME IS NULL 2018/08/27(月) 22:01:12.24 ID:Ee+4ykO9]

>>388
データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。

[391 NAME IS NULL 2018/08/28(火) 06:28:49.33 ID:???]

DBAがいないと漏れがちなこと、ってのが趣旨なんでは
データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う

[392 NAME IS NULL 2018/08/30(木) 23:28:39.42 ID:YS+AC+kz]

既存のテーブルに後から10カラムほど追加するというのはありなのでしょうか？

最初は別のテーブルにしようと思ったのですが、
1対1の関係であるため、ひとつにまとめた方が良いのではないか？と悩んでいます。

[393 NAME IS NULL 2018/08/30(木) 23:32:31.99 ID:lHt449yM]

>>392
改修コスト見合いだが
将来にわたり1:1ならいいんじゃね

[394 NAME IS NULL 2018/08/30(木) 23:41:15.81 ID:???]

ありだと思います。よくやってました。

[395 NAME IS NULL 2018/08/30(木) 23:45:46.14 ID:YS+AC+kz]

>>393-394
ありがとうございます。分ける方法もよくあるんですね

[396 NAME IS NULL 2018/09/03(月) 03:03:59.17 ID:xugX4t13]

>>395
どちらかというと分けた方がいい。

あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。

カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。

コボラーさんや頭が古いひとはカラムを追加したがる。

[397 NAME IS NULL 2018/09/03(月) 06:44:35.34 ID:???]

>>396
まとまりに意味があるからテーブル分けろ？
他に理由ないならバカとしか思えない

[398 NAME IS NULL 2018/09/03(月) 07:49:30.05 ID:8k7Ekz6C]

ただスキルがないだけなのにバカ呼ばわりは少しかわいそうw

[399 NAME IS NULL 2018/09/03(月) 10:15:56.89 ID:???]

それぞれが巨象の一部にふれて、
象とはこういうものだと言い合っている絵を
思い浮かべる議論だな

[400 NAME IS NULL 2018/09/03(月) 20:46:20.70 ID:xugX4t13]

>>399
仏教徒か。仲間だな。

[401 NAME IS NULL 2018/09/04(火) 19:00:44.56 ID:PCCrVc8p]

>>396
コボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。

[402 NAME IS NULL 2018/09/04(火) 19:13:28.23 ID:NpqdKDu5]

>>401
つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。

[403 NAME IS NULL 2018/09/04(火) 20:02:08.75 ID:???]

>>401
JCLでレコード長の数字を弄らんといかんようになるからな w

[404 NAME IS NULL 2018/09/04(火) 21:09:30.08 ID:???]

それ以前にテープに格納されてるマスタのレコード長とか変えれんから

[405 NAME IS NULL 2018/09/05(水) 08:27:53.10 ID:1yHvak3l]

なんでCOBOLの話をしているのか？

[406 NAME IS NULL 2018/09/05(水) 12:14:38.49 ID:sxBfz2nK]

コボラーだもの

[407 NAME IS NULL 2018/09/05(水) 21:29:08.15 ID:???]

小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。

[408 NAME IS NULL 2018/09/05(水) 23:49:38.89 ID:w+IuU8zi]

ちうがくせいにいぢめられんのかコボラーてw

[409 NAME IS NULL 2018/09/06(木) 11:24:17.20 ID:???]

列追加は構わんけど処理速度への影響も含めて検討してほしい

[410 NAME IS NULL 2018/09/06(木) 14:27:57.81 ID:GycufIMP]

>>409
？

[411 NAME IS NULL 2018/09/06(木) 18:52:24.46 ID:???]

>>410
レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね

[412 NAME IS NULL 2018/09/06(木) 22:15:09.33 ID:???]

まさかレコード単位でIOかましてるとでも思ってるのか

[413 NAME IS NULL 2018/09/06(木) 23:46:24.34 ID:???]

いや
ただ計測したらそうなった

[414 NAME IS NULL 2018/09/07(金) 19:37:22.26 ID:KGOTOtzd]

>>411
それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか？

[415 NAME IS NULL 2018/09/07(金) 19:58:59.63 ID:KGOTOtzd]

カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。

レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。

[416 NAME IS NULL 2018/09/07(金) 20:01:04.05 ID:???]

分からないんだけど、
連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと？

[417 NAME IS NULL 2018/09/07(金) 21:15:09.98 ID:cf7Dw2jW]

昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ

[418 NAME IS NULL 2018/09/09(日) 09:06:55.49 ID:???]

>>414>>415
SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
（個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで）

この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
（もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる）

[419 NAME IS NULL 2018/09/09(日) 11:14:36.11 ID:???]

行ストアだからそんなもんでしょ

[420 NAME IS NULL 2018/09/09(日) 12:57:35.94 ID:???]

主キーはクラスタ化なのかとか、断片化してないのとか、ページ分割が起こってないのとか
まあ不定要素多すぎて何とも言えんけど

それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話

ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと

[421 NAME IS NULL 2018/09/10(月) 14:21:33.58 ID:???]

>>420
要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん

[422 NAME IS NULL 2018/10/06(土) 14:35:50.55 ID:Kml7Tt+s]

皆さんデータベースを作るやりがいってなんですか？

[423 NAME IS NULL 2018/10/06(土) 16:33:44.55 ID:i1VqU+gz]

・ニックネーム
・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄

これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。

[424 NAME IS NULL 2018/10/06(土) 18:20:10.06 ID:???]

>>422
趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか

[425 NAME IS NULL 2018/10/13(土) 19:44:09.60 ID:???]

https://imgur.com/FAF05na.jpg

[426 NAME IS NULL 2018/10/14(日) 20:23:24.26 ID:???]

　私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
（へいわ）は、勝ち取るものです。拡散も含め、お願い致します。

[427 NAME IS NULL 2018/10/14(日) 20:53:15.89 ID:XnVgDh+Y]

>>426
戦争反対！

[428 NAME IS NULL 2018/10/17(水) 23:43:26.92 ID:???]

イオンみたいな巨大小売で、個人客が買い物した商品なんかのDBってどう管理してるんでしょうか？

主キー　会員ID　購入商品　品数　日付
1　a01　チロルチョコ 10　2018/10/17
2　a01　牛乳 1　2018/10/17
3　a02　牛肉 1　2018/10/17
4　a02　ポカリ 2　2018/10/17

こんな感じでテーブルに購入された商品1つ1つ登録してたら、1日で日本全国で百万レコードとか行っちゃいますよね？
何かいい手があるんでしょうか？毎日テーブルを作ってるのかな？

[429 NAME IS NULL 2018/10/17(水) 23:52:23.40 ID:???]

>>428
何の為にDBに登録するのか、その目的次第だと思う

小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか

[430 NAME IS NULL 2018/10/18(木) 00:21:22.13 ID:tCAmet/Z]

>>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない

[431 NAME IS NULL 2018/10/18(木) 01:28:56.96 ID:NAGDWV1s]

>>429
取る取る、もっと細かく取るよ。

[432 NAME IS NULL 2018/10/18(木) 01:47:15.31 ID:???]

小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな

[433 NAME IS NULL 2018/10/18(木) 06:59:59.61 ID:???]

>>428
> 1日で日本全国で百万レコードとか行っちゃいますよね？
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
１億レコード超えたら本気出す

[434 NAME IS NULL 2018/10/18(木) 07:03:00.50 ID:???]

顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ

[435 NAME IS NULL 2018/10/18(木) 07:33:05.12 ID:???]

>>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの？テーブルを365個SQLに書かなきゃダメ？

[436 NAME IS NULL 2018/10/18(木) 16:22:23.06 ID:???]

本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ

[437 NAME IS NULL 2018/10/18(木) 23:03:46.70 ID:???]

パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ

[438 NAME IS NULL 2018/10/18(木) 23:29:31.96 ID:???]

ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん？
数億人が毎日見てるんだぜ？考えるとすごくね？しかも検索結果の抽出も早いしどうなってんだ

[439 NAME IS NULL 2018/10/19(金) 03:14:59.08 ID:???]

超並列とか言ってみる

[440 NAME IS NULL 2018/10/20(土) 17:50:10.77 ID:???]

厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる

[441 NAME IS NULL 2018/10/20(土) 17:51:48.84 ID:???]

やってみてくれ

[442 NAME IS NULL 2018/10/23(火) 20:01:35.00 ID:???]

つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか４２倍

[443 NAME IS NULL 2018/10/23(火) 22:33:49.87 ID:hntOGwbv]

0.1mmの42倍て4.2mmじゃね？それで月まで届くの？

[444 NAME IS NULL 2018/10/23(火) 22:45:12.23 ID:???]

いやそれはおかしい

[445 NAME IS NULL 2018/10/23(火) 22:45:58.51 ID:???]

0.1mm×2＾42

[446 NAME IS NULL 2018/10/24(水) 01:29:31.23 ID:???]

しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん

[447 NAME IS NULL 2018/10/24(水) 01:45:22.86 ID:???]

どういう折り方しても、無理

[448 NAME IS NULL 2018/10/25(木) 03:15:40.01 ID:???]

よってYouTubeの検索速度を再現する事は不可能である

[449 NAME IS NULL 2018/10/25(木) 09:51:00.34 ID:???]

YouTube を実際に使っているユーザーがいないんじゃ？

[450 NAME IS NULL 2018/12/13(木) 23:16:46.44 ID:Ht+aqMlR]

YouTube を仮に使ってるユーザーぐらいいるんじゃね？

[451 NAME IS NULL 2018/12/26(水) 10:07:27.12 ID:IDBXTEXd]

特殊な炭素素材で水を水素と酸素に分解　ゼビオＨＤのグループ企業、クロステクノロジーラボが開発

[452 NAME IS NULL 2019/03/20(水) 08:24:10.88 ID:???]

500項目超とかの巨大テーブルいい加減ヤメてほしい

[453 NAME IS NULL 2019/03/30(土) 17:46:10.62 ID:???]

>>452
DBMS何使ったらそうなんの？オラコー？

[454 NAME IS NULL 2019/03/30(土) 17:52:56.67 ID:klkn0vtv]

紙の業務の置き換えで
10明細x50の伝票！あと10年は変更ありません！
とかだとよくやる。官公庁だあとありがち。
正規化するといちいちJOIN書かないといかんし

[455 NAME IS NULL 2019/03/30(土) 19:41:39.53 ID:???]

>>452
見たのは確かOracle
項目多過ぎでSQLが実行できない

[456 NAME IS NULL 2019/03/30(土) 22:37:17.45 ID:???]

COBOLで書かれたような奴の移植ならよくある

[457 NAME IS NULL 2019/05/31(金) 20:09:56.83 ID:h9fg3gjJ]

主キーをサロゲートキー(serial)にするか、複合カラムの組み合わせでUNIQUE制約をつけて主キーっぽく使うかで悩んでいます。
問題なのが、このテーブルはレコードを削除した後、復活(再度、新規登録)させる必要が出てくる可能性があることです。
その場合、復活させた時に番号が変わるserialを主キーにするのは、ありえないですよね？

[458 NAME IS NULL 2019/05/31(金) 20:48:12.74 ID:???]

そのDBがserial値の明示的挿入を許して、それが滅多に起きないんならなくはないんじゃね

それ以前におれなら復活必要なら論理削除にしとくが

[459 NAME IS NULL 2019/05/31(金) 23:33:17.50 ID:???]

データレコード削除してもサロゲートキーのマスター残しておけば問題ないんでないの。

[460 NAME IS NULL 2019/06/04(火) 20:14:47.94 ID:???]

サロゲートキーのマスターとは？

ここで言ってるserialってのは、システム側で管理して勝手に数値入れてくれるものだと思うが

[461 NAME IS NULL 2019/06/04(火) 20:52:02.44 ID:???]

単なるserial;はふつうサロゲートキーとは言わんだろう。
>>457のように一意性を保証する複合主キーが存在したうえでその代理とするのがサロゲートキー。
んだから元の複合主キーとserialからなるのがマスターだしそれが自動採番されることは矛盾しない。

[462 NAME IS NULL 2019/06/04(火) 21:03:46.49 ID:???]

で、データレコード削除しても残るサロゲートキーのマスターって何？って話だが

自動採番（システム管理）される値をサロゲートキーにするって前提じゃないの？

[463 NAME IS NULL 2019/06/04(火) 21:33:06.85 ID:???]

だから複合主キーとサロゲートキーの対応表だよ。そう書いたつもりだったが。
>>457のようにデータ再投入時にサロゲートキーの値が変わるのを防ぎたいなら
そういうマスターを残しておけばいいという話。
採番が自動か手動かはこの際関係ない。

[464 NAME IS NULL 2019/06/05(水) 00:34:03.47 ID:???]

>>463
そういうマスターを残すには手動でそういうマスターを作らないとダメなわけで
前提を合わす気がないならちゃんとそういっとかないと議論にならん

[465 NAME IS NULL 2019/06/05(水) 00:38:31.46 ID:???]

serialを変えたくないってことは、
その様な使い方を別なところでしているんじゃないかな
ログとか履歴とか

[466 NAME IS NULL 2019/06/05(水) 08:10:00.40 ID:???]

>>464
既に何度も書いているが、そのマスターのサロゲートキーはserialで自動採番して全然問題ないんだが？

あるいは、もともとデータテーブルが1テーブルだったものをマスターテーブルと分離したことを言っているなら
そりゃ当たり前だ。そう提案したんだからな。

[467 NAME IS NULL 2019/06/26(水) 12:08:55.23 ID:???]

大阪市は2019年6月24日、6月7日から翌8日にかけて発生した基幹系システムの障害に
ついて、原因を特定したと明らかにした。米オラクル（Oracle）のデータベース（DB）ソフト
「Oracle Database」のバグが原因だった。

https://egg.5ch.net/test/read.cgi/bizplus/1561468154/

[468 NAME IS NULL 2019/06/26(水) 12:32:28.72 ID:???]

やっぱ脱Oracleだな
ろくに保守サポートされないんだから有料契約の意味がない

[469 NAME IS NULL 2019/06/26(水) 19:39:47.63 ID:???]

でも金で解決してくれるサポートがなけりゃ、問題がDBMS側にあることを
突き止めることすら自前でやらなきゃならんのだぜ。

[470 NAME IS NULL 2019/06/26(水) 19:52:43.63 ID:???]

突き止めることに意味がないからな

責任転嫁のための作業であって
復旧にはどのみち問い合わせじゃ間に合わん

[471 NAME IS NULL 2019/06/26(水) 20:14:47.85 ID:???]

原因がわからなきゃ対策のとりようもないだろう。
「たまたまエラーになったけど原因がわからないからまた起きたらゴメンね。」で済むような仕事ならいいが。

[472 NAME IS NULL 2019/06/27(木) 18:25:28.42 ID:???]

オラクルは、問題がDBMSにあることをつきとめるんじゃなくて、その問題をまず認めてもらうのにサポート窓口が必要なんだよ

あとは直ればラッキーぐらい

[473 NAME IS NULL 2019/07/14(日) 19:52:47.78 ID:???]

> 大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、
> 8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜む
> バグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。
> 米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。

https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/070200035/

[474 NAME IS NULL 2019/07/14(日) 20:10:01.55 ID:???]

Oracleに金払う意味あるぅ？

[475 NAME IS NULL 2019/07/15(月) 19:18:49.04 ID:???]

それゆえMySQLとかPostgreSQL移行が進んでる

[476 NAME IS NULL 2019/07/28(日) 18:04:07.13 ID:???]

https://i.imgur.com/l91swsP.jpg

[477 NAME IS NULL 2019/08/21(水) 20:28:50.39 ID:???]

デシジョンテーブルのつくりかたがわからん
値の組み合わせ全部入れるもんなの？

null値はすべての検索値にマッチとかルール決めて行数減らしたけど
わけわかめになった

[478 NAME IS NULL 2019/09/01(日) 05:17:00.26 ID:Kcb9iNar]

売上を管理するテーブルを設計したいんですが、
後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか？

※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。

[479 NAME IS NULL 2019/09/01(日) 06:36:54.70 ID:???]

>>478
その意味のない商品コードとやらで何をしたいんだ？
商品名と価格だけでいいだろ

[480 NAME IS NULL 2019/09/01(日) 09:57:23.82 ID:e+zeE2vd]

>>478
商品マスタに有効期間を作るのが定石かなあ
ついでに言うと当時の単価もマスタ側で
売り上げは数量かなあ
（集計用に金額持たせることはある）
あと消費税の扱いをどうするかとか考えておいたほうがいい

[481 NAME IS NULL 2019/09/01(日) 16:19:32.45 ID:???]

>>478
自分ならというか自分が作ったシステムの売上データは個数、単価、価格などを保持してる
マスタから参照するのはコードと商品名ぐらい
マスタのコードは別の商品に変わる可能性があるなら売上データと商品マスタを結合するキーは
商品コードでなく商品マスタのサロゲートキー

[482 NAME IS NULL 2019/09/01(日) 16:38:47.41 ID:???]

>同じ商品コードに別の商品が割り当てられる事も想定して

これがどういう状況を表しているのかはっきりさせないと設計も決められないだろ。
少なくとも「商品コード」で「商品」を特定できないことは読み取れるが、じゃあ
「商品コード」と「商品名」であれば特定できるのかそれともそうじゃないのか。
できるなら>>478のままでいいが、できないならばそれを特定できる情報を
追加しなければならない。

[483 NAME IS NULL 2019/09/01(日) 16:51:19.34 ID:???]

商品名や容量が変わるなんてのはよくあること

[484 NAME IS NULL 2019/09/01(日) 17:30:57.16 ID:???]

同じ商品コードを別の商品に割り当てるって言うんだから、ある商品の商品名を
変更するって話とは全然違うわな。

[485 NAME IS NULL 2019/09/01(日) 17:43:49.61 ID:???]

商品コードが一意にならないって理解しにくいんだが
商品コードを仕入れ先の企業が決めてくるって事？

[486 NAME IS NULL 2019/09/01(日) 17:54:03.12 ID:???]

おそらく現実の問題ではなくて、>>478が深く考えないで書いた脳内想定だと思う。

[487 NAME IS NULL 2019/09/02(月) 04:29:38.29 ID:???]

現実的に、商品コードが一意にならないような要求をする客はいるぞ

もし本当に
>売り上げに登録する商品は、商品コードと商品名と価格だけで管理する
のならば、全情報コピーでいいだろ
現実的にはそんな単純な管理条件にはならんけどな

[488 NAME IS NULL 2019/09/02(月) 12:28:21.25 ID:???]

>>487
> 現実的に、商品コードが一意にならないような要求をする客はいるぞ
そりゃいるだろうよ
だから外部とやり取りするためのコードと内部で処理するためのコードは別に持ったりする

[489 NAME IS NULL 2019/09/02(月) 15:56:14.03 ID:???]

横着して客が提示した項目だけでまかなおうとするからコケル

[490 NAME IS NULL 2019/09/20(金) 22:43:01.69 ID:isalmAv1]

>>467
ラックに限らずクラスタリングってもしもの時のバックアップとしては全く信用できない。
基本的に運が良ければダウン時間が短く済むかも程度で考えて、データのみ同期させる予備機もっとかないと。

[491 NAME IS NULL 2019/10/13(日) 18:20:24.07 ID:???]

カラムに日本語使わないほうがいい
でもPHPでカラムを見ながら弄りたい
PHPやらhtmlでいちいち書くのは面倒くさい
ってんで、カラムの名前の日本語対応データだけもったtable作る
ってのは変ですか？

[492 NAME IS NULL 2019/10/15(火) 01:36:43.91 ID:???]

日本語っていうか、論理名を物理名とは別に持って管理するのは珍しくない

[493 NAME IS NULL 2019/10/15(火) 16:59:26.48 ID:???]

>>492
ありがとうございます
論理名 物理名というのですね
参考になる文献が結構出てきて助かりました

[494 NAME IS NULL 2019/10/16(水) 07:52:35.26 ID:???]

多少長くなっても意味の通じるカラム名で管理した方が楽かな

[495 NAME IS NULL 2019/10/16(水) 19:46:46.29 ID:vHJKi6he]

>>493
項目名が頻繁に変わるという仕様が本当に必要なのか考えた方がいい。

[496 NAME IS NULL 2019/10/17(木) 01:46:16.06 ID:???]

どこから項目名が頻繁に変わるという仕様を導き出したんだ

[497 NAME IS NULL 2019/10/17(木) 06:45:02.27 ID:???]

まあ強いて言えばわざわざ
> カラムの名前の日本語対応データだけもったtable作る
ってところじゃね？

[498 NAME IS NULL 2019/10/17(木) 23:46:22.91 ID:/2joG6dP]

お腹がすいていませんか?
ウーバーイーツの利用者が初めての方は eats-5kqyfp のプロモーションコードを使うと、#Uber&#160;Eats の初回注文が ￥1,000 割引になります。https://t.co/Wxur8AeoEf 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)

[499 NAME IS NULL 2019/10/18(金) 04:25:29.95 ID:???]

PHPからデータを入力することを考えているのですが、初心者ゆえ取っ掛かりがわからなくて途方にくれています

例えば、
歴史的建造物のテーブルと
国のテーブルが有るとします

建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか？
この入力段階では建造物テーブルにリレーション？や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか？

[500 NAME IS NULL 2019/10/18(金) 09:22:20.96 ID:???]

考えなくて良い

[501 NAME IS NULL 2019/10/18(金) 19:29:58.26 ID:d6MIxLxf]

>>499
建造物情報と国情報が紐付いてないのに、なぜ「オートコンプリート」という言葉が出てくるのか？

[502 NAME IS NULL 2019/10/18(金) 21:21:09.59 ID:???]

キー入力するんじゃねえの？

[503 NAME IS NULL 2019/10/20(日) 20:29:56.45 ID:???]

つか、建物入力して、国を絞るのか？
法隆寺は日本にしかないだろうに

国を入力したら、建物のリストを候補にだすってんなら、国と建物の紐づけが必要

[504 NAME IS NULL 2019/10/20(日) 20:53:49.69 ID:???]

法隆寺のデータをこれから入力しようって時に紐付けデータが先に存在しているわけなかろう。

[505 NAME IS NULL 2019/10/20(日) 21:37:50.26 ID:???]

オートコンプリート用国候補のデータを"国"テーブルから取得して

[506 NAME IS NULL 2019/10/22(火) 21:34:40.81 ID:???]

すでに歴史的建造物のテーブル（にレコード）があるって前提ではないのか

[507 NAME IS NULL 2019/10/22(火) 21:43:02.01 ID:???]

＞オートコンプリートとは、ユーザーによるキーボード入力履歴を活用して、
＞入力操作の軽減を図る機能の一つである。

＞オートコンプリートに対応したソフトでは、ユーザーが入力したい言葉の
＞冒頭の文字を入れると、入力履歴の中から冒頭の文字が一致するものを
＞候補として一覧で表示する。候補は、文字を入力していくごとに絞り込まれ、
＞その一覧の中に入力したい言葉があれば、ユーザーは残りの文字を入力
＞することなく、一覧から選ぶだけで入力が完了する。

こういうことなんじゃ？

[508 NAME IS NULL 2019/10/22(火) 22:57:39.65 ID:???]

>>501
>>503
>>506

>建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい

[509 NAME IS NULL 2019/10/23(水) 09:25:30.42 ID:CtOyw4yf]

>>508
だからどうしてそんな変なことを言っているのか？

[510 NAME IS NULL 2019/10/23(水) 15:59:50.08 ID:???]

入力者の作業が簡単になるからじゃね？

[511 NAME IS NULL 2019/10/23(水) 19:36:46.50 ID:???]

>>509
おまえ読解力無さすぎだろう

[512 NAME IS NULL 2019/10/23(水) 19:45:44.83 ID:???]

変なことっていうのは違うな
誰でも考えつくことだし

[513 NAME IS NULL 2019/10/23(水) 20:18:26.30 ID:???]

>>499
・国名入力欄
・建造物名入力欄

があって、「国名入力欄に入力する際に国名をオートコンプリートしたい
（“に”って入力したら“日本”が候補にでてくる）」って認識でOk？

それとも「国名を入力したら建造物名入力欄の候補が絞り込まれる」ようにしたいってことを言ってる？

[514 NAME IS NULL 2019/10/23(水) 20:43:21.25 ID:???]

>国のテーブルからオートコンプリート
>オートコンプリート用国候補のデータ

こう書いてあるんだから普通わかるだろ。

[515 NAME IS NULL 2019/10/23(水) 22:00:30.83 ID:CtOyw4yf]

建造物と何ら関係なかったな

[516 NAME IS NULL 2019/11/04(月) 00:05:11.75 ID:???]

年取ると、書いてないことを読んだり、
書いてあることを読めなかったりします
私もそうだから、よく分かります

[517 NAME IS NULL 2019/11/22(金) 17:14:44.84 ID:kYOxBcYU]

「利用回数が制限されているユーザーとされていないユーザーがいる」
という条件だとします。

このとき、finiteカラム（int）が99であれば、99回利用できるとします。
利用するごとに1ずつ減っていくイメージです。

では、「無制限に利用できる」を表現したい場合、finiteカラムでできるのでしょうか？
それとも、infiniteカラムなどを追加し、そこが1（有効）のユーザーは
無制限に利用できるというような、フラグ的な使い方をすればいいのでしょうか？

どう設計するのがベストプラクティスかわかりません。教えて下さい。

[518 NAME IS NULL 2019/11/22(金) 17:19:37.29 ID:???]

制限ユーザーかどうかを識別するカラムを追加か、
finiteが -1 なら無制限ユーザーとする、とか

[519 NAME IS NULL 2019/11/22(金) 19:58:57.97 ID:???]

ベストプラクティスなんて、アプリの設計方法次第で変わるわ

とりあえずfiniteにNULLでいいだろ
NULLから1引いてもNULLだからな

[520 NAME IS NULL 2019/11/22(金) 20:52:28.55 ID:???]

Wow

[521 517 2019/11/22(金) 21:24:33.78 ID:???]

>>518
なるほど。-1って考えはありませんでした。
聞いたことありませんが良さそうですね。

>>519
int型のカラムにNULL入れちゃうのは抵抗があります・・・

[522 NAME IS NULL 2019/11/22(金) 21:49:00.10 ID:???]

個人的には、利用上限と利用回数で項目分けたい
あとで利用回数調べたりしがちだから

基本、利用上限＞利用回数で判定して
運用上、アホみたいに利用されないなら
利用上限をintのMAX_VAlUEとかにしとけば
実質無制限になるし、同じ判定で済む

[523 517 2019/11/22(金) 23:00:06.56 ID:???]

>>522
なるほど。その方が汎用性がありますね。

利用上限も制限がある場合は1〜99まで
無制限なら999とかにしておけばわかりやすいです。
-1だとorderの並び替えも難しいですが、999ならできますし

[524 NAME IS NULL 2019/11/22(金) 23:21:12.77 ID:???]

>>523
いや、できるよ

[525 NAME IS NULL 2019/11/23(土) 21:33:05.59 ID:???]

finiteというカラム名がなんかアレ

[526 NAME IS NULL 2019/11/26(火) 17:10:04.54 ID:???]

DB設計をどうするかと、データ取得はどういう順にしたいかは別の問題

[527 NAME IS NULL 2019/11/28(木) 13:21:29.42 ID:j6IzqXGN]

モンスターマップのhtmlのデータをDB化しようとすると，
どんなスキーマにしておくと後々使えるでしょうかね．

[528 NAME IS NULL 2019/11/28(木) 20:58:42.03 ID:???]

Ｃreate Ｔable MonsterMap (
HTML ｖarchar(max);
);

[529 NAME IS NULL 2019/11/28(木) 21:14:57.24 ID:???]

Wow!

[530 NAME IS NULL 2019/11/29(金) 09:41:54.28 ID:???]

>>528 中身をDB化したい場合．
ttps://monstermap.org/data/20191129.html
みたいなURLじゃなくて，その中身です．
名前，グーグルマップへのURL，住所　のフィクションデータが入っていて
ファイル名が日付で，中身には日本語の日付もある状態．
．

[531 NAME IS NULL 2019/12/19(木) 10:39:22.96 ID:iuFPOjkS]

>>33
自分が関わったシステムではただの連番をPKにした
画面の方は検索機能で対応

[532 NAME IS NULL 2019/12/19(木) 10:51:59.59 ID:iuFPOjkS]

>>499
PHPから、と言うより、WEBの入力画面で登録という解釈で良いのかな
国カラムって言い方が違和感あるけど、国項目だよね
保存ボタン押した時に国項目に入力した内容を建造物テーブルの国カラムに設定してINSERT、もしくはUPDATEするみたいな
関係云々はこの画面が建造物と国を関連を登録する機能じゃないのかな

[533 NAME IS NULL 2020/01/24(金) 22:34:18.61 ID:9xzHgBHv]

>>532
国項目って言い方が違和感あるけど、国カラムだよね

[534 NAME IS NULL 2020/01/24(金) 23:19:54.20 ID:Z+86jpdA]

>>533
日本語か英語の違いですw

[535 NAME IS NULL 2020/01/29(水) 14:21:05.79 ID:0X1l6BuN]

運用中の既存のテーブルにカラムを一つ追加したい場合、どうするのがベストでしょうか？

普通に
ALTER TABLE `テーブル名` ADD `カラム名` TEXT NOT NULL AFTER `カラム名`

みたいなSQLを実行するだけでいいのでしょうか？
それともこれを実行するとなにか問題が起きる可能性はあるでしょうか？
運用想定までできてないので、トラブルが起きる可能性があれば教えて下さい

[536 NAME IS NULL 2020/01/29(水) 15:17:24.94 ID:???]

>>535
特殊な事情がない限りALTER TABLEでカラム追加するのが普通
ただDBMSの種類・バージョン、テーブルの規模、カラム追加時の指定方法などによって
どういう考慮が必要かは変わってくるので製品のマニュアルを読んだほうがよい

例えばMySQLなら↓ここを読む
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-performance.html

[537 NAME IS NULL 2020/01/29(水) 16:48:38.71 ID:???]

>>536
ありがとうございます。MySQLを使っています。
運用中のデータ（つまり、読み書きが行われている）ものに対して
テーブルの追加変更ってまずいと思ったのですが、そうでもないみたいですね

[538 NAME IS NULL 2020/01/29(水) 19:00:39.24 ID:???]

>>537
もしバージョン5.x使ってるならそれなりにインパクトあるから
使ってるバージョンのマニュアル見てね

[539 NAME IS NULL 2020/01/29(水) 19:12:12.64 ID:???]

ロックかけて行った方が安全だろうなあとは思う

[540 NAME IS NULL 2020/01/31(金) 21:28:37.66 ID:Ep/cOiXA]

ロックて危険やから難しいんやで？

[541 NAME IS NULL 2020/02/01(土) 03:03:34.39 ID:???]

ロックなしでスキーマ変更するのが安全だと？

可能なら本番稼働中のDBでやるような処理じゃないぞ

[542 NAME IS NULL 2020/02/01(土) 18:17:36.11 ID:jPi9eO5v]

ハイハイお子ちゃまはおねんねしようねえw

[543 NAME IS NULL 2020/02/01(土) 18:53:13.82 ID:5RS/C4xX]

ロックンロール

[544 NAME IS NULL 2020/02/09(日) 21:54:49.46 ID:???]

すみません
SQL質疑応答19のスレ222でも質問した者なんですが
ブライマリキーって迷ったら全てのカラムに指定してもいいですか？

[545 NAME IS NULL 2020/02/09(日) 21:58:21.18 ID:???]

それはアドバイスしても理解できるかどうか疑うレベル

[546 NAME IS NULL 2020/02/09(日) 22:01:46.73 ID:???]

すんません冗談です

[547 NAME IS NULL 2020/02/09(日) 22:07:40.17 ID:vpKzpKVL]

>>544
そーゆー時はidにしとけばええねん

[548 NAME IS NULL 2020/02/09(日) 22:08:42.02 ID:???]

>>544
いいんじゃね？
お前さん以外は誰も困らんし

[549 NAME IS NULL 2020/02/09(日) 22:10:54.01 ID:???]

こういうなりすます奴が出てくるので
質問者はageでやるかトリップ付けた方が良いです

[550 NAME IS NULL 2020/02/11(火) 21:42:03.27 ID:kogHpQHL]

ageるとid出るんですか？

[551 質問者 2020/02/11(火) 23:42:15.58 ID:kogHpQHL]

238 NAME IS NULL sage 2020/02/09(日) 18:00:13.65 ID:???
どうしてもkey を変えたくないなら元情報用カラムをついかして元情報をそこに残すしかし複数の変更履歴残したいならば、変更用トランザクションデータを残して置けば変更履歴は追える




トランザクションデータというのはsqliteでも使えるのでしょうか？
別のテーブルを作って　変更のlogを保存するという方法はどうでしょうかね

[552 NAME IS NULL 2020/02/11(火) 23:56:09.78 ID:???]

ここでいうトランザクションデータというのは、個別の取引レコードの事だと思う
登録するデータの内容とそれが追加か更新か（必要なら削除も）の処理内容を追記するテーブルを用意する
おそらくあなたの考えているLogと同じ事ではないかと思う。もちろんsqliteでも使える

[553 NAME IS NULL 2020/02/12(水) 20:49:06.79 ID:08I8SsIH]

いまどきマスターとかトランザクションとか言っとるジジイは放置でええねん

[554 NAME IS NULL 2020/02/12(水) 21:05:19.11 ID:vYRA4Gos]

？

[555 NAME IS NULL 2020/02/12(水) 21:23:59.53 ID:???]

業務なら普通に使うぞ

[556 NAME IS NULL 2020/02/12(水) 22:35:55.16 ID:???]

DB設計の経験が浅いプログラマーは
マスターとトランザクションデータの区別がまともにできないから気をつけろ

30オーバーのやつも含めてチーム全員が
マスターのことをトランザクションと呼んでて震撼したことがある

[557 質問者 2020/02/12(水) 23:42:53.31 ID:lI+lS+0+]

>>552
なるほどマスタとトランザクションという概念があるんですか、ためになるな
最新のデータはマスターに記録して変更履歴をトランザクションとして記録すればいいんすね

[558 NAME IS NULL 2020/02/13(木) 00:02:14.97 ID:???]

いや、そういうことじゃなくて
もっと基本的な所から勉強した方が良い
話を聞いている限り、テーブル設計がちゃんとできていない

[559 NAME IS NULL 2020/02/13(木) 00:03:42.63 ID:???]

マスターの履歴とマスターにに対する変更イベントを記録(トランザクション)は微妙に違う

[560 質問者 2020/02/13(木) 00:17:07.26 ID:IbwPir4s]

>>558
テーブル設計でいい本とかサイトありますか？
今、達人に学ぶDB設計指南って本読んでるんですけどフワッとしてるっていうかもっとテーブル設計の実例が見たい

[561 NAME IS NULL 2020/02/13(木) 17:28:06.14 ID:dDuhYxxE]

>>557
コボラーのおじいちゃんの概念なw騙されんなw現代においてはなんも意味ないでw

[562 NAME IS NULL 2020/02/13(木) 21:03:05.33 ID:???]

ついてこれないなら黙ってて

[563 NAME IS NULL 2020/02/13(木) 21:16:52.08 ID:???]

>>560
「業務別データベース設計のためのデータモデリング入門」渡辺幸三

[564 NAME IS NULL 2020/02/14(金) 00:46:37.23 ID:+QGsVRcr]

>>563
ありがとうございます
レビュー見ると難しそうだけど読んでみます

[565 NAME IS NULL 2020/02/14(金) 00:52:53.18 ID:???]

分からない事があれば、ここで聞くといいよ
賑わいはないけど真面目にレスが返る板だから

[566 NAME IS NULL 2020/02/19(水) 21:02:42.95 ID:dncf6ZkK]

>>565
おまえが気持ち悪い事ゆうから誰も居らんくなったやないか

[567 NAME IS NULL 2020/02/19(水) 22:45:15.97 ID:???]

褒めないでくださいよ、照れるな

[568 NAME IS NULL 2020/02/20(木) 02:03:55.39 ID:7o2dB+yg]

連番管理する必要がある場合、以下のどちらのほうほうがよいでしょうか？
https://ideone.com/oOlh4z

中間にINSERTされる場合があります。
SELECTする時は漏れなく連番の先頭から最後まで一括で取得することになります。

[569 NAME IS NULL 2020/02/20(木) 03:27:31.79 ID:???]

前後の関係を知りたいのが主なら1だけど、汎用的には2

[570 NAME IS NULL 2020/02/20(木) 04:23:11.02 ID:???]

>>568
件数や更新頻度、データの使われ方による

一括SELECT時のパフォーマンスが重要なら連番順のインデックスを作れるようにする
例えば有理数で管理して1/5, 2/5, 3/5と並んでるところに
データを挿入したければ3/10, 5/10
それで2/10, 3/10, 4/10, 5/10, 6/10の並びになる
他には101000, 102000, 103000のような飛び番で管理して
番号が埋まってきたら番号を振り直す方法もある

挿入時のパフォーマンスが重要なら書いてるようなLinked List的な方法で良いと思う
previousを知る必要がなければ2の方法で十分だがrootが一発でわかるデータは必要

[571 NAME IS NULL 2020/02/20(木) 18:03:03.56 ID:???]

INSERTする頻度がそれほどでないなら
順番を決められるような非整数の項目用意して
通常は整数値を入れておき、
挿入時に前後の項目の中間値を入れるなんてどうかな

[572 NAME IS NULL 2020/02/20(木) 19:50:02.82 ID:???]

>SELECTする時は漏れなく連番の先頭から最後まで一括で取得
取得する順番はどうでもいいのか？

[573 NAME IS NULL 2020/02/20(木) 20:55:47.42 ID:???]

どう考えても２だろ１とかいみふ
>>570
振り直しとかｗ

[574 NAME IS NULL 2020/02/20(木) 21:26:21.35 ID:???]

>>572
再帰クエリを使う前提やろ

>>573
>振り直しとかｗ
RDBのページ分割と同じだぞ

[575 NAME IS NULL 2020/02/20(木) 21:53:23.57 ID:???]

用途によるわな。
二項関係を全部保持する設計だと参照は爆速。

[576 NAME IS NULL 2020/02/20(木) 22:07:16.22 ID:???]

あとnullはやめて-1や0にしといたほうが吉

[577 NAME IS NULL 2020/02/21(金) 05:29:35.02 ID:???]

>>568
入れ子集合
閉包テーブル
なんて方法もあります

[578 NAME IS NULL 2020/02/21(金) 20:03:46.42 ID:???]

>>573
振り直しは実は結構現実的なソリューション

>>574
まあ、再帰前提になるわな

再帰クエリってパフォーマンスどうなんだ
あと再帰のネスト深さとかけっこう制限あったような

[579 NAME IS NULL 2020/04/28(火) 18:41:13.11 ID:???]

フラグ系のカラム名付け質問

例えば商品マスタ（ID,JANコード、名称、・・・）があって
こいつらにセール対象、まとめ買い対象、みたいなフラグカラム追加したいときってどういうカラム名がいいんでしょ？

セール対象テーブル追加してそっちみろは無しでお願いします
is_Bargain、is_MatomeGay(英語わからんので適当)とかにする？

[580 NAME IS NULL 2020/04/28(火) 21:37:21.40 ID:???]

まとめゲイw

命名規約次第だけど個人的にはon_saleやfor_bulkみたいな名前をつける
is/has縛りなら商品に対応する単語をくっつけたほうがいいかも
セール対象商品 => is_bargain_item
まとめ買い対象商品 => is_matomegai_item

item.is_bargainだと英語的には超微妙
item.is_for_bargainならわりと自然だけどis_for_bargainというカラム名は微妙
item.is_bargain_itemも冗長だけど冠詞がないだけでまあ自然でis_for_bargainに比べるとカラム名としてはマシ

[581 NAME IS NULL 2020/04/28(火) 21:42:09.42 ID:???]

ただ現実問題としてis_bargainみたいなboolフラグで管理可能なの？

アフィサイトみたいに表示管理だけでいいなら
それでも問題ないかもしれないけど、実際にキャンペーンやる会社なら
どの期間、どのキャンペーンの対象で、どういう適用条件かみたいなのが最低限必要だからboolじゃ破綻しそう

[582 NAME IS NULL 2020/04/28(火) 23:30:35.91 ID:???]

ありがとうございます
そうなんですよね。英語的にはマシかもだけどカラム名として何だか微妙になるんですよね
現状はフラグ1、フラグ2、..みたいな暗黒状態かつ命名規約何それなので、それよりはマシなのですが

実際は簡単なフラグ管理だけで良いので、バーゲン期間とかは考慮しなくて大丈夫です
良かろうと思って一般的なサンプルでっち上げると余計な検討点が出てきてダメですね

私の悩みを10年前に通過している列海王的な方がいたら、引き続きナイスな命名案をよろしくお願いします

[583 NAME IS NULL 2020/04/29(水) 00:45:02.07 ID:???]

github検索してみたが
on_saleやis_on_saleで命名してるのはそこそこ見つかる

[584 NAME IS NULL 2020/05/02(土) 23:39:27.57 ID:???]

>>583
遅くなりました。ありがとうございます
githubも見てみます
こういう時ネイティブ並の語彙力がほしくなる

[585 NAME IS NULL 2020/05/03(日) 04:57:59.36 ID:???]

どうせそれを見るのも日本人だろ
ネイティブが違和感を感じるかどうかより、日本人が納得するかどうかだと思うぞ

DBMSにもよるだろうが、日本語環境以外での動作を考えないなら日本語カラム名でもいいと思う

[586 NAME IS NULL 2020/05/04(月) 17:11:14.86 ID:???]

以前はfoo_flag, bar_flagみたいな命名はダサいから可能な限り避けようとしてたが
最近は一貫性が取れてるならis_fooやis_barよりもベターなケースが多いと思うようになってきた
組織の英語力やDBリテラシー次第

[587 NAME IS NULL 2020/05/04(月) 22:00:17.67 ID:???]

うちのアカンDB
boo(0,1)とるカラムがxx_kbn
int(0~9)とるカラムがxx_flag
せめて逆じゃね？

[588 NAME IS NULL 2020/05/04(月) 23:04:59.53 ID:???]

逆ならよかったね〜

[589 NAME IS NULL 2020/05/10(日) 15:13:42.60 ID:DCNb3jN3]

普通はデータベースって蓄積するもので、
普通は削除フラグにとどめて、よほどのことがないとdeleteするようなことってないと思いますが、
deleteしまくることによって何か問題が起きたりするのでしょうか？
あと消したあとも、ゴミ箱にいれたHDDの中身みたいに実は復旧可能だったりしますか？
問い合わせのログみたいなのを一定期間後に完全削除するのを考えてます。

[590 NAME IS NULL 2020/05/10(日) 15:37:54.86 ID:???]

>>589
削除するかどうかは要件次第

不要になったら一旦アーカイブに移動させて
その後、事前に決めた一定期間を過ぎたらメディアにバックアップとって削除する
メディアも事前に決めたメディア用の一定期間を過ぎたら廃棄する
そういうデータライフサイクルを要件定義時に決めて運用にのせるのが普通

復元できるかどうかはバックアップやトランザクションログの残し方による

[591 NAME IS NULL 2020/05/19(火) 13:31:17.65 ID:FzKBKTy1]

同じ設計で別の用途に使用したいテーブルがある場合、テーブル名をどうしていますか？

例えばブログの場合、
article 　　→　記事テーブル
category　→　カテゴリーテーブル
article_cateogry　→記事のカテゴリーテーブル

と設計することがあると思います。
ここに「特集」という別のコンテンツを追加したい場合、

special 　　→　特集テーブル
special_category　→　特集カテゴリーテーブル
special_special__cateogry　→特集の特集カテゴリーテーブル

とするのは変です。

記事と特集はテーブル設計が異なるので、同じテーブルでまとめられません。
しかし、「カテゴリー」テーブルの設計は同じです。同名でも意味は通じます。

categoryではなく、type（種類）とかclass（クラス）とか別名にして対応するのでしょうか？

[592 NAME IS NULL 2020/05/19(火) 15:41:38.69 ID:???]

>>591
「特集」は特集記事であって記事の特化したものではないの？

ある一つのカテゴリーを選択した場合に
それに合致する記事も特集も拾いたいケースがあるなら
カテゴリーテーブルは一つにしたほうがよくて
特集テーブルも記事テーブルと1 ― 0..1 の関係で作るか
特集テーブルと記事テーブルを汎化したテーブルを検討する

[593 NAME IS NULL 2020/05/19(火) 16:47:06.21 ID:FzKBKTy1]

>>592
「特集」という例がわかりづらいなら、掲示板（bbs）でもいいです。
掲示板でも「カテゴリー」って分類は必要ですよね？
でも、記事のカテゴリーと掲示板のカテゴリーは内容そのものが違います。

たとえカラムが同じであっても、用途が異なるテーブルを共有し使うのはよくありません。
だからcategoryではない別名が必要なのですが、その命名が難しいという相談です。

[594 NAME IS NULL 2020/05/19(火) 20:13:30.72 ID:???]

この程度のことを聞ける人が会社にいないんだろうかw

[595 NAME IS NULL 2020/05/19(火) 20:32:01.95 ID:???]

記事カテゴリーと掲示板カテゴリーでなんの不都合がある？

[596 NAME IS NULL 2020/05/19(火) 20:45:57.38 ID:???]

>>594
この程度のことがググっても見つからないんです。

>>595
日本語だとそれでOKなのですが、>>591の命名に合わせるとおかしいと思う次第です。

そもそもですが、最初は単純に「category」というテーブル名にしてて、
あとから別の用途のカテゴリーがでてくる事ってありませんか？
最初から記事カテゴリーを作る想定をしていないと思うんです。
規模を拡張する時に命名が被る、だから困るってそんなおかしい悩みですかね・・・

[597 NAME IS NULL 2020/05/19(火) 21:13:48.53 ID:???]

命名がうまくいかないケースの7~8割は
モデリングがうまくできてないケース

[598 NAME IS NULL 2020/05/19(火) 21:52:13.20 ID:???]

悩みは理解できるがmany-to-manyで管理が必要なカテゴリーテーブルが
1つのスキーマに複数必要になるケースってそうそうないよね

[599 NAME IS NULL 2020/05/19(火) 21:58:57.66 ID:???]

そもそもそんな場合はDB分けるし

[600 NAME IS NULL 2020/05/19(火) 22:14:36.92 ID:???]

>>591
そもそも special_category という名称が意味不明

[601 NAME IS NULL 2020/05/19(火) 23:39:26.48 ID:???]

>>598
確かにただアプリとしてブログとか掲示板を作ってるだけなら無いですが、
サイト作ってる場合、要件の追加・カスタマイズってあると思うんですよね
カテゴリーみたいな分類が必要なコンテンツって、
記事、掲示板、お知らせ、特集、クチコミ、求人など様々思いつきますし。
それをWordpressのように単一参照テーブルで管理しろってのもちょっと・・。

>>599
それも考えたのですが、ひとつのDBに数テーブルしかない状態でわけるってのも
どうかと思うんです。JOINの効率も悪そうだし。

>>600
すみません。単に例題として出しただけです。

[602 NAME IS NULL 2020/05/19(火) 23:45:42.87 ID:???]

とにかく的確な答えがない＝よくある設計の悩みじゃないってことですかね
categoryじゃなくても、menuとかclassとかgenreとか似たような用途に使える
名前があるし、わざわざカテゴリーって呼び方にこだわらなくてもいいかもしれません

一般的な質問でない場合、上記のように解釈して妥協します。

[603 NAME IS NULL 2020/05/20(水) 02:26:52.88 ID:???]

力技で命名するより先に設計見直したほうがいいって言われてるのが理解できないのかな

記事カテゴリー
掲示板カテゴリー
お知らせカテゴリー
特集カテゴリー
クチコミカテゴリー
求人カテゴリー

普通のお客さんならキレるよ

[604 NAME IS NULL 2020/05/20(水) 09:07:47.41 ID:???]

>>603
お客さんに提供してないのでキレられることはないですが、
設計を見直すということは、既存のテーブルの名前を変えろということですか？

何度も記載していますが、最初はただの「カテゴリー」として作っていたものを
後から「記事カテゴリー」と別名にするのはリスク高いと思います。
だから力技で命名するしかないのではないか？と思う次第です。

「いや、後から用途が増えるなら変えるべきだろ」
というなら私の認識が間違っているので変更しますが、
確信的なレスがないので納得できないでいます。

[605 NAME IS NULL 2020/05/20(水) 09:15:02.49 ID:???]

自分の説明の仕方が悪いと思うので、もう一度整理します。

（１）初期運用段階
article 　　→　記事テーブル
category　→　カテゴリーテーブル
article_cateogry　→記事のカテゴリーテーブル

（２）「カテゴリー付きの掲示板が必要」という要件が発生した
bbs　　→　掲示板テーブル
bbs_category　→　掲示板カテゴリーテーブル
bbs_bbs__cateogry　→掲示板の掲示板カテゴリーテーブル

[悩み]こういうテーブル設計を追加するのはおかしいと思う。
　　　　一般的にはどうするべきですか？

（補足）>>603さんの案：既存のテーブル名を変更
article_category　→　記事カテゴリーテーブルに変更
article_article_cateogry　→記事の記事カテゴリーテーブル

[悩み]途中で既存のテーブル名を変更するのはリスクが高くないか

[606 NAME IS NULL 2020/05/20(水) 12:39:47.56 ID:???]

いやいやw
>>603のは普通は全部一つのカテゴリーテーブルでまとめられるだとって話なんだけど・・・

CMSで管理するサイトコンテンツのカテゴリーでしょ？
記事に付けるタグと求人に付けるタグが共通でも問題ないし
どちらか一方にしか使えないタグが必要でも
いちいち別テーブルにしなくてもまとめて管理できるでしょ

力技の命名ってのは関連テーブルを示すprefix/infix/suffixを決めて
それを該当スキーマ内で一貫して使うみたいな規約で逃げるという意味
既存のテーブル名を変更するのがリスクが高いかどうかはアプリの作り次第だが
CMSならリスクは知れてる

[607 NAME IS NULL 2020/05/20(水) 17:44:51.41 ID:???]

>>606
もしかしてCMS＝既存のCMSを指してますか？
そうでなくて、自作の話なのですが・・。

それにひとつのカテゴリーテーブルで、>>603みたいなのをまとめるのは無理です。

例えば以下のようなカテゴリーが必要だとします。
記事　 ｜全般、Web制作、システム開発、データベス
掲示板｜パソコン、ニュース、エンタメ
お知らせ｜サービス、イベント、運営会社

記事コンテンツで、掲示板で使用する「パソコン」というカテゴリーはいらないし、
お知らせコンテンツにある、運営会社というカテゴリーもおかしいです。

カテゴリーテーブル（category）を以下のカラム構成にして
id（pk）｜target｜name｜
1　　　｜article｜全般
2　　　｜bbs　｜パソコン

SELECT * FROM category WHERE target='article'

というSQLを実行すれば、「記事だけのカテゴリーを抽出」することは可能です。
しかし、こんな設計は明らかにアンチパターンですよね？
JOINするときはWHEREとセットになるし、SQLコストも増大します。
通常は要件に伴ったテーブルを用意するはずです。

それともアンチパターンとか関係なく、上記のようにするのが普通なのでしょうか？
あるいは、カラム設計自体も違うというのであれば、正しい設計を教えていただきたいです。

[608 NAME IS NULL 2020/05/20(水) 18:55:01.20 ID:???]

>>607
細かいところを置いておくとそのテーブルイメージの考え方はアンチパターンではないよ
同じ情報を管理するのに全部別テーブルにするほうがアンチパターン

JOINするときWHEREとセットになるんじゃなく
記事/掲示板/お知らせみたいな要素を指すIDが結合条件になる
仮にWHEREで指定することになったところで
カテゴリーテーブルの件数なんてめちゃくちゃ少ないし
きちんとインデックス付けてればSQLコストが増大とかしないから

[609 NAME IS NULL 2020/05/20(水) 18:57:14.65 ID:???]

はじめからそういう要件を想定できなかった以上、きれいな設計にしたいなら作り直せ

[610 NAME IS NULL 2020/05/20(水) 19:00:20.45 ID:???]

>>607
それとそのカテゴリーの例を見ると
1つの記事や掲示板は1つのカテゴリーにしか属さない風にも見えるけど
複数カテゴリーに属する前提であってる？

[611 NAME IS NULL 2020/05/20(水) 19:04:47.61 ID:???]

この態度で回答するやついたら神だな
俺は絶対スルー案件だわw

[612 NAME IS NULL 2020/05/20(水) 19:28:50.40 ID:???]

>>607
上でもそうだったけど、命名がおかしい気がする

掲示板のところにある「パソコン」「ニュース」「エンタメ」というのは
5ちゃんねるで言う板のこと？ (たとえばこのスレはデータベース板だけど)

記事・掲示板・お知らせの関係がわかると答えやすくなると思う
(例えば掲示板と記事は一対多の関係など)

[613 NAME IS NULL 2020/05/20(水) 19:48:43.41 ID:???]

なにがどうアンチパターンなのかも判断できないのに
こいつのアンチパターンだからダメって脅迫概念はどっからきてるんだ

[614 NAME IS NULL 2020/05/20(水) 20:15:27.77 ID:???]

>>607
> 正しい設計を教えていただきたいです。
そもそも絶対的に正しい設計なんてない
例えばカテゴリーテーブルを>>603の各項目毎に作るのか１つにまとめるのかも双方にメリット・デメリットあるからケースバイケースで常にどっちかが良いというわけじゃない
算数の答えみたいに正解が１つと思うのはやめた方がいい

[615 NAME IS NULL 2020/05/20(水) 20:25:38.47 ID:???]

レス前後しますが、

>>613
何がどうアンチパターンか＝正規化ができてない
って判断はおかしいですかね？怒られる程なのでしょうか・・・

>>608
既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。

>>609
煽り抜きで教えてほしいのですが、
普通に「思ったより反響があって増築の必要が出た」
って要件、くさるほどあると思うんです。
1か100かじゃなくて、1・2・3って成長していくものだと思うんです。

[616 NAME IS NULL 2020/05/20(水) 20:26:36.28 ID:???]

>>610
591や605の例で中間テーブルを想定していますが、
>>607の例でも中間テーブルを用意すれば、多対多は可能だと思います。

>>611
真摯に議論したいし、間違っていたら教えてもらいたいだけです。

>>614
おしゃるとおりですが、そもそも私の質問自体「こいつ馬鹿じゃね？」
って感じのレスを頂くものですから、ベストプラクティスがあると思うんです。
それにみなさんはどうしているのかを聞きたいのが、希望ですし・・。

[617 NAME IS NULL 2020/05/20(水) 21:04:01.67 ID:???]

>>616
>中間テーブルを用意すれば、多対多は可能だと思います。

実現可能かどうかじゃなく要件として多対多が要求されてるの？

[618 NAME IS NULL 2020/05/20(水) 21:17:12.37 ID:???]

>>615
>既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
>単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。

自分のまずい設計を正当化するためにリスクが増大するんですって言ってるんじゃなく
微妙な設計になることのデメリットと既存の部分を触ることによるデメリットを
天秤に掛けた上の判断なら別にいいと思うよ

CMSでカテゴリーテーブルを使用する箇所が
あっちこっちに散在してるようならそもそもの設計がまずいとは思うけどね

[619 NAME IS NULL 2020/05/20(水) 21:26:58.14 ID:???]

>>617
要求されています。

>>618
618さんの解釈では、
「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」
ということですよね？それがまずい設計だと、

私は「ひとつのテーブルですべてのカテゴリーを管理する」
ことがまずい設計だと思っているんです。

なぜまずいと思うかというと、アンチパターンだったり、正規化できていなかったりと
一般的に悪いと言われるテーブル設計を採用しろと言われているからです。

618さんの言う「カテゴリーはカテゴリーなんだから、複数あるのはおかしい」
という主張は理解できます。
しかし、ひとつのテーブルに用途違いのデータが入ることの正当性が
私には理解できないので、618さんの主張が正しいと思えないんです。
煽っているのではなく、主張を正しいとする論拠がわからないんです。

[620 NAME IS NULL 2020/05/20(水) 21:32:41.33 ID:qpD3w8BM]

意識低い系の自分はその場合カテゴリのテーブルは一つのままカテゴリの種類ごとにidの範囲を変えて運用してしまうな
記事カテゴリは10000〜19999、特集カテゴリは20000〜29999みたいな

[621 NAME IS NULL 2020/05/20(水) 21:34:11.67 ID:???]

>>612 は？

[622 NAME IS NULL 2020/05/20(水) 21:49:45.25 ID:???]

>>620
それで記事テーブルと結合する時はどうするんですか？
全てのSQLにWHERE id BETWEEN '10000' AND '19999'
を追加するのでしょうか？

>>621
5ちゃんねるでいうと板になるんですかね。
記事とか掲示板とかお知らせは1つのテーブル（1つのコンテンツが入る）であり、
カテゴリーというのは、そのテーブル内のデータを分類するために必要です。
1つの投稿に対して複数のカテゴリーを割り当てられることから、多対多ですね。
5ちゃんねるの場合、1つの投稿に複数カテゴリーを割り当てないと思いますが。

[623 NAME IS NULL 2020/05/20(水) 22:07:40.68 ID:???]

>>622
掲示板と記事は一対多なの？

[624 NAME IS NULL 2020/05/20(水) 22:25:53.64 ID:???]

>>619
>「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」ということですよね？
違う、そういう考え方じゃない
既存のしがらみは一旦忘れて同じエンティティなのか異なるエンティティなのかを考える
その答えは要件によって変わるんだが
今のところ異なるエンティティとして管理すべき要件は見当たらない

正規化できないというのは君の思い込み

コンテンツの種別ごとにカテゴリーテーブルとその中間テーブルを作らなきゃいけないのは
SQLアンチパターンの9章にある”Antipattern: Clone Tables or Columns”

[625 NAME IS NULL 2020/05/20(水) 22:39:11.58 ID:???]

CMSならコンテンツを管理する単位が記事だろうと掲示板だろうと
共通に扱える仕組みを用意した上で個別に必要な拡張が施せるようにする

記事に特化した記事管理システムなら
そこに掲示板管理システムをそのまま増設するのは悪手で
DB含めてシステムを分けるか再構築してまともなCMSにする

[626 NAME IS NULL 2020/05/20(水) 23:15:00.78 ID:???]

>>624-625
自分のスキルが低いと思うんですが、理解できずに申し訳ないです。

それでは私が最初に構想していた>>591という
要件毎にテーブルを作るやり方ではなく、
>>607のような、ひとつのテーブルでまとめるやり方が正しい
（今回の相談ケースではこうするべき）という解釈で良いのでしょうか？

AでもBでも良いとか、AもBもよくないという結論では
モヤッとしてしまうので、どちらがベターか指摘してほしいです。

[627 NAME IS NULL 2020/05/20(水) 23:35:03.93 ID:???]

>>616
> ベストプラクティスがあると思うんです。
だからケースバイケースだっていう話

>>611
お前が正しかったわ

[628 NAME IS NULL 2020/05/20(水) 23:41:09.52 ID:???]

突然伸びててビビったズラ

テレワークは終わりですよ

[629 NAME IS NULL 2020/05/21(木) 01:00:34.53 ID:???]

お前の言うカテゴリーとは何なのかを詳細に詰めないとベストな答えなんか出ないわ

テーブル名とかまあどうでもいいわな
掲示板カテゴリーと記事カテゴリーが別だとするなら別テーブル作ればいいし
同じだが使用箇所が違うだけだと思えば一つで良い

[630 NAME IS NULL 2020/05/21(木) 06:52:31.63 ID:???]

命名規約があるなら結果変なテーブル名になっても仕方ない
それがいやならテーブル名を連番にでもすればいい

[631 NAME IS NULL 2020/05/21(木) 11:31:44.45 ID:???]

>要件毎にテーブルを作るやり方ではなく

要件という言葉を理解してないw
無知なのにイキってる感じがQiitaっぽいな

[632 NAME IS NULL 2020/05/21(木) 17:40:13.28 ID:???]

カテゴリと内容の関係ならカテゴリに記事と特集を示すフィールド入れれば解決ずら
その程度の変更もできないプログラムだったらプログラム側の設計も見直したほうがいいら

[633 NAME IS NULL 2020/05/21(木) 18:10:57.18 ID:???]

話題変わるけど10万円給付のオンライン申請で多重申請とかで問題出て停止しているようだけど
これってDB設計が糞だと思うんだけどどうだと思いますか？

[634 NAME IS NULL 2020/05/21(木) 18:20:21.15 ID:???]

システム設計の根本から間違えている

[635 NAME IS NULL 2020/05/21(木) 18:57:20.13 ID:???]

多重申請を許容するかどうかは要件次第なので
多重申請ができるからといってDB設計が糞とは言い切れない

DV被害者対策や郵送申請もあるので
後続の業務はもともと多重申請がある前提で設計しておく必要がある

実際のところは短期間での開発を要求されたから
普通なら必要になる画面や機能を削った結果
多重申請を許容する仕様にせざるを得なかったんだろうな

[636 NAME IS NULL 2020/05/21(木) 19:02:38.66 ID:???]

ググったら10人以上の世帯は複数回申請しないといけないからってのと
間違った内容で申請した場合に後から正しい内容で申請できるようにするために
多重申請ができる仕様にしてるらしい

付け焼き刃だし仕方ないかもね
郵送に一本化しといたほうが効率的だった可能性もある

[637 NAME IS NULL 2020/05/21(木) 19:29:00.39 ID:???]

今回の目的はｷﾞｮｳﾑｶｲｾﾞﾝじゃなくて感染防止だから……

単に用紙の持ち込みをオンライン化しただけで
持ち込まれたデータのチェック・管理はすべて人力
分かりやすいシンプルな良いシステム

[638 NAME IS NULL 2020/05/21(木) 19:49:25.34 ID:???]

＞新型コロナウイルスの感染拡大に伴う現金10万円の一律給付を受けるためのオンライン申請について、
＞東京 調布市と福生市は入力された情報の確認に時間がかかり給付が遅れるおそれがあるとして、受け
＞付けや手続きを停止しました。オンライン申請を巡っては、同じような対応をとる自治体が各地で相次い
＞でいます。

https://www3.nhk.or.jp/news/html/20200521/k10012439151000.html

[639 NAME IS NULL 2020/05/21(木) 21:19:53.32 ID:C+Ki3nmV]

オンラインで申請すると郵送よりも処理に時間がかかる上、
郵送分の処理も妨害して遅くするのでやめてほしいそうだ。

[640 NAME IS NULL 2020/05/22(金) 15:56:07.78 ID:???]

>>607
自分が俄で視点が近いからか微妙に解る気がするんだけどこの設計がEAVじゃないかって気になるって事であってる？

けどこれって>624の「同じエンティティなのか異なるエンティティなのかを考える」が全てで、
カテゴリーっていう同じエンティティなんだから同じテーブルに纏めたってEAVにはならないのではって事だと思うが

このテーブルに[targer:person_name, name:田中]みたいなレコード登録したらEAVだと思うけど

[641 NAME IS NULL 2020/05/22(金) 23:25:58.05 ID:???]

EAVかどうかなんて考え方次第
カテゴリーテーブルがサブカテゴリーにたいするEAVだって考え方もある

EAVだからアンチパターンでダメだって考えが間違ってる
アンチパターンと言われているものの、何がどうダメなのかちゃんと考えないと

[642 NAME IS NULL 2020/05/23(土) 00:18:19.59 ID:???]

AmazonみたいなECサイトで商品カテゴリと顧客カテゴリを管理するとしたらほぼ確実に別エンティティ

Youtubeの動画に付けるタグとGmailのメールにつけるタグも1テーブルで管理することはまずない
(RDB使ってない可能性のほうが高いけど)

QiitaがもしQ&A掲示板を始めたり技術イベントの告知・集客サービスを始めて
各スレッドや各イベントにタグ付けできる機能を実装するようなケースは
既存の記事向けのタグと同じエンティティとして管理する可能性が高い

[643 NAME IS NULL 2020/05/23(土) 09:51:07.58 ID:???]

あきらかに回答でもなく雑談（笑）

[644 NAME IS NULL 2020/05/23(土) 11:30:26.74 ID:???]

雑談と言うより単なる妄想

[645 NAME IS NULL 2020/05/23(土) 12:34:48.23 ID:???]

雑談っちゃ雑談だけど抽象化思考が苦手なやつが多いみたいだから具体的なインスタンスを示してみたんだよ

ケースバイケースとか考え方次第で済ませてその判断基準を何も提示しないのはゼロ回答に等しいからさ

[646 NAME IS NULL 2020/05/23(土) 12:59:28.25 ID:???]

ここは、モノローグスレ

[647 NAME IS NULL 2020/05/23(土) 14:37:43.95 ID:???]

適当な妄想垂れ流すぐらいならゼロ回答のほうがマシ

[648 NAME IS NULL 2020/05/23(土) 16:07:15.63 ID:???]

事例に対する個人の判断結果を示してるだけで、肝心の判断基準を示してない件

[649 NAME IS NULL 2020/05/23(土) 18:14:02.96 ID:???]

>>648
それは「考え方次第」

[650 NAME IS NULL 2020/05/23(土) 20:48:19.09 ID:???]

でも語るスレだからいいのか

[651 NAME IS NULL 2020/05/23(土) 21:52:49.37 ID:???]

>>650
それは「ケースバイケース」

[652 NAME IS NULL 2020/05/27(水) 07:37:48.25 ID:???]

質問です
csv ファイルを提供されて
数量データが4000なのですが
少数第二位までという4000.00の意味の
400000というデータで提供されます
毎回エクセルで100で割ってからインポートします
また、顧客コードが10桁で
数字の羅列が醜いので
12-3456-7890とハイフンの追加も行ってから
インポートします
毎月の事なのですが
この数量データ割算と、顧客データハイフンを
いちいちExcelで処理せずに
インポート時やインポート後にうまく処理する方法は無いでしょうか？

[653 NAME IS NULL 2020/05/27(水) 10:55:44.11 ID:???]

>>652
若干スレチな気もするがその内容ならCSVを変換するスクリプトを書くのが手っ取り早いと思う

どういう方法が最適かはDBMSの種類、既存のインポート方法・インポート時の処理内容、処理件数、所持スキル等による

[654 NAME IS NULL 2020/05/27(水) 11:30:33.69 ID:???]

ここまで回答見てきたけど、結局ケースバイケースで終わる話ばかりだな

[655 NAME IS NULL 2020/05/27(水) 12:01:00.97 ID:???]

経験浅いとケースバイケースが理解できないから仕方ない

[656 NAME IS NULL 2020/05/27(水) 12:29:36.22 ID:???]

そのケースバイケースを細かく教えて
今ここで話題にしているのはその事例なんだから

[657 NAME IS NULL 2020/05/27(水) 13:37:12.83 ID:???]

>>656
>そのケースバイケースを細かく教えて

これがケースバイケースが理解できてない典型例

[658 NAME IS NULL 2020/05/27(水) 13:55:21.55 ID:???]

理解出来るように説明して

[659 NAME IS NULL 2020/05/27(水) 14:36:27.12 ID:???]

>>652
この質問だけだと良くわからないんだよね
csvファイルはどういうDBにインポートされるのかとか
そもそもなぜ100で割ってからインポートするような謎な仕様になっているのかとか

ひとまずこの質問文だと, DB設計の話ではなく, DBを扱うプログラミングの話でしかない
DBにアクセスするプログラミング言語で実装すればよい

[660 NAME IS NULL 2020/05/27(水) 14:47:02.83 ID:???]

>>658
何を知りたいのかを他人が理解出来るようにまず説明して

[661 NAME IS NULL 2020/05/27(水) 14:55:35.18 ID:???]

「ケースバイケースで終わる話」って説明が必要なの？

[662 NAME IS NULL 2020/05/27(水) 15:08:38.84 ID:???]

>>661
それは「ケースバイケース」

[663 NAME IS NULL 2020/05/27(水) 15:23:40.95 ID:???]

客観的に見て「それケースバイケースだよね」ってレスするより
「これはこうしろ」ってレスするほうが早くないか？
質問者に喜ばれるし、自己顕示欲も満たすし、スレも荒れない。
何も損しないんだが、なぜケースバイケースってまとめるのかわからん

[664 NAME IS NULL 2020/05/27(水) 16:56:45.60 ID:???]

>>663
早くない
質問する側がどういうケースなのかを特定するための説明をするほうが断然早い

どういうケースなのかを相手に伝える努力を放棄してるにもかかわらず
答える側にはケースを想定した回答を求めるのは無理筋

[665 NAME IS NULL 2020/05/27(水) 17:28:19.42 ID:???]

何をもって
「それケースバイケース」って言えるか位は､
言えるだろう
それを聞いている

[666 NAME IS NULL 2020/05/27(水) 17:28:52.80 ID:???]

>>664
それならもっと詳しく聞けばいいだけじゃないか？
プログラム板とか情報足りないとそう答えてるぞ

荒れやすいニュース板でもケースバイケースとかどっちでもいいとか
クソレスするやつは少ないよ
ここぐらいだ。端からコミュニケーション放棄してるのは

[667 NAME IS NULL 2020/05/27(水) 17:29:08.26 ID:???]

自分の好きな例を持ってくれば良いという､簡単な事だろう

[668 NAME IS NULL 2020/05/27(水) 17:32:01.30 ID:???]

普通ならそうだよ。
「AまたはBですか？」
という的外れな質問でも
「Cだよ」って回答して
「いや、CじゃなくてAはこういう意味で〜」
ってな感じでスレが流れる。

しかしここは「AでもBでもどっちでもいい」だもん。
まるで会話になっていない

[669 NAME IS NULL 2020/05/27(水) 17:39:29.67 ID:???]

>>665
「それを聞いてる」じゃわからないよ
何を聞いてるの？

[670 NAME IS NULL 2020/05/27(水) 18:00:58.87 ID:???]

>>666
>それならもっと詳しく聞けばいいだけじゃないか？

それは単なる甘え

自分が努力せず他人に努力させようとしてるやつに
仕事でもないのに懇切丁寧に聞き返す労力を払うやつは少ないわな

[671 NAME IS NULL 2020/05/27(水) 18:02:04.31 ID:???]

>>660
これに尽きるな

[672 NAME IS NULL 2020/05/27(水) 18:54:02.70 ID:???]

ここは、AかBかって質問で充分なケース想定ができるならもともな答がかえってくるわ

ケースバイケースっていわれた段階で説明が足りんと気づけや

[673 652 2020/05/27(水) 19:08:39.17 ID:???]

653
659
スレチなのにご回答ありがとうございます
とりあえずデータベースだけで出来るような仕組みを考えます

[674 NAME IS NULL 2020/05/27(水) 19:12:38.40 ID:???]

ちゃんと説明しないやつはコミュニケーションが足らないって言ってるやつが相手してやればいいだろ
内容がはっきりすればそれなりに回答してくれてるだろ、このスレは

[675 NAME IS NULL 2020/05/27(水) 19:14:01.98 ID:???]

常にケースバイケースなら、

ケース分けなどいらないぞ

[676 NAME IS NULL 2020/05/27(水) 19:15:19.35 ID:???]

ちゃんとやりたいことを説明しないからケースバイケースって言われるんだろ

[677 NAME IS NULL 2020/05/27(水) 20:16:10.67 ID:???]

ワークテーブルにいれてから
加工するsqlでインポートはどうかな

[678 NAME IS NULL 2020/05/27(水) 20:19:15.84 ID:???]

まちがえたインサートだ

[679 NAME IS NULL 2020/05/27(水) 21:18:28.66 ID:???]

ETLでやる内容だな

[680 NAME IS NULL 2020/05/27(水) 22:01:37.60 ID:???]

ハイフン入りの顧客コードは計算列という選択肢もある
参照整合性がどうなってんのか気になるが

[681 NAME IS NULL 2020/05/27(水) 22:20:41.40 ID:???]

エクセルだろ
セルに書式設定すればいいんじゃね

インポートして書式設定までVBAですぐできるだろ

[682 NAME IS NULL 2020/05/28(木) 11:27:01.61 ID:???]

>>677-681は想像して書いてるよな。
>>676みたいな奴は読解力がないだけ

[683 NAME IS NULL 2020/05/28(木) 12:11:39.95 ID:???]

>>682
想像してるんじゃなくてDBだけでやりたいという形でケースの特定化がなされたことで>>677や>>680の回答が出やすくなってるんやで

[684 NAME IS NULL 2020/05/28(木) 12:49:31.13 ID:???]

>>682
これに関してケースバイケースなんて言われてないだろ
お前はそれ以前に日本語が読めないのか？

[685 NAME IS NULL 2020/05/28(木) 16:48:42.27 ID:???]

>>684
>>654

[686 NAME IS NULL 2020/05/28(木) 17:13:38.87 ID:???]

カテゴリー君はよほど悔しかったんだなw

[687 NAME IS NULL 2020/10/02(金) 04:29:53.32 ID:8BLp41VJ]

すみません。IDの設定について教えて下さい。
現在、id (INTEGER) と user_name (TEXT) の2カラムで、以下のデータがあるとします。
1 , 東京営業所
2 , 沖縄営業所
3 , 北海道営業所
4 , 東北営業所

データを取得時、以下のように北のほうからの並びで取得したい場合は、並び順を設定するカラムを追加するしかないでしょうか？
3 , 北海道営業所 , 1
4 , 東北営業所 , 2
1 , 東京営業所 , 3
2 , 沖縄営業所 , 4

既存のテーブルで、設計を変更するとプログラム側も変更しないといけない場所が何か所か出てくるので、
極力変更したくないのですが・・・

[688 NAME IS NULL 2020/10/02(金) 07:18:02.94 ID:???]

どうしても変更したくないならソートオーダーの為だけの新テーブルを追加
素直にフィールド追加した方が後の保守は楽ですよ
プログラム側はフィールド追加で影響が出ない様に作るものですけどね

[689 NAME IS NULL 2020/10/02(金) 08:33:57.24 ID:???]

既存テーブルへのカラム追加で既存プログラムも修正が必要になるのって
データを複製してるような処理しか思いつかない
そういう処理なら並び順もデータとして必要になるよね

[690 NAME IS NULL 2020/10/02(金) 20:23:42.56 ID:???]

select *

[691 NAME IS NULL 2020/10/02(金) 22:02:47.07 ID:???]

今どきアスタリスク指定してるくらいじゃ問題にならんよ
最終目的地までカラムを指定せず全部出力するなら別だけど

[692 NAME IS NULL 2020/10/02(金) 22:21:30.11 ID:???]

今order by指定していないなら、それは「たまたま」id順で出てるだけ
どっちにしてもorder by指定する必要がある

今idでorder byしてるが、それを変えたくないなら、id振りなおすしかないわな
id振りなおすのとカラム追加＆プログラム変更とid振り直しとどっちが楽か判断して決めれば良いんじゃね

[693 NAME IS NULL 2020/10/03(土) 20:16:27.73 ID:???]

なんで行順番の話?

[694 NAME IS NULL 2020/10/03(土) 23:37:33.72 ID:???]

さあ

しかしorder byがなくて
バクるアプリを引き継いだワイにはタイムリーネタやで

[695 NAME IS NULL 2020/10/03(土) 23:46:00.34 ID:???]

都道府県コード使うとしても、北からの並びではないからなあ
並べたい順に自分で番号付けたテーブルを用意しないと無理でしょ

[696 NAME IS NULL 2020/10/04(日) 02:18:43.41 ID:???]

sst

[697 NAME IS NULL 2020/10/05(月) 16:37:36.91 ID:???]

case でマッピングするという力業もあるけど

[698 NAME IS NULL 2020/10/05(月) 19:58:12.35 ID:mY4x3iPH]

>>687
そのIDにエリアの概念を持たせなかったのが失敗なんだよ。

[699 NAME IS NULL 2020/10/05(月) 20:44:41.26 ID:???]

idにidentity以外の意味を持たせるのは愚策。素直に順序列を追加するのが吉。

[700 NAME IS NULL 2020/10/05(月) 20:44:48.17 ID:???]

あるあるアンチパターンを勧めてくるとは

さすが

[701 NAME IS NULL 2020/10/05(月) 20:45:18.74 ID:???]

かぶった

[702 NAME IS NULL 2020/10/06(火) 01:05:10.04 ID:HE4gRaIT]

電話番号や郵便番号のコード体系を考えたこともないのかね。

[703 NAME IS NULL 2020/10/06(火) 09:23:09.69 ID:???]

コード体系が必要なら各意味を別々のカラムで管理してコード自体は導出項目にする

コード体系を作ったこともないのかね。

[704 NAME IS NULL 2020/10/06(火) 10:17:55.36 ID:???]

汎用機世代の人やRDBをよく知らないExcel屋さんは
すぐ暗黙のコードを使おうとするんだよね

昔、東大卒のマーケティング屋さんが
10個以上の意味を埋め込んだオレオレ独自コードを
自信満々のドヤ顔で説明してきた時は困り果てたよ

[705 NAME IS NULL 2020/10/06(火) 11:04:05.32 ID:9/QKAQYT]

代理キーが標準のような話になってますね

[706 NAME IS NULL 2020/10/06(火) 11:47:26.23 ID:???]

匿名掲示板で、ID表示なし、コテハンもトリップもナシでどやられてもなあ

[707 NAME IS NULL 2020/10/06(火) 11:47:30.72 ID:???]

コード体系の話はプライマリキーが代理キーかナチュラルキーかは関係ないよ

複数の意味を持たせるのがアンチパターン

[708 NAME IS NULL 2020/10/06(火) 13:04:33.85 ID:9/QKAQYT]

主キーの意味がわかってないのか？

[709 NAME IS NULL 2020/10/06(火) 13:25:17.40 ID:???]

いつもの触っちゃだめなやつ
控えめに言ってガイキチなので気をつけろ

[710 NAME IS NULL 2020/10/06(火) 14:07:09.38 ID:9/QKAQYT]

>>699
identityではなくidentifier。

[711 NAME IS NULL 2020/10/06(火) 14:07:39.63 ID:9/QKAQYT]

>>707
IDはユニークという意味しかない

[712 NAME IS NULL 2020/10/06(火) 14:37:54.31 ID:???]

>>699が言ってるのは「identifierにidentity以外の意味を持たせるのは愚策」ってことやぞ

[713 NAME IS NULL 2020/10/06(火) 14:54:07.51 ID:???]

あるコード(体系)を設計し導出項目となり、それをキーとしたいとなった場合
必然それは代理キーとなるだろう、とは言えるが

導出項目をつねに代理キーにするとか言ってないし
代理キーが主キーに限定されているわけでもないし

そもそもコード体系云々以前に
一つの項目に複数の意味を持たせるなって大原則があるだけ

[714 NAME IS NULL 2020/10/06(火) 16:27:35.99 ID:9/QKAQYT]

実務経験のなさが露呈してますよ

[715 NAME IS NULL 2020/10/06(火) 18:02:55.53 ID:???]

もしかして代理キーをsurrogate keyの意味じゃなくalternate keyの意味で使ってるのか？

もしそうなら誤訳以外のなにものでもないので別の訳語なり用語を選んだほうがいいと思うぞ

[716 NAME IS NULL 2020/10/06(火) 18:11:26.80 ID:???]

https://ja.wikipedia.org/wiki/代理キー
代理キー（だいりキー、英: alternate key）
代替キー (サロゲートキー、surrogate key)

これはやべぇw
英語の日本語の意味が完全に逆

[717 NAME IS NULL 2020/10/06(火) 18:14:46.93 ID:HE4gRaIT]

いまになって調べてるのか？

[718 NAME IS NULL 2020/10/06(火) 18:24:08.59 ID:HE4gRaIT]

>>716
その代替キーはIPAでは代用キーと呼んでいる。

サロゲートキーのことを「代理キー」と呼ぶのは日本の慣習です。

英語の翻訳語は使われ方が反対になることがあるので注意してください。

[719 NAME IS NULL 2020/10/06(火) 22:06:20.96 ID:???]

>>716
wikipediaの記事ができるより前の時期で検索してみたが
surrogate keyは代理キーは、alternate keyは代替キーと正しく訳してるものしか見つからない
オラクル、富士通、ユニシス、@IT、オージス総研などなど

古いDBマガジンを確認しても代理キーはsurrogate keyの意味で使われてるものしかない

歴史修正主義なんかな？

[720 NAME IS NULL 2020/10/06(火) 22:15:47.94 ID:???]

alternate keyは二次識別子と言っておけばだいたいOK

[721 NAME IS NULL 2020/10/20(火) 07:31:35.62 ID:???]

テーブル設計であえて正規化しないで置くべき理由ってなにがあるでしょうか？
ちょろっとググった感じだと、パフォーマンスが重要な要件だとテーブル結合をなるべく避けたい
とかが見つかりましたが

[722 NAME IS NULL 2020/10/20(火) 07:34:17.42 ID:???]

逆に正規化する「べき」理由ってあるの？

[723 NAME IS NULL 2020/10/20(火) 07:40:17.35 ID:???]

素人なので断言できませんがパッと思いつくのは
多重管理を避けることができ、それに付随して
・テーブルの意図が明確になる
・データ不整合の発生を防げる
などです

[724 NAME IS NULL 2020/10/20(火) 10:09:11.35 ID:???]

>>721
トランザクション処理中心の業務系データベースの場合は基本的に正規化する
更新異常を防いで整合性を維持するため

ただしパフォーマンス最適化のために正規化されたものを非正規化することはある
その場合でも設計時には正規化された場合の構造を明確にした上で非正規化する
そうしないと非正規化したことでどういう更新異常が発生しうるのかや
アプリ側で担保しなくてはいけないデータ整合性が明文化されないから

データウェアハウスのようにデータの追加はあっても更新のない情報系データベースの場合は
全く正規化しないわけではないけど最初から分析しやすい形を念頭に設計する

[725 NAME IS NULL 2020/10/20(火) 14:09:08.77 ID:???]

>>724
やはり特殊な用途を除き正規化するのが基本なのですね
ありがとうございます

身近で詳しそうな人に正規化した設計を提出したところ
フラットに作り直すよう指摘され、明確な理由がわからず
もやもやしておりました

開発観点の他に運用・保守観点（項目の追加/削除、データの追跡可能性）
を想像してみても特に正規化を避けるべき理由が思い当たりませんでした

[726 NAME IS NULL 2020/10/20(火) 14:56:58.07 ID:???]

なぜ指摘した本人に理由を聞かないのか

そもそもそれほんとにちゃんとした正規化が出来てるのか？
正規化を避けるべき理由はないのか？

そもそも設計を提出ってなんだよ。業務なのか？
だったらなぜ上司ではなく詳しそうな人なんだ

[727 NAME IS NULL 2020/10/20(火) 15:05:03.53 ID:???]

もしかしてRDBじゃなくMongoみたいの使う前提なのかな？

まあ指摘した本人に理由を聞くべきなのは間違いない

[728 NAME IS NULL 2020/10/20(火) 15:31:38.20 ID:???]

理由ははぐらかされてしまいました
そっちのほうがいい気がする
というようなことを言っていました

> もしかしてRDBじゃなくMongoみたいの使う前提なのかな？
RDBです

[729 NAME IS NULL 2020/10/20(火) 16:12:36.27 ID:???]

技術的な面じゃなくサーバーが年代物で貧弱とか
開発予算がないから手抜きで作るとか政治的な事だったり

[730 NAME IS NULL 2020/10/20(火) 17:39:35.83 ID:???]

正規化した設計とかフラットにした設計の中身が
もう少し具体的にわからんとなんとも言えないね

フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない

[731 NAME IS NULL 2020/10/20(火) 19:58:51.65 ID:???]

>>725
世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい

[732 NAME IS NULL 2020/10/21(水) 00:08:11.04 ID:???]

原則は教科書通りにるすのが一番ですが

場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな

気にやまないことだと思います

[733 NAME IS NULL 2020/10/21(水) 01:41:41.26 ID:???]

すぐに言語化できなくても直感的にモヤッとする設計ってのはある
必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい

[734 NAME IS NULL 2020/10/21(水) 01:49:04.44 ID:???]

なんとなく分かる
気持ち悪い設計って確かにある

[735 NAME IS NULL 2020/10/21(水) 13:04:54.08 ID:???]

第4や第5とかボイス何たらとかを第3に戻されたとか？

[736 NAME IS NULL 2020/10/21(水) 13:07:36.31 ID:???]

第5はともかくボイスコッドで設計できる人の質問ではない気がする

[737 NAME IS NULL 2020/10/21(水) 17:30:47.48 ID:???]

詳しそうで素人な人もいるぜ
クソ設計なテーブルで、プログラム書かされて死にそうになったことある

[738 NAME IS NULL 2020/10/23(金) 14:20:38.63 ID:???]

>>736
ボイスコッドの方が難易上なの？
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある……

[739 NAME IS NULL 2020/10/23(金) 23:40:51.85 ID:???]

実務のボイスコッド正規形は理論のそれと違って
導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる

第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ

[740 NAME IS NULL 2020/11/30(月) 22:31:04.06 ID:???]

とりあえずサロゲートキー持たせたいとき（持たせるって表現で良いのか解らないけど）って、
数字のみの連番にする？　何か文字列も付与する？　ケースバイケース？

数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか

[741 NAME IS NULL 2020/11/30(月) 23:55:06.66 ID:???]

サロゲートキーという範疇に入らないかもしれないがUUIDを使ったほうがいいケースは自然と文字列も入る
分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合

でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな

他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する

[742 NAME IS NULL 2020/12/01(火) 00:00:33.65 ID:???]

最初に文字を入れると全部桁数は揃うだろうから見た目は気持ちはいいかもな

[743 NAME IS NULL 2020/12/02(水) 02:52:19.08 ID:???]

>>741
なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する

これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、２つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したｗ

[744 NAME IS NULL 2020/12/02(水) 09:55:10.43 ID:???]

そもそも代理キーに文字を入れたいとか、代理キーになんらかの意味を持たせたいってことだろ
それすでに代理キーじゃなくね

[745 NAME IS NULL 2020/12/04(金) 10:49:18.51 ID:???]

>>744
代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど

[746 NAME IS NULL 2020/12/04(金) 11:41:14.98 ID:???]

>>745

>>715

[747 NAME IS NULL 2021/01/04(月) 11:20:12.25 ID:???]

商品に、表示フラグ、新着フラグ、18禁フラグや、表示優先順位などWeb上の表示だけに特化した値を持つ場合、商品マスタに書いてしまっていいのでしょうか？それとも別に持ったほうがいいのでしょうか？

[748 NAME IS NULL 2021/01/04(月) 12:28:55.25 ID:???]

表示フラグと18金ｗはいるだろうな
他は、コロコロ変わるものだから
別にして良いと思う

[749 NAME IS NULL 2021/01/04(月) 18:53:45.42 ID:???]

>>747
商品マスタの構成や商品マスタをどう使う前提なのかによる

一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い

18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)

あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通

[750 NAME IS NULL 2021/01/04(月) 21:39:09.85 ID:???]

サロゲートキーにulid 使うのは異端？
スレ検索してもulid 出てこないね。

[751 NAME IS NULL 2021/01/04(月) 22:01:16.35 ID:???]

サロゲートキーにUUIDを必要とするユースケース自体がかなり稀だからね

[752 NAME IS NULL 2021/01/04(月) 23:04:35.94 ID:???]

ごめん、ちゃんと注意して書けば良かった。
128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。

日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな？

[753 NAME IS NULL 2021/01/04(月) 23:37:36.45 ID:???]

わかってるよ
UUIDを必要とするユースケース以外でULID使うことないでしょ

[754 NAME IS NULL 2021/01/04(月) 23:55:03.99 ID:???]

仰る通りです。すいませんでした。

[755 NAME IS NULL 2021/01/05(火) 00:56:58.70 ID:???]

それサロゲートキー項目に一意性と日時って二つの意味を持たせることになるんじゃね
ありえないな。日時でソートしたいならちゃんと日時の項目もつべき

[756 NAME IS NULL 2021/01/05(火) 01:50:26.16 ID:???]

生成順にソート可能にするための実装として日時を使っているからといって
日時の意味を持たせてるということにはならないよ

ULIDから日時を取り出してデータ作成日時として利用するなら別だが

[757 NAME IS NULL 2021/01/05(火) 15:53:27.55 ID:???]

日時としての意味はなくても、その日時で生成順としての意味をもたせてるじゃないか

シーケンスとか生成順に使うような場合って実際には結構あるけど、本来それも間違ってる
昔のオラクルのマニュアルとか生成順は保証しないようなこと書いてあったんだがなぁ

[758 NAME IS NULL 2021/01/05(火) 17:16:48.59 ID:???]

大小比較可能な値を生成したら「二つの意味を持たせてるからありえない」ってどういう脳みそしてるんだか

オラクルが正だと思ってるようなやつは中途半端な知識で
斜め上の御託を並べ立てるやつが多くて困る

[759 NAME IS NULL 2021/01/05(火) 20:05:33.88 ID:???]

一意保障以外に大小比較って意味をもたせてるんだから二つの意味なんだが
サロゲートキーに一意保障以外の意味を持たせるなって大原則をまず理解しような

[760 NAME IS NULL 2021/01/05(火) 20:08:21.25 ID:???]

シーケンスのDB発番はクラスタ化が難しいので元々ありえない。

UUIDは日時でソート出来ない。

ULIDはソート出来るだけでありがてぇ。パーティショニングで役に立ちそう。あ、DB発番しないよ。

[761 NAME IS NULL 2021/01/05(火) 20:24:27.35 ID:???]

だったら素直にUUIDと日付列用意すればいいんじゃね
インデックスの効率落ちそうだ

[762 NAME IS NULL 2021/01/05(火) 22:59:49.77 ID:???]

>>759
なんで2つ意味を持たせると良くないのかをまず考えろよ
その理由を理解せずにトンチンカンなことばっかり言ってマウント取ろうとするからいつもバカにされてるんだぞ

[763 NAME IS NULL 2021/01/09(土) 14:41:54.56 ID:???]

上の話どうなった？
自分740の質問した人間なので気になる

きのこたけのこ論争みたいなもんで正解はないやつ？

[764 NAME IS NULL 2021/01/09(土) 16:21:49.00 ID:???]

UUIDの代替としてULID使うべきかどうかはケースバイケースだからその点ついての正解はない
ULID使いたければ特徴と限界を理解した上で使えばいい
まだ比較的新しいものだから標準ライブラリ相当で安定した実装が提供されてる言語は少ない

二つの意味を持たせてる云々は少し考えればわかるでしょ

[765 NAME IS NULL 2021/01/10(日) 00:03:48.39 ID:???]

ULIDはUUIDのパフォーマンス問題を軽減できるのが一番大きい

[766 NAME IS NULL 2021/01/10(日) 07:38:57.64 ID:???]

>>765
インサートが遅くなるアレ？
ulid 解決できるんだ！？

[767 NAME IS NULL 2021/01/10(日) 08:36:14.08 ID:???]

UUIDを主キーにするって人は、衝突しないって前提でやってるの？

[768 NAME IS NULL 2021/01/10(日) 08:59:33.73 ID:???]

そりゃそのために作られたものなわけだし。使う場合はその前提に乗っかるのが当たり前。

[769 NAME IS NULL 2021/01/10(日) 16:24:43.84 ID:???]

UUID使ってるシステム見たけど
データが無駄にデカイし
インデックスもやたら膨らむしで
主キーに使うのも考えもんだな
気持ちはわからんでもないが

[770 NAME IS NULL 2021/01/10(日) 16:25:36.71 ID:???]

主キーなら衝突したらわかるでしょ

[771 NAME IS NULL 2021/01/10(日) 18:29:44.20 ID:???]

>>770
衝突しない前提なら、衝突したときのリトライ処理等は不要だ
つまり衝突したときの対処してるかって質問だろ

[772 NAME IS NULL 2021/01/10(日) 18:59:06.79 ID:???]

それはエラーをどう扱うかという話で衝突しない前提ではないよ
ユーザーにリトライを促すような個別の対処はしてなくても集約エラーハンドラで結局対処してる

[773 NAME IS NULL 2021/01/10(日) 20:54:05.63 ID:???]

だから、UUIDが衝突したときに個別の対応してるかって質問なんだが
まあ、お前がやってないだろうことは理解した

GUIDが衝突したって話は聞いたことがある
UUID衝突の可能性はゼロではないんだが、まあ起こったときの重要度次第か

[774 NAME IS NULL 2021/01/10(日) 20:58:18.48 ID:???]

>>773
お前質問者じゃないじゃん

[775 NAME IS NULL 2021/01/10(日) 21:33:58.44 ID:???]

UUIDやULIDって衝突した事を想定した方がいいの？
だったらオートインクリメントで良い気がする。

[776 NAME IS NULL 2021/01/10(日) 21:36:18.27 ID:???]

トランザクションが失敗したらリカバリなりするだろうが、キーの重複が原因の時だけ特にどうこうってのはないんじゃないかね

[777 NAME IS NULL 2021/01/10(日) 22:06:27.15 ID:???]

オートインクリメントのように一箇所で採番できる状況ならUUIDは使わないよ

[778 NAME IS NULL 2021/01/10(日) 22:26:37.20 ID:???]

プロシージャー書いて自前で発番すれば良いのではないか

[779 NAME IS NULL 2021/01/11(月) 18:12:04.80 ID:???]

UUID/ULIDよりも18禁商品マスタのほうがいかにもDB設計っぽい内容にもかかわらずレス数が桁違いになるのはなぜなんだ？

[780 NAME IS NULL 2021/01/11(月) 19:03:34.36 ID:???]

>>747ならどっちが正しいと決まるもんでもないから、追加情報でもない限りそれ以上話が広がらないし
単純に内容がつまらない。

[781 NAME IS NULL 2021/01/11(月) 21:33:51.50 ID:???]

設計スレなのにどっちが正しいか決まるようなものを期待してるのか
理解に苦しむ

[782 NAME IS NULL 2021/01/11(月) 22:15:19.50 ID:???]

質問者はどっちがいいか聞いてるわけだろ？でもどっちでもいいから話はそこでおしまい。

[783 NAME IS NULL 2021/01/11(月) 23:24:18.82 ID:???]

>>779
机上の知識だけでコメントしやすい内容か
設計の経験がないとコメントしにくい内容かの違い
珍しくにぎわってるからいいんじゃないの

[784 NAME IS NULL 2021/01/27(水) 15:50:40.26 ID:???]

QiitaのWeekly Trendで4位に入ってたから読んでみたが・・・
https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8

扱ってる題材のレベルが低いのは初心者向けだからいいとしても
こんな問題だらけのデータモデルとユースケース書いて平気な顔してる開発者はやばいよな？

[785 NAME IS NULL 2021/01/27(水) 18:11:58.87 ID:???]

マイクロサービスとかいって、REST API 呼び出しをループで大量に実行しようとする
これの気持ちだけちょっとわかる

やれoop、やれdddのお作法に合わせて
少ない件数でテストしてできました！
とかやる奴

[786 NAME IS NULL 2021/01/27(水) 21:24:38.53 ID:???]

Qiitaとか見てる奴いるんだｗ

[787 NAME IS NULL 2021/01/27(水) 22:06:01.60 ID:???]

会員登録しないとまともに機能しないサイトは検索上位から消しほしいよ

[788 NAME IS NULL 2021/01/27(水) 22:17:56.84 ID:???]

Googleで検索すると上位に出てきてしまうんだよな
判断力がない奴が読むと、とても危険

[789 NAME IS NULL 2021/01/27(水) 23:20:18.99 ID:???]

DB設計には誰も触れないw
>>783は至言

[790 NAME IS NULL 2021/01/27(水) 23:29:01.05 ID:???]

サンプルだし目くじら立てるほどか？

グルグルSQLどころか
ぐるぐるコネクションされて
性能調査に回って来た時には吹いたから
気持ちはまあわかる

コードのオブジェクト指向的
美しさ、べき論を説かれたが
俺はプログラマーじゃないから
ようわからんかった

[791 NAME IS NULL 2021/01/27(水) 23:59:32.65 ID:???]

コードの美しさよりも処理スピードの方が大事

[792 NAME IS NULL 2021/01/28(木) 00:19:06.32 ID:???]

SQLだけでなんとかしようとするやつも困りもの

[793 NAME IS NULL 2021/01/28(木) 00:57:25.39 ID:???]

ネットショップで画面に商品リストとその詳細仕様を表示する処理があったんだ
前任者はどう作ったかというと、まず商品一覧を取得するSQLを発行した
そのSQLが返してくれる商品一覧に対して、一つずつ詳細取得するSQLを発行した
10件位の時は問題がなかった。多分前任者はこれでOKにしたんだろう
ショップがオープンして、100件、1000件と扱うようになった途端、
メチャクチャに処理に時間が掛かるようになった
で、どう直したかというと、商品一覧を取得する段階で、細かく詳細も取得するようにした
詳細取得が商品種類毎に違っていて、SQLは場合分けが必要で複雑になってしまったが
客は結果を見て喜んでOKを出してくれた

なんでこうなったかと考えて見ると、詳細設計書段階で、
取得する手順の記述があったからのようだ
設計書はとてもシンプルで綺麗な記述になっていた

※この話はフィクションです、実在する人物・企業とは関係ありません

[794 NAME IS NULL 2021/01/28(木) 07:25:30.60 ID:???]

1000件の詳細情報を、一度に取得して表示ねぇ...

まあなんにしても、DB設計の話じゃないな

[795 NAME IS NULL 2021/01/28(木) 11:06:31.58 ID:???]

>>785
マイクロサービスに限らず逐次処理と一括処理とでAPIを分けるのが常識なので
テスト以前のAPIのレビュー時に気づくべきことじゃないか？

[796 NAME IS NULL 2021/01/28(木) 13:02:17.02 ID:???]

SQLを直接書いてるのにN+1で問題になるようなコード書くような人間は周りにはいないな

ORM経由のN+1は仕組みをよく理解してない人間がやらかすけど
そういうのも本番環境に出る前には確実に修正される

DB側で検知する仕組み入れとくと確実かもね

[797 NAME IS NULL 2021/01/28(木) 19:08:58.61 ID:???]

>>784
これはヒドイ

プレミアム会員フラグや商品価格を変更できないw
ぐるぐる以前の問題

[798 NAME IS NULL 2021/01/28(木) 20:39:20.13 ID:???]

商品価格変更されたらどうするんだろうと悩ませておいて、問題文の隅っこに
「価格改定の場合は新規に商品IDを発行する」なんて条件が書いてあったりする
情報処理試験のパターン。

[799 NAME IS NULL 2021/01/29(金) 14:26:13.74 ID:???]

>>798
同じ商品に対して複数のPKを発行できるようにするならモデルが違ってくる

[800 NAME IS NULL 2021/01/29(金) 16:10:44.32 ID:???]

情報処理試験を受けさせてるベンダーほどまともなDB設計できないよね

[801 NAME IS NULL 2021/01/29(金) 18:53:57.86 ID:???]

このタイプの派生関係を使う場合は
読み取り用にはViewを用意してやるといい
各SQLで毎回ケアするのは無駄

[802 NAME IS NULL 2021/01/29(金) 22:45:33.21 ID:???]

>>799
>同じ商品に対して複数のPKを発行

意味不明。
「同じ商品に対して複数の商品ID」なら意味が通じなくもないが
その部分は>>784には描かれていない。

[803 NAME IS NULL 2021/01/29(金) 23:19:36.29 ID:???]

>>802
「同じ商品に対して複数の商品ID」を発行するとして
どうやって同じ商品かどうかを判別するの？

[804 NAME IS NULL 2021/01/29(金) 23:26:28.28 ID:???]

どうやってもなにも、「同じ商品」を判別できるデータを持たせるしかないわな。

[805 NAME IS NULL 2021/01/30(土) 00:26:36.49 ID:???]

同じ商品かどうかを判別するための識別子が必要だよね
それを一般的には商品IDと呼ぶことが多いから複数の商品IDじゃなく複数のPKと書いたわけ

名前は別にいいんだけど
同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
それをモデルに描かないのはありえない

それにある商品の標準価格を変えようとすると
対応するプレミアム価格も変更が必要になる
なら別テーブルにする意味ない

[806 NAME IS NULL 2021/01/30(土) 03:02:35.12 ID:???]

一つの商品ID、商品テーブル、価格テ―ブルで良くね?

[807 NAME IS NULL 2021/01/30(土) 08:22:17.42 ID:???]

>>805
>名前は別にいいんだけど
>同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
>それをモデルに描かないのはありえない

そりゃ設計書としてならあり得なんだろうが実際>>784には商品とか
商品名とか描いてないじゃん。そこで説明したいポイントには関係ないから
省略したんだろうが。

>同じ商品かどうかを判別するための識別子が必要だよね
>それを一般的には商品IDと呼ぶことが多いから

一般にはそういうことが多いとしても、「商品ID」は絶対そうでなくては
ならないという決まりも無いわけなんで、そこはちゃんと定義を
確認しなきゃならん。

>複数の商品IDじゃなく複数のPKと書いたわけ

PKってのはテーブルの定義なんでそこは明らかに間違い。
「商品に対する商品ID」か「商品テーブルのPK」じゃなきゃ
意味が通じない。

[808 NAME IS NULL 2021/01/30(土) 11:58:25.05 ID:???]

>>798
>「価格改定の場合は新規に商品IDを発行する」

その場合でも注文データに確定した支払い金額を記録するぞ
バッチ処理でユーザーごとの購入金額を集計するのに
マスタから価格持ってくるような設計はやばい

[809 NAME IS NULL 2021/01/30(土) 12:01:57.13 ID:???]

>>807
わかってないのに無理してレスすんな

[810 NAME IS NULL 2021/01/30(土) 12:23:10.14 ID:???]

子供の喧嘩じゃないんだから、反論があるなら具体的にな

[811 NAME IS NULL 2021/01/30(土) 12:49:10.58 ID:???]

長いからちゃんと読んでないけどあの記事で言いたいのって
ぐるぐる SQLは性能に問題が出るからやめようねって話なんじゃないの？
テーブル設計はあくまで例であって、そこをここで突っ込んでも…

[812 NAME IS NULL 2021/01/30(土) 15:04:12.14 ID:???]

でもレス返してるやつはそれで正しいと思って返してるのでは？

[813 NAME IS NULL 2021/01/30(土) 16:13:55.14 ID:???]

いいも悪いもあれだけで断言できんだろ

[814 NAME IS NULL 2021/01/30(土) 17:35:24.51 ID:???]

>>811
まともなDB設計ならぐるぐるSQLすら発生しないだろ

[815 NAME IS NULL 2021/01/30(土) 18:02:21.65 ID:???]

そしたら件の記事は設計変更しないでぐるぐる解消しているから「まともな設計」ってことになるが

[816 NAME IS NULL 2021/01/30(土) 18:13:42.82 ID:???]

>>790
コードの美しさとは無関係というか両立できる問題じゃないかなあという気がするんだがどうなんだろう
> ぐるぐるコネクションって、ループの内部で都度接続と切断繰り返してる処理であってる？

>>808
現時点の注文（＝買い物かご）と注文履歴は別管理なんじゃねって言う勝手な想像

[817 NAME IS NULL 2021/01/30(土) 18:14:32.10 ID:???]

運用面で破綻しなければそれはそれでよい設計なのでは？
うちの販売システムは発注伝票の内容は全てトランザクションデータとして保存するし
商品マスタは通常もセットも含めて1テーブルだけど

[818 NAME IS NULL 2021/01/30(土) 18:49:31.12 ID:???]

>>806
顧客や顧客種別ごとに単価を管理する場合はそうするのが普通

ただプレミアム会員向けの単価が登録されてなければ標準単価を採用するみたいなロジックはアンチパターンだから普通はやらない

単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する

[819 NAME IS NULL 2021/01/30(土) 23:22:05.33 ID:???]

>>816
コードの美しさ云々は単なるいいわけでしょ
リモートのAPI呼び出しをローカルに閉じた関数呼び出しと同じように扱おうとする連中と同じ

[820 NAME IS NULL 2021/01/30(土) 23:26:08.18 ID:???]

陽キャ先輩「それDBに任せるともっと良くなるかも！」
俺「一瞬で終わって草ァ！SQLすげぇｗｗｗｗｗｗｗｗ」

陰キャ先輩「はぁ…ぐるぐるSQLは止めてください」
俺「あっ すみません気を付けます… ぐるぐるって何でしょうか…」
陰キャ先輩「知らないの？スキーマがこうでアプリのコードがこうだとするでしょ」
俺「あっあっ はい」
陰キャ先輩「ループがねオーバーヘッドがねマイクロサービスとか言ってる奴等なんて」
俺「はい… はい…」

[821 NAME IS NULL 2021/01/31(日) 05:54:37.13 ID:???]

>>807
>そこで説明したいポイントには関係ないから省略したんだろうが。
そもそも、元のやつの設計が複数の商品IDを発行する設計だと思ってるのか？

つかまあ、あれはほんとのシステムの設計としてはあり得んレベルだけどな
あの記事が言いたかったのはそんなことじゃないだろ

[822 NAME IS NULL 2021/01/31(日) 09:41:56.04 ID:???]

一例を出してこういう処理の仕方はやめましょうっていう内容の記事に対して
本番稼働を前提に設計レビューをしてくれる掲示板

[823 NAME IS NULL 2021/01/31(日) 11:13:07.54 ID:???]

>>818


単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する

これと、価格テーブルが1個であることとは矛盾しない

価格種別を決定するコンテキストがあれば良い

[824 NAME IS NULL 2021/01/31(日) 11:17:15.54 ID:???]

サンプルだからいいってレベルじゃないんだよな
あれを許容できるやつは普段同レベルの設計をしてるとしか思えない

[825 NAME IS NULL 2021/01/31(日) 11:24:40.01 ID:???]

求職サイトだから仕方がない

[826 NAME IS NULL 2021/01/31(日) 11:31:41.57 ID:???]

>>823
それ同じこと言い換えてるだけだよ

[827 NAME IS NULL 2021/01/31(日) 15:21:03.28 ID:???]

根本原因が稚拙なDB設計にあるにもかかわらず
それを理解せずに場当たり的なSQLの修正しか考えないのは悪手でしかないわな

[828 NAME IS NULL 2021/01/31(日) 15:53:35.89 ID:???]

>>827
下請け孫請けでDB設計には口出しできないんだろ

[829 NAME IS NULL 2021/02/02(火) 10:43:18.74 ID:???]

実際問題、後からDB設計間違えたって気づいたらどうする？
運用中のものを停止してでもやり直す？
それとも現状を変えずに追加し続ける？

[830 NAME IS NULL 2021/02/02(火) 12:21:21.06 ID:???]

どういう種類の間違いなのかとそれによってどういう問題が発生しているのかによる

放置
ちょろっと修正
次のプロジェクトで合わせて修正
独立した修正プロジェクトで対応
障害として対応

[831 NAME IS NULL 2021/02/02(火) 14:32:11.31 ID:???]

上で例に出てた注文テーブルのような設計なら
良くて修正プロジェクト、悪いと障害対応だろうな

[832 NAME IS NULL 2021/02/02(火) 19:43:17.14 ID:???]

本番リリース後ならちょろっと修正はないわ

問題がなければ基本放置だが、遅いとかいうクレームでたらまあ協議だな

[833 NAME IS NULL 2021/02/02(火) 22:02:04.11 ID:???]

ポイントはそれを放置した場合にどういうリスクがあるかだよな。
データや処理の間違いで被害を出す恐れがあるなら早めに対処しなきゃならんだろうが、
それも予想される被害の大きさと発生確率によるリスク算定次第。
運用で逃げられるようなものだったら後回しにしたり。

>>831
障害と言えるような具体的な不具合って挙がってたっけ？

[834 NAME IS NULL 2021/02/02(火) 22:40:37.58 ID:???]

>>833
DB設計は単体で障害になるわけじゃないから
アプリの仕様や運用、ビジネス要件との合わせ技

[835 NAME IS NULL 2021/02/03(水) 10:02:04.48 ID:???]

ま、基本的には機能追加が目的だろうな
悪い設計のまま追加するか、それともやり直すか
前者だとコストもリスクも低いが、将来困る
後者だとその逆。

経営判断なら前者になるだろうな

[836 NAME IS NULL 2021/02/03(水) 12:42:18.54 ID:???]

普通の販売管理でこんな設計ないから続ける意味がないと思ってる

[837 NAME IS NULL 2021/02/03(水) 13:14:58.53 ID:???]

無いことはないだろ。国のシステムがしょっちゅう問題になってるじゃん。
似たようなことは日常茶飯事で起きてると思うぞ

[838 NAME IS NULL 2021/02/03(水) 18:03:06.12 ID:???]

＞会員は1回の注文あたり１種類の商品を複数個注文できる。
注文っていったら1回で複数商品注文とかするだろ？
注文テーブルにそんな考慮もないようなシステムで何をするんだい？ｗ

[839 NAME IS NULL 2021/02/03(水) 18:27:35.71 ID:???]

>>838
1注文あたり1種類の商品のみというビジネスモデルも実際に存在するぞ

[840 NAME IS NULL 2021/02/03(水) 19:35:01.61 ID:???]

発注元次第

[841 NAME IS NULL 2021/02/03(水) 20:13:09.59 ID:???]

あの元記事書いた人の最大の失敗は、注文とか商品とか言っちゃったことだな
単にテーブルＡがテーブルＢを参照し、とか言ってればよかったのにな

[842 NAME IS NULL 2021/02/03(水) 20:24:10.77 ID:???]

>>839
UIで制限することはあってもそんなビジネスモデル前提で設計しないと思うけどなぁ
まあ要件みたせばあんなDB設計でもいい人もいるんだからいいのか

[843 NAME IS NULL 2021/02/03(水) 20:44:09.02 ID:???]

1注文に複数商品IDを含めることができるようにするならその分構造が複雑になるわけだから
そういう要求がない限りシンプルな構造にしておくという考え方はあると思うが。

[844 NAME IS NULL 2021/02/03(水) 21:48:04.89 ID:???]

1注文あたり1種類の商品しか注文できないとか
価格変更時は必ず新しい商品IDになるとかは実際にあるけど
注文データに金額を記録しないのは伝票としての要件を満たさないからまずありえない

[845 NAME IS NULL 2021/02/03(水) 22:24:40.50 ID:???]

>伝票としての要件を満たさない

どんな要件を満たしてない？

[846 NAME IS NULL 2021/02/04(木) 15:35:48.76 ID:???]

>>819
特定のDBMSや永続化技術を意識するレイヤーと
ループしながらビジネスルールの判定をするレイヤーを分けたい場合に
ループが途中でブレイクしても確実にコネクションを切断する仕掛けが必要になる

言語やプログラマのスキルによってはその仕掛けが実現できないので
ぐるぐるコネクションになっちゃう

[847 NAME IS NULL 2021/02/04(木) 16:05:13.13 ID:???]

簡単そうな話題だといつまでも話が続くね

[848 NAME IS NULL 2021/02/04(木) 20:16:34.87 ID:???]

話が続かなかった難しい話題って例えばどれ？

[849 NAME IS NULL 2021/02/04(木) 21:22:56.40 ID:???]

ulid をdb側(mysql )で発番したいんだけど、自分で実装するしかない？

一応、日時(例えば20210204125959001)と乱数(80bit分)は作った。
BASE32に変換出来無いから、10進数を36進数(0-9 A-Zの36。CONV関数使用)してみた。
内部だけで使うならアリなんだけど、ユーザーに見えるところはBASE32がいいんだよなぁ。。。

[850 NAME IS NULL 2021/02/04(木) 22:57:48.90 ID:???]

>>849
MySQLへスレへどうぞ

[851 NAME IS NULL 2021/02/05(金) 07:22:54.69 ID:???]

このスレ的には、単一参照テーブル、又の名をOTLT
は結論出てたりする？

https://gihyo.jp/dev/serial/01/sql_academy2/000301

うちの古いシステムは大量にある名称マスタをこの方法で取り扱ってるけど、
やめた方がいいのかなと。

[852 NAME IS NULL 2021/02/05(金) 12:23:22.50 ID:???]

>>851
DB設計の観点からだけいえばEAVと一緒で100%やめたほうがいい
ポリモーフィズムでもなければオブジェクト指向は全く関係ない
RDB以前の汎用機で使われてたやり方

実際にやめるかどうかはシステムの寿命や変更の頻度を考えた場合に
手間をかけるメリットがあるかどうか

[853 NAME IS NULL 2021/02/05(金) 12:31:10.80 ID:???]

>>852
流石に動いてるものは触れない。
仮に新しく作り直すとしたら
大量にマスタが作られて、大量にCRUDの画面が作られる問題が出てくる
これ皆どう解決してるんだろう
もう気にせず愚直に作った方が精神的にもシステム的にもいいんだろうか。

[854 NAME IS NULL 2021/02/05(金) 17:00:05.17 ID:???]

>>851
自分だったら単一参照テーブルにするなら内部キー(PK)・識別子・外部キー・内容の様にして
トランザクションには内部キーを保持したい
理由はテーブルの結合の際にトランザクションとマスタを外部キーで結合して
さらに識別子をハードコードするのは抵抗があるから
でもこういう設計をしても結合の際に識別子を条件に付ける人がいそうなので困る

[855 NAME IS NULL 2021/02/05(金) 18:14:28.40 ID:???]

>>854
複合キーじゃなくサロゲートキーを導入するという話なんだろうけど
識別子や外部キーって用語の使い方を間違えてるから全然伝わらないぞ

識別子は基本的にそれによって行を特定できるキーのこと
外部キーはForeign Keyのこと
商品IDとJANコードのようなのは内部ID/外部IDとは言うけど外部キーとは言わない

[856 NAME IS NULL 2021/02/05(金) 18:17:26.28 ID:???]

>>853
マスタメンテ画面が必要ないものもたくさんあると思うんだけど
必要なら汎用的なマスタメンテ画面を作ればいいんじゃない

[857 NAME IS NULL 2021/02/05(金) 19:08:27.08 ID:???]

>>855
お前が勝手に言葉変えてるだけだろ

[858 NAME IS NULL 2021/02/05(金) 19:08:56.72 ID:???]

>>856
いっぱいお客さんいると男女ですら変更したいという要件もある…
さらにやっぱり英語名も持ちたいとか色々要件増えて管理する項目も微妙に変わってくんだよな…
で、それを汎用項目みたいな持たせ方してるんだよ…

恥ずかしながらこの記事の作者同様、若い頃は便利だなあと思ってた。

よし、一念発起してSexMaster作るか

[859 NAME IS NULL 2021/02/05(金) 21:09:23.08 ID:???]

ここまで、>>851がダメな理由を明確に説明できる奴皆無

[860 NAME IS NULL 2021/02/05(金) 21:31:59.63 ID:???]

>>858
メンテが必要でSQLで手動更新しないなら画面用意する他ないな
Railsのようなのでscaffoldでサクサク作るか
metadata用のAPI使ってOTLTと同じような共通汎用メンテ画面を作るか

[861 NAME IS NULL 2021/02/05(金) 21:34:13.42 ID:???]

>>859
わざわざ説明して欲しいの？

[862 NAME IS NULL 2021/02/05(金) 21:42:58.60 ID:???]

>>861
そういうスレだしな。
でも根拠なしにテキトーなこと言ってるだけの奴は「ググれ」「自分で考えろ」とかいってごまかす。

[863 NAME IS NULL 2021/02/05(金) 22:54:38.55 ID:???]

>>862
記事に欠点が列挙されてるんだがそれは読んだのか？

[864 NAME IS NULL 2021/02/05(金) 23:09:49.13 ID:???]

メリットデメリット併記されていて、少なくとも「100%やめたほうがいい」なんて断言はしてないと思うが

[865 NAME IS NULL 2021/02/06(土) 00:05:44.88 ID:???]

それはミック氏の考え方だからな
SQLには詳しいけどDB設計に詳しい人ではないから

[866 NAME IS NULL 2021/02/06(土) 00:11:31.24 ID:???]

一番大きな欠点は参照整合性を担保できなくなる点
記事にメリットとしてあげられてる点も鵜呑みにせず本当かどうか考えたほうがいい

[867 NAME IS NULL 2021/02/06(土) 05:47:12.37 ID:???]

じゃあ皆さんの設計する社員マスタはセックスマスターを参照しているんですか？

[868 NAME IS NULL 2021/02/06(土) 09:45:46.26 ID:???]

>>866
正確に言うと、件のマスターの主キーが複合主キーになるから参照整合性制約をかけようとするなら
面倒くさい＆無駄ってことだね。
それを必要としない用途で使う分には問題ないかもしれない。

[869 NAME IS NULL 2021/02/06(土) 14:26:16.22 ID:???]

>>868
そう
担保するためには複合主キー+チェック制約がいるので
OTLTを1つ参照するたびに2カラム必要になってヒドイことになる

参照する側が取りうる値の範囲を参照制約以外で担保する前提で
異なるコード体系じゃなく統一されたコード体系のテーブルなら
DB設計的にも有りだけどそれはもうOTLTじゃない

[870 NAME IS NULL 2021/02/06(土) 19:44:15.11 ID:???]

それOTLTとか関係なく複合主キーの問題なんじゃね

[871 NAME IS NULL 2021/02/06(土) 20:44:19.48 ID:???]

そもそも
> OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
とか感覚で語ってる奴の相手しなくていいかと

[872 NAME IS NULL 2021/02/06(土) 21:33:46.92 ID:???]

これだけ解説してもらってもわからないってどういうことよ

[873 NAME IS NULL 2021/02/06(土) 21:40:35.94 ID:???]

>>869
1:男←性別
2:女
3:北海道←ここから都道府県
4:青森
...
80:赤←ここから色
81:青

みたいに管理するってこと？

[874 NAME IS NULL 2021/02/06(土) 21:58:10.25 ID:???]

そもそもOTLTを検討するようなデータは制約をつけるようなデータは管理しないのでは
自分が設計したDBは可変特にユーザーが何か設定するようなデータは必ずマスタとして登録してたわ
何でもかんでも使うのは乱暴だけど純粋にシステムとして値と内容だけで完結するようなデータであればありだと思う

[875 NAME IS NULL 2021/02/06(土) 22:46:52.67 ID:???]

>>874
よくわからん
必ずマスタとして登録って、つまりOTLT的なマスタのこと？

[876 NAME IS NULL 2021/02/06(土) 23:18:19.50 ID:???]

わからないならしかたない

[877 NAME IS NULL 2021/02/07(日) 08:38:41.24 ID:???]

みんなセックスマスター作ってるのか？

[878 NAME IS NULL 2021/02/07(日) 10:46:31.05 ID:???]

みんなあーだこーだ言うだけで
セックスマスター持ってるかどうかまでは言及しないな

[879 NAME IS NULL 2021/02/07(日) 13:58:15.18 ID:???]

>>873
それは統一されたコード体系で扱えるデータじゃないからすぐ破綻すると思うが
データ構造だけで言えば下のように管理して特定の値はIDのみで引けるようにしておくイメージ
表示の多言語対応なんかで使う

ID:カテゴリ:表示名
1:性別:男
2:性別:女
3:都道府県:北海道
4:都道府県:青森
...
80:色:赤
81:色:青

[880 NAME IS NULL 2021/02/07(日) 13:59:52.25 ID:???]

性別はわざわざ参照テーブルを用意するほどじゃないことが多い
作る場合はgenderテーブル

[881 NAME IS NULL 2021/02/07(日) 14:01:55.50 ID:???]

性別には、「未回答」、「回答拒否」って場合もあるんだろうか

[882 NAME IS NULL 2021/02/07(日) 14:58:31.26 ID:???]

>>881
うちは男性、女性、不明で管理してるけど
この手の区分は全てドキュメントの辞書管理してるだけでわざわざテーブルに登録してない

[883 NAME IS NULL 2021/02/07(日) 20:16:00.19 ID:???]

100万件の会員データcsvで出力してください
性別は名称付きでってなったらどうするの？

[884 NAME IS NULL 2021/02/07(日) 20:25:45.49 ID:???]

>>883
case で名前に変換すりゃいいだけじゃね

[885 NAME IS NULL 2021/02/07(日) 20:48:57.88 ID:???]

むむ、じゃあ今日だけ、男じゃなくて雄でだしてほしいんだよな〜って言われたらどうするの

[886 NAME IS NULL 2021/02/07(日) 21:03:19.72 ID:???]

αβΩとか入ってくるとややこしいなぁ

[887 NAME IS NULL 2021/02/07(日) 21:09:16.30 ID:???]

データがあればいくらでも出力できるだろ
生年月日は和暦でお願いといっしょでここでする話じゃない

[888 NAME IS NULL 2021/02/07(日) 21:11:51.65 ID:???]

>>885
今日だけSQL書き換えればいいだけでしょ
アドホックな要求ならそれで充分

[889 NAME IS NULL 2021/02/07(日) 22:24:53.92 ID:???]

今日は♂になりました

[890 NAME IS NULL 2021/02/07(日) 22:40:40.47 ID:???]

>>888
保守性が低い
あなたの会社は毎回sql書き換えてリリースされるのですか

[891 NAME IS NULL 2021/02/07(日) 22:54:02.61 ID:???]

アドホックに表示名を変更するためだけに
マスタを変更するほうが保守性が低い

[892 NAME IS NULL 2021/02/07(日) 23:07:35.14 ID:???]

馬鹿はかまわないほうがいいぞ

[893 NAME IS NULL 2021/02/07(日) 23:10:40.93 ID:???]

性別はともかくどこまでマスタ管理するかだよなあ
令和のために元々管理していなかった元号をマスタ管理するようになったところは多いと思う

[894 NAME IS NULL 2021/02/07(日) 23:12:38.92 ID:???]

保険会社みたいに性別が重要な情報で
それを含む会員データをいろんな用途で使うなら間違いなく性別マスターを作る

でも今回発送するDMに限っては”男性”じゃなく”♂”で表示したいとなっても
性別マスターを更新して対応したりはしない

アドホックに表示をカスタマイズしたいという要望が
恒常的に発生してシステム化が必要な場合は
カノニカルな表記とは別にマッピング機能を追加する

[895 NAME IS NULL 2021/02/08(月) 05:59:15.42 ID:???]

>>890
アドホックの意味わかる？
まあ100万件超えないならExcelにエクスポートして置換でもいいかもな

[896 NAME IS NULL 2021/02/08(月) 06:07:15.07 ID:???]

>>891
保守性と言うかどこで使われてるかわからんマスタの変更なんて簡単にできないよね
本当にいろいろな表示の仕方が恒常的に要求されるならマスタに表示用の列を複数持つわ
id|表示名1|表示名2|表示名3|…
1|男|♂|雄|…
2|女|♀|雌|…

[897 NAME IS NULL 2021/02/08(月) 07:03:16.85 ID:???]

アドホック（ad hoc）は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。

ラテン語はわからないです…

[898 NAME IS NULL 2021/02/08(月) 07:58:09.88 ID:???]

>>896が最強のセックスマスター

[899 NAME IS NULL 2021/02/08(月) 12:49:21.91 ID:???]

>>896
「今日だけ絵文字で表示したいんですけど〜」
「じゃ、お列追加しときますね〜」

[900 NAME IS NULL 2021/02/08(月) 15:13:29.86 ID:???]

>>899
日本語理解できないのか？
> "恒常的" に要求されるならマスタに表示用の列を複数持つ
今日だけの話ならcaseでも専用の表示マスタでも好きにやってくれ

[901 NAME IS NULL 2021/02/08(月) 15:45:13.95 ID:???]

恒常的に要求されてもこのケースは列持ちすべきじゃない

[902 NAME IS NULL 2021/02/08(月) 16:19:26.78 ID:???]

DB設計もしたことない奴が書き込んでるだから無視したほうがいいぞ
俺の中では851なんて全体で合意をとればいい話でどっちだってかまわないと思ってる話題
ただ値（ID、コード）にAは数値、Bは文字と意味を持たせたいなら別管理したほうがストレスはないと思う

[903 NAME IS NULL 2021/02/08(月) 16:44:21.38 ID:???]

>>901
で、お前さんならどうするの？

[904 NAME IS NULL 2021/02/08(月) 17:50:13.97 ID:???]

>>903
id|表示名1|表示名2|表示名3|表示名4|表示名5|表示名6|表示名7|表示名8|…

↑こういう設計見たらどうするの？

[905 NAME IS NULL 2021/02/08(月) 17:51:51.04 ID:???]

扱うシステムの規模にもよるだろうが、大量に名称マスタが必要なシステムだと方向性間違えると辛いことになる

マスタを全て分けると必要最低限の管理画面が必要。その開発工数がバカにならない。

上でも挙がっているが
Rubyのスキャフォールドは便利だが、大規模システムで動的型付け言語は別の点でやばくなる。
asp.net mvcのスキャフォールドはrubyのパクリだが静的型付けなのでまだマシ。
これらに限らず最近のフレームワークは似たような構築機能があるだろう。

加えてシステムの変更に強い。
この名称マスタだけカラムを追加したいみたいなことに対応しやすい。

小規模で変更がないシステムであれば…名称マスタも少ないだろからやっぱりちゃんとマスタ作ったほうがいいんじゃない？

[906 NAME IS NULL 2021/02/08(月) 18:32:42.95 ID:???]

>>904
いいんじゃないの？
表示名nみたいな名前はどうかと思うけど
で、>>903の回答は？

[907 NAME IS NULL 2021/02/08(月) 19:34:38.74 ID:???]

セックスマスター作る派のやつは、セックスマスターメンテナンス画面もつくるのか？

[908 NAME IS NULL 2021/02/08(月) 20:10:58.13 ID:???]

あたり前田

[909 NAME IS NULL 2021/02/08(月) 20:54:45.84 ID:???]

"ぼくのかんがえた最強のセックスマスター"が瞬殺されて涙目の素人さんwww

[910 NAME IS NULL 2021/02/08(月) 21:12:25.50 ID:???]

>>907
セックスマスターにインサートしちゃう

[911 NAME IS NULL 2021/02/08(月) 21:27:56.93 ID:???]

>>909
そういうゴタクはよりマシなセックスマスター提示してから言わないと恥ずかしいだけやでww

[912 NAME IS NULL 2021/02/08(月) 21:34:52.75 ID:???]

セックスマスター作らない人は
TO_DOU_FU_KEN_MASTERも作らないの？

[913 NAME IS NULL 2021/02/08(月) 22:34:51.69 ID:???]

アボンばかり

[914 NAME IS NULL 2021/02/08(月) 22:52:38.12 ID:???]

>>905
マスタを分けてもテーブルの構造に応じて
メンテ画面の内容が変わるようなのを1つ作っとけばいいだけでしょ
異なるコード体系を1カラムに詰め込むのはC#でdynamic typeを使うようなもの

[915 NAME IS NULL 2021/02/08(月) 23:14:23.60 ID:???]

>>907
都道府県マスターと同じでメンテ画面は必要ないことのほうが多い

[916 NAME IS NULL 2021/02/09(火) 12:09:04.76 ID:???]

>>914
異なるコード体系を1カラムに突っ込むなんて書いてないつもりなんだが。

んで、そういう動的に画面生成されるようなやつってどうなんだろ
動的にsql組み立てることになって結局メンテナンスしづらくなると思う。

[917 NAME IS NULL 2021/02/09(火) 12:45:28.48 ID:???]

表示を日本語でするか英語でするかを、
使用するユーザーが決める
それと同じように作ればいい

[918 NAME IS NULL 2021/02/09(火) 16:02:15.61 ID:???]

>>916
>加えてシステムの変更に強い。
>この名称マスタだけカラムを追加したいみたいなことに対応しやすい。

じゃ”この名称マスタ”ってどういう構造を想定して言ってるの？

[919 NAME IS NULL 2021/02/09(火) 16:11:20.57 ID:???]

>>917
それをRDBでやる方法がよくわからないからOTLTみたいなものになってるんだろうね

[920 NAME IS NULL 2021/02/09(火) 17:16:30.95 ID:???]

わかってるやつは話題にはいってこない内容だし
バカが話を脱線させるから851みたいな話はおわらないｗ

[921 NAME IS NULL 2021/02/09(火) 17:51:32.88 ID:???]

>>918
おれはOTLTじゃなくて
性別マスタ、都道府県マスタで別に管理しましょう派だよ？

たとえば都道府県マスタに名産物列を追加しましょう。
メンテナンス画面はめんどくさいけどちまちま直しましょう。
ってこと。

[922 NAME IS NULL 2021/02/09(火) 17:56:14.58 ID:???]

コードと名称以外の属性持つ前提ならOTLTなんて考えないのでは
OTLTを前提にするならコードと名称以外の属性はもたないでしょ

[923 NAME IS NULL 2021/02/09(火) 18:15:45.02 ID:???]

>>922
そんな前提はすぐ崩れる
ソフトウェアには変更がつきもの

[924 NAME IS NULL 2021/02/09(火) 18:32:23.44 ID:???]

>>921
なるほど読み間違えてた

[925 NAME IS NULL 2021/02/09(火) 18:44:25.95 ID:???]

>>923
もともとの要件にない話なら問題外
開発中の変更であれば別テーブルに変更すればいいだけ
そもそもコードと名称しか管理しない前提の都道府県情報に
名産物なんて項目を増やすようなシステムなら最初から別テーブルになるし
そんなこと言い出したらOTLT禁止の前提でシステム（DB）設計してると思うわ
こういう話はごねたいだけの話題にしかならんね

[926 NAME IS NULL 2021/02/09(火) 18:45:47.69 ID:???]

>>916
>動的にsql組み立てることになって結局メンテナンスしづらくなると思う。

動的sql的なものは使わざるをえないけどORM使えば全然大変じゃない

[927 NAME IS NULL 2021/02/09(火) 19:25:24.73 ID:???]

>>925
だから禁止っつうかOTLT使うなって言ってるつーの

[928 NAME IS NULL 2021/02/09(火) 19:27:36.02 ID:???]

>>926
そんなORMあるか…？
そのobjectの型定義はどうなってるんだ？
AcriveRecord？

[929 NAME IS NULL 2021/02/09(火) 19:53:07.87 ID:???]

>>927
0なし
1あり
しか持たない〇〇テーブルたくさん持つの？

[930 NAME IS NULL 2021/02/09(火) 20:30:48.58 ID:???]

>>929
他の人も書いてるように、メンテナンスが発生しない&コードが少ないのであれば
メモリ内に持つ

意外とOTLT派が多いね
自分も大昔使っていたが、害の方が多いという印象。

[931 NAME IS NULL 2021/02/09(火) 21:24:37.20 ID:???]

>意外とOTLT派が多いね

「OTLT派」ってほど積極的に肯定している人はいないんじゃないかな。
ダメな理由がないなら使ってもいいじゃん、程度だと思うけどね。

>自分も大昔使っていたが、害の方が多いという印象。

その「害」を具体的に挙げたら建設的な議論になると思う。
ひとつは上で参照制約の話が挙げられていたが。

[932 NAME IS NULL 2021/02/09(火) 21:47:29.79 ID:???]

こんな害

レコードが増えすぎると性能に影響が出る。そんな大量に突っ込むなよってはなしだが、使い所を分かってない人間はなんでも入れてくる。

変更に強いようで弱い。汎用性を意識して予備カラムみたいなのを用意するが結局足りなかったり、数値型と言ってもintとnumber、日付も時間まで持つかどうかで変わる。
型は厳密に。null非許容にできないのも痛い。

汎用性を重視するあまりカラム名が曖昧になる（なんとか1,2,3）
名前が適当だと後でわからなくなる。

それぞれにViewを定義したりして誤魔化してきたけど、使い所を誤る人がどうしても出てくるのだ。

[933 NAME IS NULL 2021/02/09(火) 21:56:11.05 ID:???]

ありがとう。
そうやって具体的に挙げてもらえたら、あとは自分の案件にとってそれが
「害」になるのかどうか判断すりゃいいだけだね。

[934 NAME IS NULL 2021/02/09(火) 22:13:24.03 ID:???]

>>928
ActiveRecordにしろEFにしろORM経由でテーブルを扱うタイミングでは
ORMがテーブルの型を認識できてる必要はあるよ

Rubyなら動的に型定義可能なので
実行時に汎用メンテ画面で扱うテーブル一覧をDBから読み込んで
それ用のclassを定義したらActiveRecordで扱える

C#でも動的に型定義できるけどちょっと面倒くさいので
テーブルを新規に追加した時はスキャフォールドして型定義をプログラムに追加しとけばいい
テーブル名を変数で渡されたらリフレクションで型にすればあとは普通に使える

[935 NAME IS NULL 2021/02/09(火) 22:33:31.23 ID:???]

>>934
スキャフォールドって
モデルからViewとコントローラーのコードが生成されるけど
それぞれモデル名が頭につくから
SexControllerみたいになるよね
それにテーブル名渡すの？

urlがapi/v1/Sex/Index?table=sexみたいになるのかな？
で、EFは使わず、動的にsqlを組み立てるってこと？
なかなか強引だな。

[936 NAME IS NULL 2021/02/09(火) 22:38:32.80 ID:???]

>>932
これ書いといてなんだけど、同じデータベースの構成でいろんなお客さんにシステム導入しようとするとEAVの問題が出てくるんだよな
で、xmlやjsonを列に突っ込んでる

型を厳密にと言っときながら厳密でない型の列を定義してる俺を罵ってくれ

[937 NAME IS NULL 2021/02/09(火) 22:53:09.69 ID:???]

別に同業他社の人に評価してもらうのではなく使ってもらうユーザーに評価してもらってOKならそれでよくね？
誰が見ても使っても満点の設計なんてできない以上それでかまわないと思うけど

[938 NAME IS NULL 2021/02/09(火) 22:58:26.92 ID:???]

うん、でもそれいっちゃうとこのスレ要らなくない？

[939 NAME IS NULL 2021/02/09(火) 23:00:45.47 ID:???]

>>935
ビューやコントローラを生成する必要はないから
モデルファーストでテーブルを追加/更新するならそのモデル定義をプログラムに追加するだけ

スキャフォールドって言ったのはデータベースの定義を読んでEFで扱えるようにするための話
> dotnet ef dbcontext scaffold --table Hoge

[940 NAME IS NULL 2021/02/09(火) 23:38:34.79 ID:???]

>>939
ViewContoroller使わないのは納得した。

渡したテーブル名はどこで使うの？

pocoで定義されたクラスに値入れて、addしてsavechanges
てのがEFの普通の流れだけど
そのクラス名はhogeだよね

そのクラス名が動的に変わる？

[941 NAME IS NULL 2021/02/11(木) 09:05:41.50 ID:???]

>>921
この手のほぼ更新のないマスタテーブルはDB管理者がsqlでメンテだな

[942 NAME IS NULL 2021/02/11(木) 11:59:29.12 ID:???]

>>940
リフレクション使うんだよ
カラム名やデータ型を共通化できるなら
リフレクションじゃなくジェネリックでも対応可

[943 NAME IS NULL 2021/03/27(土) 19:52:09.74 ID:JXErytnT]

>>1000

日本人はカス民族。世界で尊敬される日本人は大嘘。

日本人は正体がバレないのを良い事にネット上で好き放題書く卑怯な民族。
日本人の職場はパワハラやセクハラ大好き。 学校はイジメが大好き。
日本人は同じ日本人やアジア人には厳しく白人には甘い情け無い民族。
日本人は中国人や朝鮮人に対する差別を正当化する。差別を正義だと思ってる。
日本人は絶対的な正義で弱者や個人を叩く。日本人は集団イジメも正当化する。
日本の芸能人は人の悪口で笑いを取る。視聴者もそれで笑う民族性。
日本人はコロナ感染者を一方的に差別し叩く。感染する奴が悪い主義の民族。
日本人は犯罪者の死刑拷問大好き。でもネットに書くだけで実行は他人任せ前提。
日本人は己の手は汚さない。
日本人は鯨やイルカを殺戮して何が悪いと開き直るが猫や犬には虐待する事すら許さない動物差別主義的民族。
日本人は「外国も同じだ」と言い訳するが文化依存症候群の日本人限定の対人恐怖症が有るので日本人だけカスな民族性なのは明らか。
世界中で日本語表記のHikikomori(引きこもり)Karoshi(過労死)Taijin kyofushoは日本人による陰湿な日本社会ならでは。
世界で日本人だけ異様に海外の反応が大好き。人の顔色を伺う媚びへつらう民族性。
世界幸福度ランキング先進国の中で日本だけダントツ最下位。欧米は上位。
もう一度言う「外国も一緒」は通用しない。日本人だけがカス。カス民族なのは日本人だけ.

陰湿な同級生、陰湿な身内、陰湿な同僚、陰湿なネットユーザー、他者を見下すのが生き甲斐の国民達。
こんなカス民族によるカス国家滅びたってどうでも良いし愛国心を持つ価値も無い。

[944 NAME IS NULL 2021/03/27(土) 20:37:34.41 ID:xBIdyDrI]

カス民族日本でも世界の上位にいるんだよね
カスの日本人より

[945 NAME IS NULL 2021/05/27(木) 22:14:23.71 ID:???]

なんでこんなに
いろんな仕組みが発達したのに
いまだにDBのデッドロックの回避チェックを
人間が人力でやらんといかんのだ

[946 NAME IS NULL 2021/05/28(金) 00:25:17.31 ID:???]

そりゃお前のシステムがクソだからだろ

[947 NAME IS NULL 2021/05/28(金) 00:44:50.60 ID:???]

SQLだけ抽出すれば簡単だろうけど
呼び出し側のコードも含めて解析するとなると面倒くさいわな

普通に設計すればデッドロックで困ることなんてないからニーズもない

[948 NAME IS NULL 2021/05/28(金) 10:16:32.81 ID:???]

ある一つの商品（例えば動画とか）に現物の商品とDL商品と言うように、種類が二つないし複数ある場合

products
- id
- name
- description

product_classes
- id
- product_id
- type
- price

こんな設計でよろしいのでしょうか？
今まで1商品1レコードの単純なものしか扱った事がなかったので、こう言った場合のセオリーがわかりません
よろしければご教授下さい

[949 NAME IS NULL 2021/05/28(金) 22:11:41.96 ID:???]

なんとなく想像はつくけど、設計を語るのであれば最低限ユニークキー、外部キーとかは示した方がいい。

[950 NAME IS NULL 2021/05/29(土) 00:13:12.94 ID:???]

>>948
種類の軸が1つだけで固定的なら基本的にはそれでいいと思う

2つのテーブルの関係は1対多の親子関係(親が存在しないと子も存在しない)なので
product_id + typeの複合主キーにするか
id付与してproduct+id + typeはユニークかつNOT NULLにするか

あとは
商品単位で管理する項目
派生商品単位で管理する項目
現物のみ・DLのみで管理する項目
を精査してモデルを調整する

種類の軸が複数ある(複数になる確率が高そう)なら
それをモデルに取り込んでいく必要がある

classはカテゴリに近い概念に使われるのでやめたほうがいい
英語ならproduct, product_variantが定番

[951 948 2021/05/29(土) 08:38:41.36 ID:???]

>>950
質問する前に調べていた所 EC-CUBEが、dtb_product, dtb_product_class と言う関係のようだったので、product_classes としましたが、正直自分も違和感があったので、product_variant採用させていただきます

主キーやユニークなども適宜設定していきたいと思います

丁寧な回答ありがとう御座いました

[952 NAME IS NULL 2021/07/07(水) 07:18:27.74 ID:???]

初歩的な質問なのですが、テーブルを作成する際は以下のdata列のように数字と文字のように見た時に意味合いが違うデータは同じカラムにするべきではないでしょうか？(id=int型、data=string型)

文字列扱いの列とはいえ、センサONを1,0で表して数値型の列として扱ったほうが適切なのでしょうか？


Id | data |
--------------
1 | 120 |
--------------
2 | 55 |
--------------
3 | センサON |

[953 NAME IS NULL 2021/07/07(水) 09:41:32.05 ID:???]

>>952
そのテーブルやdata列の意図・目的と
CREATE/UPDATE側・READ側でそれぞれどういう風に使うのかによる

アプリケーション全体の設定値を1テーブルに格納するようなケースで
型を揃えられないような場合は文字列で保存して読み取り側で変換する方法はそれなりに使われてる
(設定ファイルと同じ)

[954 NAME IS NULL 2021/07/17(土) 19:18:27.33 ID:???]

知ってて基本は信用できないんだよなあ
Q「DB使えますか？」
できる人「（論理設計やSQLなどの基本的なレベルでは）扱えます」
できない人「（接続先情報指定したら他のことは大体やってくれるORマッパーライブラリがやってくれるから）扱えます」

これを客観的に揃えてくれるのが資格。

凄い人だなとは見られないけど、しょうもない人ではないと安心してもらえる要素として有用

経歴の説明だけで嘘八百じゃないと信じてもらえるコミュ力の人にとっては無用かもしれない

[955 NAME IS NULL 2021/07/17(土) 19:42:59.19 ID:???]

イミフすぎ
何だコイツw

[956 NAME IS NULL 2021/07/17(土) 20:20:24.66 ID:???]

>>954
>Q「DB使えますか？」

質問がアホなので回答もアホになる

できる人は「使えますか？」の意図や定義を確認しようとする質問で返すか
自分でそれを補完して共通認識を明確しやすい回答をする

質問の意図を確認する質問をする人は
盲目的に回答する人に比べてできる人材である確率が飛躍的に高い

[957 NAME IS NULL 2021/07/17(土) 22:12:13.49 ID:???]

とある開発チームはメンバー全員がオラクルのシルバーかゴールド持ってたけど論理設計ができる人は一人もいなかった

Javaのシルバーかゴールドも全員持ってたけどオブジェクト指向的な設計がまともにできる人も一人もいなかった

一般的な資格はできる・できないの指標ではなく最低限の表面的な座学知識を持ってるかどうかの指標

[958 NAME IS NULL 2021/07/18(日) 02:20:49.23 ID:???]

バカの集まり自慢して楽しいのかなw

[959 NAME IS NULL 2021/07/18(日) 08:19:42.48 ID:???]

>>957
木に縁りて魚を求む

[960 NAME IS NULL 2021/07/18(日) 08:31:55.54 ID:???]

このスレでまともに論理設計できそうなやつ見たことない

[961 NAME IS NULL 2021/07/18(日) 11:25:11.08 ID:???]

そもそもオラクルマスターの試験科目に論理設計なんてあるのか？

[962 NAME IS NULL 2021/07/18(日) 13:04:22.39 ID:???]

オラクルマスターって資格を金で買う印象しかない

[963 NAME IS NULL 2021/07/18(日) 14:19:58.12 ID:???]

試験科目はDBAとSQLやぞw

[964 NAME IS NULL 2021/07/18(日) 14:48:22.38 ID:???]

Oracleに必要なのは論理設計よりインフラ側の知識じゃないのかね
広い知識は必要なことが多いけどDB屋は何でも屋じゃないからな

[965 NAME IS NULL 2021/07/18(日) 17:35:07.35 ID:???]

適当な知識ででたらめ言ってるだけだろ
かわいそうなやつ

[966 NAME IS NULL 2021/07/18(日) 18:11:25.20 ID:???]

使える、扱える、試験科目、インフラ側
用語の定義を軽視する人は論理設計に向かない

[967 NAME IS NULL 2021/07/18(日) 18:12:46.43 ID:???]

DBの論理設計に限らず設計能力を測れるような資格は聞いたことがないな
もしあるならぜひ知りたい

[968 NAME IS NULL 2021/07/18(日) 18:19:37.52 ID:???]

仕事場では姑のようにうるさい職なのに
不必要なところまで偏狭な思想を持ち込むと煙たがられるぞ

[969 NAME IS NULL 2021/07/18(日) 19:19:52.47 ID:???]

要求/要件を正しく設計に落とし込む能力ならとりあえずテクニカルエンジニア(DB)でいいんじゃね？

[970 NAME IS NULL 2021/07/18(日) 21:46:58.28 ID:???]

データベーススペシャリスト試験で設計能力は全く測れないよ
高度試験合格してると「お勉強よく頑張ったんですね」って評価はできる

[971 NAME IS NULL 2021/07/18(日) 22:02:15.15 ID:???]

そもそも、そこで言っている「設計能力」ってどういうものを指しているんだろう。
まさかER図を奇麗に描く能力とかじゃないだろうが。

[972 NAME IS NULL 2021/07/18(日) 22:53:26.92 ID:???]

>>971
バカはいいから黙ってろよｗ

[973 NAME IS NULL 2021/07/19(月) 08:02:57.54 ID:???]

>>970
設計に必要な最低限の知識を持っていることくらいはわかるだろう。
少なくともリレーションの正規化も知らないような箸にも棒にもかからないような奴は弾ける。
>>956のような面接での数回の質問よりはあてにできるんじゃないかねぇ。

[974 NAME IS NULL 2021/07/19(月) 09:35:56.32 ID:???]

〇〇が測れないから資格なんて無駄！
って資格も取れない奴の捨てゼリフだろw
資格なんて>>973が言うように最低限の読み書きレベルの保証でしかない

[975 NAME IS NULL 2021/07/30(金) 14:38:44.71 ID:yprK+x+f]

データベースエンジニアは高負荷になりがち

[976 NAME IS NULL 2021/08/03(火) 06:37:39.50 ID:kjdIp7nl]

■■■　ほしのあすかちゃん　無茶苦茶可愛い！！！　■■■
■■■　https://imgur.com/T1UEAEJ.jpg　■■■

■■■　星野飛鳥／ほしのあすか／星野明日香　の画像357枚！！大奉仕！！！　■■■
■■■　お宝画像リンク　→　■■■　https://imgur.com/a/PYlApK1　■■■　←　お宝画像リンク　■■■
【星野飛鳥・ほしのあすか・星野明日香】　合わせて98枚！■■■　https://imgur.com/a/l3OS8C9　■■■
こちらも読んでください。■■■　http://archive.is/HwUrc　■■■


【あべみかこ画像集79枚大量アップ】
あべみかこファンの皆様、いつもお世話になっております。

今回はファンの皆様に大量奉仕いたします。どうぞごゆっくりとご覧くださいませ。
■■■　https://imgur.com/a/knpAYJ4　■■■　←でもこれで2,600ビュー以上いってるんだから人気はあるんだな。
【【【あべみかこ画像　300枚以上・保存版・大出血サービス！！】】】
■■■　https://imgur.com/a/3BzRqGD　■■■　←でもこれで2,800ビュー以上いってるんだから人気はあるんだな。


ブルマ好きのお兄さんたち、大変お待たせしました。
ブルマ姿の女の子たち（大部分が素人）の画像を大量アップさせていただきました。
■■■　https://imgur.com/a/A3iq11Q　■■■
いやぁ、ブルマ姿の女の子って、すごくいいもんですね。
お尻に砂がついてても気にせずにはしゃぎまわる子、
ブルマから下着がはみ出ていても気づかずに元気よく走り回る子、
ブルマに下着のラインが浮き出ていても元気よく動き回る子など、
魅力的な女の子たちの画像が満載となっています。
画像の中には既出や重複がある場合があることをご了承ください。
今夜はブルマ姿の女の子たちを遅くまでごゆっくりとご鑑賞ください。

では、また！

[977 NAME IS NULL 2021/08/28(土) 16:28:41.43 ID:ufCxb7Gf]

この中のどれくらいの人がIPAのデータベーススペシャリスト合格者なのかね。

[978 NAME IS NULL 2021/08/28(土) 17:39:11.36 ID:PkRMMA3g]

データベーススペシャリストでも実体験がはるかに多くないと変な設計になる。

[979 NAME IS NULL 2021/08/28(土) 17:53:44.11 ID:???]

ちゃんとした知識を身に着けないで見よう見まねで実務経験を積んできたようなのの方が
考え方が偏った変な設計になっている気がする。

[980 NAME IS NULL 2021/08/28(土) 18:17:32.02 ID:PkRMMA3g]

それは偏見。いろんな設計を見ていきてないやつだと確かにそうなるが。

[981 NAME IS NULL 2021/08/28(土) 18:29:16.56 ID:???]

だからそのいろんな設計に対応できる知識や能力を問うのが試験であって、そのための勉強をするわけだが。
実務でたまたま出会える設計なんて限られたものだろう。

[982 NAME IS NULL 2021/08/28(土) 18:47:15.12 ID:ufCxb7Gf]

合否は別として、レスを拝見するに真っ当な見識をお持ちの方が多そう。

[983 NAME IS NULL 2021/08/28(土) 18:47:51.18 ID:???]

門前の小僧　習わぬシステムを設計する

[984 NAME IS NULL 2021/08/28(土) 19:23:25.68 ID:P8TnL8ql]

エンジニアでは無いながら、この度スペシャリスト試験受けることになり、勉強する内にデータベースの魅力に気付いてしまった。そして、とうとうプロの巣窟であるこのスレに辿り着いたというわけさ。

[985 NAME IS NULL 2021/08/28(土) 20:11:55.56 ID:???]

>>981
>いろんな設計に対応できる知識や能力を問うのが試験

なんてものが存在すればいいんだけどね
少なくともデータベーススペシャリストの試験ではそんなものは問われない

[986 NAME IS NULL 2021/08/28(土) 20:46:37.45 ID:???]

そういうこと言うのはたいてい受かってない奴w
試験細目はこれ。
https://www.jitec.ipa.go.jp/1_13download/syllabus_db_ver4_0.pdf

[987 NAME IS NULL 2021/08/28(土) 21:07:54.26 ID:???]

>>986
そこに書いてる内容が全て試験で問われるわけじゃないんだよ
実務を知らないのかそれとも試験内容を知らないのか

[988 NAME IS NULL 2021/08/28(土) 21:16:51.62 ID:???]

正規化が設計だと思ってるやついるからな

設計能力を問う試験 == 「これは第何正規形か？」

[989 NAME IS NULL 2021/08/28(土) 21:25:12.13 ID:PkRMMA3g]

実務では制約をガチガチに付けてデータが入らないようにして、それは私の仕事ではありませんと言い、自分の仕事を減らすクソがいるからな。

データベーススペシャリストやオラクルマスターの一部はこうなりやすい。

[990 NAME IS NULL 2021/08/28(土) 21:41:20.39 ID:???]

>データベーススペシャリストやオラクルマスターの一部はこうなりやすい。

相当なルサンチマンがあるようでｗ

[991 NAME IS NULL 2021/08/28(土) 22:05:41.57 ID:P8TnL8ql]

物理設計は実務やってないと感覚的に理解するの難しいのだろうか。。

[992 NAME IS NULL 2021/08/28(土) 22:09:51.55 ID:P8TnL8ql]

次スレ建てましたわ。

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

[993 NAME IS NULL 2021/08/28(土) 22:12:15.87 ID:P8TnL8ql]

新スレ保守お願いします

[994 NAME IS NULL 2021/08/28(土) 22:17:42.12 ID:PkRMMA3g]

>>990
データベース板でそう主張するやつがいるんだよ！

[995 NAME IS NULL 2021/08/28(土) 22:41:54.46 ID:???]

>>991
物理設計はベンダー資格はある程度役に立つ
論理設計は資格試験は全くといっていいほど役に立たない

[996 NAME IS NULL 2021/08/29(日) 11:32:43.63 ID:ns1fXrgZ]

>>995
なるほど。。当方は非エンジニアなんだけども今後、データベース領域の人達と交じるにあたり、データベーススペシャリスト受けようと思ってるのよね。上で誰かも言っていたし、他の多くの試験と同様、最低限の共通言語を持っていると捉えてくれるだろうと期待して。

[997 NAME IS NULL 2021/08/29(日) 11:34:54.60 ID:ns1fXrgZ]

相手の知識量を見積もりながら会話するの非効率だろうから。。

[998 NAME IS NULL 2021/08/29(日) 11:35:16.40 ID:ns1fXrgZ]

さて埋めるか

[999 NAME IS NULL 2021/08/29(日) 11:36:05.25 ID:ns1fXrgZ]

試験通ってデータベーススペシャルになるんや！(´･ω･`)

[1000 NAME IS NULL 2021/08/29(日) 11:36:36.96 ID:ns1fXrgZ]

毎日がスペシャリスト(´･ω･`)