0001NAME IS NULL
2017/05/22(月) 16:38:31.52ID:???前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/
探検
DB設計を語るスレ 10 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/
0002NAME IS NULL
2017/05/22(月) 17:22:02.30ID:???0003NAME IS NULL
2017/05/22(月) 21:59:23.81ID:???0004NAME IS NULL
2017/05/23(火) 09:06:17.88ID:1YMhep2r0005NAME IS NULL
2017/05/25(木) 15:57:16.88ID:???0006NAME IS NULL
2017/05/26(金) 22:01:38.57ID:???0007NAME IS NULL
2017/05/29(月) 19:54:48.57ID:???0008NAME IS NULL
2017/08/23(水) 00:45:19.03ID:???0009NAME IS NULL
2017/08/25(金) 05:55:35.66ID:???0010NAME IS NULL
2017/10/31(火) 23:10:54.44ID:???キッコーマン醤油 500ml 300円 塩分8%
ネスカフェ 300g 450円
菊正宗 1.8L 1000円 アルコール度数15
こんなデータだと、商品名や単価は各データに共通ですが、それ以外は共通点が有りません。
こう言う場合どんなカラムを持つテーブルを作成すべきですか?
0011NAME IS NULL
2017/10/31(火) 23:55:10.31ID:???単なる文字情報なら商品名に突っ込んどけばいい
0012NAME IS NULL
2017/11/01(水) 00:01:10.65ID:???＞各数値をなにかに使うならカラムを作ればいいし
商品名 単価 塩分 アルコール度数 、、、
みたいにするって事ですか?
＞単なる文字情報なら商品名に突っ込んどけばいい
それだと例えば 15<アルコール度数 みたいな検索がやり辛いですよね？
0013NAME IS NULL
2017/11/01(水) 00:12:16.37ID:???アルコール度数や塩分濃度みたいな商品の詳細情報で
精度・性能ともに高いレベルのフィルタリングが必須なら
そういう分類で別途ククリだす
価格.comの検索とかで
商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
あのイメージ
0014NAME IS NULL
2017/11/01(水) 07:07:56.85ID:???＞そういう分類で別途ククリだす
＞
＞価格.comの検索とかで
＞商品カテゴリ毎に詳細検索できる項目を別途用意してるよね
＞あのイメージ
まだよくわからないんですが、一つのテーブルでは無くて、複数のテーブルに分けるようなイメージですか？
そうだとしても、よく分かりません。
0015NAME IS NULL
2017/11/01(水) 14:40:35.09ID:???「データベース 派生関係」でググって
0016NAME IS NULL
2017/11/01(水) 16:39:16.89ID:???EAV
商品 (商品ID, 商品名, 単価)
商品属性 (商品ID, 属性名, 値, 単位)
0017NAME IS NULL
2017/11/01(水) 17:15:33.60ID:???0018NAME IS NULL
2017/11/01(水) 18:05:43.74ID:???ならより良い解答してあげて
0019NAME IS NULL
2017/11/01(水) 18:08:06.97ID:???0020NAME IS NULL
2017/11/01(水) 19:18:20.98ID:???お前みたいな低能にはそうなんだろうな...
0021NAME IS NULL
2017/11/01(水) 20:18:17.14ID:33PRYza30022NAME IS NULL
2017/11/01(水) 20:46:47.43ID:???基本マスタとカテゴリごとのマスタに分けてる感はあるけど
0023NAME IS NULL
2017/11/01(水) 21:10:54.54ID:???派生関係
0024NAME IS NULL
2017/11/01(水) 21:18:05.38ID:???金融商品やプロバイダは別として
家電やPC系は共通マスタと派生マスタで管理してると思うよ
パフォーマンスのための最適化は別途してるかもしれないけどね
http://kakaku.com/pc/note-pc/itemlist.aspx?pdf_Spec101=39
http://kakaku.com/kaden/lcd-tv/itemlist.aspx?pdf_Spec301=42-46
↑この辺比べるとよく分かる
0025NAME IS NULL
2017/11/01(水) 21:46:09.22ID:???商品の種類だけテーブルを増やしていくんだな
買った商品一覧を詳細付きで取ってきたい時とかすげぇ面倒そうだ
0026NAME IS NULL
2017/11/01(水) 21:49:42.43ID:33PRYza3そんな要件があると思えない。
0027NAME IS NULL
2017/11/01(水) 22:24:52.60ID:???仮定の話なんで
ちなみにやる事になったらどんな実装で対応する？
後学のために知っておきたい
002810
2017/11/01(水) 22:58:04.66ID:???>>24
この価格コムの場合、
[最安価格][売れ筋][レビュー評価][クチコミ件数][登録日][スペック情報]
のようにしておいて、
[スペック情報]の部分でパソコンやテレビなどのカテゴリーの事なる製品の
情報を保管するわけですね。
そう言うのを共通マスタと派生マスタと言うんですか？
ググって勉強してみます。
疑問点があればまた質問しますので、よろしくお願いいたします。
002924
2017/11/01(水) 23:50:31.77ID:???>>22の書いてる基本マスタとカテゴリ別マスタみたいな呼び方のほうが多いかもね
とりあえずデータベースの派生関係とか継承でググれば解説してるサイト出てくるよ
0030NAME IS NULL
2017/11/04(土) 01:17:17.38ID:???たいていカラム増やすか予備カラムにまとめてぶっこんでる
0031NAME IS NULL
2017/11/04(土) 14:30:10.74ID:???>予備カラムにまとめてぶっこんでる
そんなの手抜きシステムだろ
0032NAME IS NULL
2017/11/06(月) 15:55:51.67ID:???そんなの有り？
0033NAME IS NULL
2017/12/13(水) 20:21:33.68ID:id+unZ0U電話番号だと電話が無い人もいるし。
0034NAME IS NULL
2017/12/13(水) 23:20:33.63ID:???0035NAME IS NULL
2017/12/14(木) 10:20:17.61ID:???0036NAME IS NULL
2017/12/14(木) 11:24:40.98ID:???0037NAME IS NULL
2017/12/14(木) 22:30:10.07ID:???連番も似たようなもの。
0038NAME IS NULL
2017/12/15(金) 01:33:41.72ID:???違う物に対して同じ値を生成するんだぜ
元のデータで区別できたとしても、ハッシュかけた段階で区別できなくなる可能性があるんだが
そんなものを主キーにするとか狂気のさただな
0039NAME IS NULL
2017/12/15(金) 09:28:07.27ID:???>一般的なハッシュってのは
>違う物に対して同じ値を生成するんだぜ
そんなハッシュあるのかｗ
0040NAME IS NULL
2017/12/15(金) 11:30:27.39ID:???天文学的に小さいな
0041NAME IS NULL
2017/12/15(金) 12:21:10.16ID:???0042NAME IS NULL
2017/12/15(金) 12:22:24.34ID:???元データさえ違うなら心配する確率ではないね
とはいえ、PKに使うものじゃないと思うし連番で十分じゃないかな
0043NAME IS NULL
2017/12/15(金) 20:41:37.20ID:6QrkU8mN0044NAME IS NULL
2017/12/15(金) 22:00:00.19ID:???理屈上どころか衝突前提のハッシュなんていくらでもある
0045NAME IS NULL
2017/12/16(土) 07:09:25.86ID:E1KHECAFおまえは何の勘違いをしとるんやw
0046NAME IS NULL
2017/12/16(土) 08:06:02.76ID:???はあ？
衝突前提のハッシュ知らんのか？
せめてここでも見とけよ
https://ja.m.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0
0047NAME IS NULL
2017/12/16(土) 12:38:08.13ID:???で、それ見て何を勘違いしたんやお前はw
0048NAME IS NULL
2017/12/16(土) 13:13:01.80ID:???0049NAME IS NULL
2017/12/16(土) 14:38:38.92ID:???0050NAME IS NULL
2017/12/16(土) 15:28:06.06ID:???0051NAME IS NULL
2017/12/16(土) 16:16:42.51ID:???MD5だって衝突の可能性はあるわけだが
0052NAME IS NULL
2017/12/16(土) 21:36:50.89ID:E1KHECAF0053NAME IS NULL
2017/12/16(土) 22:34:42.89ID:???こんなアホな突っ込み久々に見たわ w
0054NAME IS NULL
2017/12/16(土) 22:56:10.26ID:E1KHECAFやっとわかったわ
お前勘違いやなくそもそも根本的に何もわかっとらんやろw
0055NAME IS NULL
2017/12/16(土) 23:00:47.03ID:???まあ頑張って一人て吠えてなよ w
0056NAME IS NULL
2017/12/16(土) 23:06:48.97ID:E1KHECAFいやお前がもっと頑張れやw
最初の勢いはどうしたw
0057NAME IS NULL
2017/12/17(日) 08:05:30.02ID:???技術的な話じゃなくなると勢いあるな w
0058NAME IS NULL
2017/12/17(日) 12:37:49.59ID:???え？技術的な話じゃなかったのかw
お前のその深い勘違いの根っこは一体どこにあんねんw
0059NAME IS NULL
2017/12/17(日) 14:02:17.70ID:???俺は技術的な話のつもりだったけど
「勘違い」としか連呼できないアホが絡んできたってだけのこと
0060NAME IS NULL
2017/12/17(日) 19:39:41.63ID:GmUw4YSYしゃあないやろ勘違いをしとるんはお前なんやからw自業自得やぞw
0061NAME IS NULL
2017/12/18(月) 04:59:23.82ID:???0062NAME IS NULL
2017/12/19(火) 16:42:48.07ID:N2E99BBwどや？そろそろ耳の火照りもひいた頃合いやろからお前の勘違いを全部さらけだしてみたらどうや？
間違ってるとこおしえたるでw
0063NAME IS NULL
2017/12/19(火) 19:29:26.17ID:???> 間違ってるとこおしえたるでw
書いてからほざけよ w
どうせ頓珍漢なことしか書けないから引っ張ってるだけだろ？
0064NAME IS NULL
2017/12/19(火) 19:59:07.34ID:N2E99BBwアホかとっくにしびれをきらしとるわw
いいから早くお前がハッシュを何だと思ってるのか書けよ
お前の勘違いしてるとこ教えてやるからw
0065NAME IS NULL
2017/12/19(火) 22:29:33.59ID:???文脈で判断しろよ、バーカ w
0066NAME IS NULL
2017/12/20(水) 08:25:59.98ID:LkqKP4icそれはもう教えてやったやつやろw頓珍漢はお前やわw
てかそんなに恥かくの嫌やったらはじめから何も言うなやw
ホンマにカスやなお前w
0067NAME IS NULL
2017/12/20(水) 08:46:00.54ID:???0068NAME IS NULL
2017/12/20(水) 08:57:14.74ID:LkqKP4icまた動揺してエセ関西弁うつっとるでw恥ずかしいのぉ〜w
0069NAME IS NULL
2017/12/20(水) 12:55:06.94ID:???まだ粘着してるのかよ w
勘違いと言い張るならどこのレス見てどう勘違いしてると思ったのか書けよ
それが書けないからいつまでも勘違いを連呼するしかないんだろ w
0070NAME IS NULL
2017/12/20(水) 15:28:12.50ID:LkqKP4icお前なあwメッチャ自分の勘違いが気になっとるくせになんで素直に聞けんのやw
粘着しとるのお前やでw恥ずかしいのぉ〜w
0071NAME IS NULL
2017/12/20(水) 17:47:08.79ID:???0072NAME IS NULL
2017/12/20(水) 18:50:24.06ID:LkqKP4ic何かうやむやにしたいみたいやけど悔しくてレス返さんと気がすまんのやなw
てかそもそも誰もお前がスキル高い奴だなんて思っとらんからそんなに悔しがる意味もないんやけんどなw
0073NAME IS NULL
2017/12/20(水) 19:09:52.02ID:???>>71
0074NAME IS NULL
2017/12/20(水) 20:03:30.28ID:???0075NAME IS NULL
2017/12/20(水) 20:29:25.30ID:LkqKP4icまだレス返すんかwどんだけ悔しいんやw
無理してそんな煽りレスばっかしとらんと素直にハッシュについて言えばいいやんけw
教えてやるって何度も言っとるのにw
0076NAME IS NULL
2017/12/20(水) 21:17:35.06ID:???>>46
煽りしかできないアホの出る幕じゃねーよ w
0077NAME IS NULL
2017/12/21(木) 07:29:56.41ID:m6k27wgoおいおい何ふりだしに戻しとるんやw
やっぱり何もわかっとらんから自分の言葉で言えんやんけw
で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
言ってみ？教えてやるからw盛大にバカにした後でやけどなwww
0078NAME IS NULL
2017/12/21(木) 08:07:26.64ID:???ハッシュテーブルのこといってるんじゃないの？グルーピングの用途でハッシュ関数使うって意味で
0079NAME IS NULL
2017/12/21(木) 10:05:36.30ID:???多対一の変換に意味があるのか？
0080NAME IS NULL
2017/12/21(木) 10:22:53.47ID:???多対1じゃなくて、多対n。結合するときにないぶてきに使われるhash joinとかこの方式だよね。
0081NAME IS NULL
2017/12/21(木) 10:24:46.30ID:???いいかげん具体的な指摘なしで勘違いとしかほざけないやつはうざいわ
0082NAME IS NULL
2017/12/21(木) 10:49:25.14ID:o/6FHTRS0083NAME IS NULL
2017/12/21(木) 12:54:19.84ID:???> で、それみてお前どうやって衝突前提のハッシュなんて勘違いしたんやw
前提なしでハッシュって書いたら衝突するケースを想定するのは当たり前
そう言うことを知らなかった>>39が暴れてるだけだろ
0084NAME IS NULL
2017/12/21(木) 12:57:47.83ID:cIfjA39h後で教えたるからなw
とりあえずそれまでみんなで>>81を盛大にバカにしときw
0085NAME IS NULL
2017/12/21(木) 15:07:28.11ID:???0086NAME IS NULL
2017/12/21(木) 15:50:38.56ID:???0087NAME IS NULL
2017/12/21(木) 19:55:49.52ID:???何揉めてんだか
>>33はそれの何が不満なんだよ。
0088NAME IS NULL
2017/12/21(木) 20:28:48.83ID:???PKを連番じゃなくてハッシュ値にすべきって散々煽ってたのか。どんな回答するのかすげー気になるわ。
0089NAME IS NULL
2017/12/21(木) 21:31:06.81ID:???>>87の言う通り社員番号とかのユニークキーがあればそれを使えばいい
なんにもなければ>>34の言うように連番を振るとかyymmdd+枝番とか要件によってユニークな番号を振ればいい
とりあえずハッシュバカは無視でいい w
0090NAME IS NULL
2017/12/21(木) 22:13:21.18ID:m6k27wgoお？バカ少しおとなしくなったやんけw完全ハッシュはどうしたw
0091NAME IS NULL
2017/12/21(木) 22:40:25.61ID:???0092NAME IS NULL
2017/12/21(木) 22:42:05.48ID:???0093NAME IS NULL
2017/12/21(木) 22:50:31.46ID:???0094NAME IS NULL
2017/12/22(金) 00:27:00.22ID:???完全ハッシュについて調べてこいよ w
0095NAME IS NULL
2017/12/22(金) 00:30:58.20ID:???もっといい解があるなら示してみてよ
>>93
> 適切なものがなければ、作らなくて良いと思うが
> PKを何にしたら良いでしょうか？
って言ってるのにバカですか？
0096NAME IS NULL
2017/12/22(金) 00:48:01.41ID:???0097NAME IS NULL
2017/12/22(金) 03:07:52.25ID:???PKを指定しないときによきに計らってくれるDBMSなんてみたことないわ
と言っといて、ACCESSとか勝手に連番でPK作ってくれた気もするな
すくなくともRDBMSの基本理念においては、すべてのテーブルはPKを持つべしっとなってる
0098NAME IS NULL
2017/12/22(金) 03:28:06.91ID:???持つべしってことはないでしょ
0099NAME IS NULL
2017/12/22(金) 05:48:11.28ID:???0100NAME IS NULL
2017/12/22(金) 07:21:44.64ID:KAIeoRczええでその調子やwビビらんともう少しその勘違い晒せやへたれw
0101NAME IS NULL
2017/12/22(金) 08:14:52.49ID:???例えば、レコードとして実在の個人を表現したいのに氏名しかないから同姓同名の人が
区別できない、なんてのはそもそもシステム設計の失敗。
それを単に連番振れば解決するかのように言う奴はバカだし有害。
有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
仕組みも必要。。
0102NAME IS NULL
2017/12/22(金) 08:43:18.68ID:???> 個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
> 仕組みも必要。。
そんな当たり前のことを力説されても困るわ w
0103NAME IS NULL
2017/12/22(金) 10:45:03.07ID:???>有効な自然キーがないから人工キーを振るというなら、例えば同姓同名の二人
>(ここでは便宜上AさんBさんとする)に対して、Aさんは1、Bさんは2というように
>個人を特定したうえでキーを採番することが必要だし、その紐付けが維持できるような
>仕組みも必要。。
すまんが、これって連番振るのと何が違うの？
0104NAME IS NULL
2017/12/22(金) 11:01:13.97ID:???俺もそう思うんだよね。
連番であってもなくてもいいけど、社員コードが社員の識別に役立てないとでも思ってんのか
0105NAME IS NULL
2017/12/22(金) 12:45:16.02ID:KAIeoRcz0106NAME IS NULL
2017/12/22(金) 14:56:17.28ID:???さっさと、PKにハッシュ値を設定すべき理由を教えてくれや
0107NAME IS NULL
2017/12/22(金) 18:50:39.54ID:???要件による前提をかってに決めないで話してくれ
0108NAME IS NULL
2017/12/22(金) 19:45:03.18ID:KAIeoRczさすが勘違いバカやなwお前には一体何が見えとるんやw
0109NAME IS NULL
2017/12/22(金) 20:36:34.50ID:???この要件は
名簿みたいなデータではPKを何にしたら良いでしょうか？
これ以外質問者からは提示されていない。
ウスラバカのお前こそ勝手に決めつけんな
0110NAME IS NULL
2017/12/22(金) 21:19:47.34ID:???重要なのはA=1,B=2なのかA=2,B=1なのか特定できてるってこと。
そうじゃない単なるユニークなだけのキーを振っても意味ない。
0111NAME IS NULL
2017/12/22(金) 22:01:01.41ID:KAIeoRczおまえキチガイのふりしたいみたいやけんどわざとらしすぎていまいち萌えんのうw
0112NAME IS NULL
2017/12/22(金) 22:24:18.98ID:???0113NAME IS NULL
2017/12/22(金) 22:43:39.26ID:???すまん、やはりよく分からない
特定できることにどのようなメリットがあるの？
0114NAME IS NULL
2017/12/22(金) 23:30:49.60ID:???>>36
が見えてんな
0115NAME IS NULL
2017/12/22(金) 23:34:05.23ID:???わかったよ。ハッシュでPK最高ー！
0116NAME IS NULL
2017/12/22(金) 23:53:46.12ID:KAIeoRczおまえなあwエセ関西弁使う奴が全部俺やと勘違いしとるやろw
さすが勘違いキングやなwww
てかお前完全に名前を主キーにして大目玉くらうタイプやなw
どんな腐った脳ミソしとったらハッシュを知らんお前をバカにしとる俺と
ハッシュを知らん発言の>>36が同一人物に見えんねんwww
0117NAME IS NULL
2017/12/23(土) 00:05:28.58ID:???へーっ。まじっすか。まじはんぱねーっす。
自分、すげー尊敬しちゃうんで、何に噛み付いてんのかまじ教えてほしいっす。
0118NAME IS NULL
2017/12/23(土) 08:01:51.82ID:???特定できるとメリットがあるというより、AなのかBなのか判別できないデータじゃ意味ないだろうと。
ユニークキーが存在しない状態と変わらんじゃん。
0119NAME IS NULL
2017/12/23(土) 11:03:50.26ID:???山田太郎Aと山田太郎Bを区別しないといけないなら
そのためのカラムを持つべき
そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
単なるユニークなだけのキーを振っておけばいい
今ここで連番を主キーにしろって主張は自然キーの候補がないならって前提だぞ
そもそも主キーが要らないだろって話は別の議論な
0120NAME IS NULL
2017/12/23(土) 12:25:57.35ID:V+00B+qt0121NAME IS NULL
2017/12/23(土) 12:47:20.20ID:???へーっまじっすか。まじはんぱねーっす。早く何に噛み付いてるか教えてくださいよ。
0122NAME IS NULL
2017/12/23(土) 15:22:28.35ID:???100回読んできたら？
あとデータベーススペシャリストに合格するくらい勉強したら、良いと思うよ
0123NAME IS NULL
2017/12/25(月) 21:50:56.03ID:???> 山田太郎Aと山田太郎Bを区別しないといけないなら
> そのためのカラムを持つべき
横からだが、それがサロゲートキーだろ
0124NAME IS NULL
2017/12/26(火) 02:36:23.97ID:???サロゲートじゃなくて、自然キーで区別できるようなカラムが必要だろって事だろ
0125NAME IS NULL
2017/12/26(火) 07:14:12.54ID:???むしろサロゲートキーは
> そうじゃなくて、山田太郎が二人いる事だけ分かれば良いなら
> 単なるユニークなだけのキーを振っておけばいい
の方だろ
0126NAME IS NULL
2017/12/26(火) 08:25:45.48ID:???なるほど住所や何かで複合主キーにしろという事か
読解力がなくて悪かった
それでも不便な自然キーを優先させようとは理由がない限り思わんが
0127NAME IS NULL
2017/12/26(火) 11:22:36.49ID:???0128NAME IS NULL
2017/12/26(火) 12:09:06.71ID:???同じ住所の可能性はゼロじゃないから
0129NAME IS NULL
2017/12/26(火) 12:36:20.97ID:???0130NAME IS NULL
2017/12/26(火) 12:59:30.71ID:???要件による
てか、何と何の複合でやろうとしてるのかすらわからんのに正解かどうかきかれてもな
0131NAME IS NULL
2017/12/26(火) 13:00:41.95ID:???そもそも住所は引っ越しとか町村合併で結構頻繁に変わるし
0132NAME IS NULL
2017/12/26(火) 17:44:38.01ID:???0133NAME IS NULL
2017/12/26(火) 21:57:54.33ID:???複合キーでできるならそれでいいが、ハンドリングしにくいならそのサロゲートでもいい。
ただし複合キーでもユニークに特定できないものはサロゲートにしたところでやっぱりダメ。
0134NAME IS NULL
2017/12/26(火) 22:43:04.71ID:???氏名 住所 年齢
くらいで十分じゃあないの？
0135NAME IS NULL
2017/12/26(火) 22:58:10.93ID:???生年月日ならまだしも年齢とか変わっていくものをPKの一部にするとか変わってるな
0136NAME IS NULL
2017/12/26(火) 23:03:51.55ID:???0137NAME IS NULL
2017/12/26(火) 23:17:18.41ID:???0138NAME IS NULL
2017/12/27(水) 08:04:26.05ID:???Aさんのここ５年間の情報頂戴って言われたらどうするつもりなんだ？ w
0139NAME IS NULL
2017/12/27(水) 08:12:27.79ID:???「Aさんは今何歳？」
「今年は西暦何年？」
「今年は昭和何年？」
0140NAME IS NULL
2017/12/27(水) 10:25:59.08ID:???0141NAME IS NULL
2017/12/27(水) 12:19:03.35ID:5EZatHLU0142NAME IS NULL
2017/12/27(水) 12:46:24.97ID:???年齢を生年月日にするにしても
同姓同名の誕生日も同じ人が
ルームシェアで同じ家に住んでる可能性がある以上
十分とはいえない
0143NAME IS NULL
2017/12/27(水) 14:18:50.57ID:???そういう風にDBに入るなら、間違いではないし誰も困らない
0144NAME IS NULL
2017/12/27(水) 14:26:47.16ID:???0145NAME IS NULL
2017/12/27(水) 14:48:03.83ID:???>>33すら放棄してんのに
お前らヒマなんやな w
0146NAME IS NULL
2017/12/27(水) 14:55:09.55ID:???0147NAME IS NULL
2017/12/27(水) 19:19:41.67ID:lvRR+7xm0148NAME IS NULL
2017/12/27(水) 21:05:50.80ID:???0149NAME IS NULL
2017/12/27(水) 21:22:32.89ID:???明日？そんな先の事は分らない」
0150NAME IS NULL
2017/12/27(水) 21:23:22.17ID:???それな
なのに>>101が連番ではダメと難癖つけたから脱線しただけだよ
0151NAME IS NULL
2017/12/27(水) 22:01:00.99ID:???どっちが一方かだけが提示されていない条件を仮定したかなんて決められるもんかねぇ。
0152NAME IS NULL
2017/12/27(水) 22:20:42.71ID:???唯一の条件を問わない正解なのに
0153NAME IS NULL
2017/12/28(木) 17:05:27.38ID:???回答するに当たって条件があるなら示しとかないとな
>>147
>>101は自然キー（候補キー）の必要性の問題を連番が問題だと勘違いしてるからな
>>152
>「連番じゃなきゃダメ」
そもそもそんな主張がどこにあった？
0154NAME IS NULL
2017/12/28(木) 17:17:30.46ID:???0155NAME IS NULL
2017/12/29(金) 11:03:53.55ID:dtNZwIie参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
NULCDBFZ4S
0156NAME IS NULL
2017/12/31(日) 10:46:46.28ID:???Primary Keyがないテーブルを使うと何か問題が起こりますか？
0157NAME IS NULL
2017/12/31(日) 18:11:01.37ID:rWX012Wwおまえが問題を起こすのだ
0158NAME IS NULL
2017/12/31(日) 18:32:52.59ID:???その人から自分の電話番号変わったから変更してって言われても
どちらを更新して良いか分からない（＝人間）
全部書き換えようとする（＝DB）
こんなことが起こる
普通は一意性を確保するために、
社員IDやら学生IDやらマイナンバーやら
他と重ならないキー情報を用意して、
それをPKにしている。
0159NAME IS NULL
2017/12/31(日) 18:54:16.62ID:XZEULNadそういうのは履歴を取る設計にするのが普通なんだよ。
0160NAME IS NULL
2017/12/31(日) 19:11:39.10ID:???そんなに頻繁に変えるとは思わないし
履歴は履歴レコードで残せば
0161NAME IS NULL
2017/12/31(日) 20:03:47.84ID:???お前は何を言ってるんだ？
0162NAME IS NULL
2017/12/31(日) 20:47:09.37ID:rWX012Wwあくまで俺の予想だけど
そういうのは履歴を取る設計にするのが普通なんだよ。
って言ってるんだと思う
0163NAME IS NULL
2017/12/31(日) 21:23:49.22ID:???すっげーー含蓄のある台詞でした
来年はこれを使おう
0164NAME IS NULL
2017/12/31(日) 21:28:58.37ID:???>>158からそれが読み取れるとしたらよほど天才か知ったかのアホとしか思えんが w
0165NAME IS NULL
2017/12/31(日) 21:44:37.10ID:rWX012Ww勘違いクンはお口にチャックやでえwwww
おまえほんまにアホやなあwww
0166NAME IS NULL
2017/12/31(日) 21:49:45.03ID:???具体的になにも指摘できないなら絡んでこなきゃいいのに w
0167NAME IS NULL
2017/12/31(日) 21:57:51.30ID:rWX012Ww絡んできたのお前やろがwww
脳ミソおかあちゃんのアナルに忘れてきたんかお前はwwwww
0168NAME IS NULL
2017/12/31(日) 22:16:24.92ID:???/:::::;;-‐-､:::ヽ _,,,,,,,_
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;;;''"".. ,,:ヽ／
＼;::: ヾ';;;;;;;;;;;::''' ...::'':: ,,::::::／＼
｀''‐､､__ ￣￣ __,,,,､-‐"
. ／/:::::/ヽ￣￣￣￣ノ::::/＼
. ／ /:::::/ ｀￣￣￣/:::::/. ＼
0169NAME IS NULL
2018/01/01(月) 14:02:21.33ID:KcPEsTvV0170NAME IS NULL
2018/01/01(月) 15:50:18.06ID:???0171NAME IS NULL
2018/01/01(月) 20:56:53.06ID:iMl2Nb4o人的データパッチミス、プログラムの変更、追加によるバグが変なデータを作り出す。
0172NAME IS NULL
2018/01/01(月) 21:23:07.91ID:???そんな所利用したくない
0173NAME IS NULL
2018/01/01(月) 21:26:43.18ID:???ふーん。全てのデータをinsertとフラグ列のupdateとかで更新してくってこと？
0174NAME IS NULL
2018/01/01(月) 22:30:38.24ID:g9MeygUN0175NAME IS NULL
2018/01/01(月) 22:32:52.66ID:g9MeygUN履歴レコードの話だよ。マスタデータでもトランザクションデータでも追跡できないのは運用で困る。何がどうなったのか他人に説明できないだろうが。
0176NAME IS NULL
2018/01/01(月) 22:56:14.39ID:QeD1IQawトランザクションの記録を更新すんなアホw
0177NAME IS NULL
2018/01/01(月) 23:08:31.05ID:g9MeygUN0178NAME IS NULL
2018/01/01(月) 23:08:36.63ID:???よっぽど酷い人たちで開発してそう
0179NAME IS NULL
2018/01/01(月) 23:10:08.13ID:g9MeygUN0180NAME IS NULL
2018/01/01(月) 23:41:53.03ID:???履歴を記録しろと言い出す謎の勢力が襲い掛かってくる
0181NAME IS NULL
2018/01/01(月) 23:46:18.18ID:???（例えば売上とか）
そうじゃないなら必要性が理解できない
0182NAME IS NULL
2018/01/02(火) 00:05:50.83ID:???0183NAME IS NULL
2018/01/02(火) 00:21:32.94ID:???履歴が必要なら履歴とるように設計すればいい
履歴とるように設計されてないから苦労したとかならしらんから
運用の話は別スレでやってくれ
0184NAME IS NULL
2018/01/02(火) 00:28:00.40ID:???単にマスタじゃないデータという意味合いでトランザクションって言ってる場合があるけど
この場合は当然そのテーブルが更新されたりする
もっと狭い意味でトランザクションって言ってるなら、トランザクションなんだから追加しかありえないだろ
それを更新するとかありえないって設計もある
0185NAME IS NULL
2018/01/02(火) 07:23:53.00ID:???0186NAME IS NULL
2018/01/08(月) 07:44:30.25ID:???ＤＤＬは基本１件ずつしか触れないようにしといてほしかった
手動で操作するのこわい
0187NAME IS NULL
2018/01/08(月) 10:32:22.05ID:???業務でどんなSQLを実行してるんだ？
まあDMLにしても1件ずつとかありえんけどな
SQLは手続き型じゃないんだよ
0188NAME IS NULL
2018/01/24(水) 13:49:08.82ID:8ow/svL2末尾に追加しますか？それともデータ型やカラム名が合う場所に追加しますか？
くだ質ですが、気になるので教えてください。
0189NAME IS NULL
2018/01/24(水) 14:29:33.12ID:???0190NAME IS NULL
2018/01/24(水) 15:20:39.28ID:8ow/svL2問題はありません。
ですが、DB設計的に揃えるのが通常かな？と思いまして
0191NAME IS NULL
2018/01/24(水) 17:51:33.77ID:Hghj+DlTそもそも間に挿入できると思っているのか？
列順が変わることを想定していないプログラムへの影響、列順が違うのだけなのに運用を止める、データの移行のミス等、面倒なことばかりで普通はやらない。
0192NAME IS NULL
2018/01/24(水) 19:47:51.39ID:???さすがにそこまでは面倒見きれんw
0193NAME IS NULL
2018/01/24(水) 20:08:03.01ID:???実装上で問題があるケースってあるのかな？
0194NAME IS NULL
2018/01/24(水) 20:09:48.86ID:???0195NAME IS NULL
2018/01/24(水) 20:38:49.43ID:ibathY67http://rosie.5ch.net/test/read.cgi/liveplus/1516779817/l50
0196NAME IS NULL
2018/01/25(木) 16:14:20.92ID:???id,name,address,telephone,comment,date
だとする。そして「携帯電話」を追加したい。
こういった要件の場合、
id,name,address,tel,mobilephone,comment,date
ってしたくならないか？
id,name,address,telephone,comment,date,mobilephone
だとなんか納まりが悪いじゃん
0197NAME IS NULL
2018/01/25(木) 16:16:11.62ID:???id,name,address,telephone,mobilephone,comment,date
0198NAME IS NULL
2018/01/25(木) 16:22:13.38ID:???0199NAME IS NULL
2018/01/25(木) 17:12:08.82ID:???言いたいことはわかるけど、
本来リレーショナルデータベースにはそうした順序性が存在しない
0200NAME IS NULL
2018/01/25(木) 17:14:48.52ID:???いやだから、気になりませんか？って話です。
本質とかルールがどうこうではなく、心情的な面で。
0201NAME IS NULL
2018/01/25(木) 17:22:02.78ID:???そして集合には順序なんて概念はないの
0202NAME IS NULL
2018/01/25(木) 17:23:25.83ID:???もちろん、ユーザに見せるときにはSQLではなくプログラミング言語で調整しているよ
0203NAME IS NULL
2018/01/25(木) 17:25:46.44ID:???順序がないけど順序を視覚化しているツールを使っている時に、
カラム名やデータ型が異なる順番で並んでると気になりませんか？
単に気持ちの問題ならどうでもよくても、仕様書にした場合、
順序がバラバラだとミスや勘違いの原因になりやすいのではないでしょうか？
0204NAME IS NULL
2018/01/25(木) 17:30:24.66ID:???気にはなるけどリレーショナルデータベースとはそうしたもんだ
仕様とはまったく別の話
ある順序通りに列を並べたいというのが仕様にあればアプリ側で対応すべき話であって
その順序をDBに持ち込むことがおかしい
0205NAME IS NULL
2018/01/25(木) 17:32:15.39ID:???つまり、
>>196の要件で「携帯電話」を追加したい場合、
id,name,address,telephone,comment,date,mobilephone
で良いということですか？
これは順序も何も考えて無くて、単に末尾に追加しているだけです。
0206NAME IS NULL
2018/01/25(木) 17:38:50.08ID:???何度も言っているように、DBはそれで良い
というか、そこで順序にこだわることがおかしい
ユーザ側に見せる時には、プログラミング言語(JavaやC#やPHPでもなんでも)で調整すべき
0207NAME IS NULL
2018/01/25(木) 17:39:52.94ID:???0208NAME IS NULL
2018/01/25(木) 18:03:00.90ID:???0209NAME IS NULL
2018/01/25(木) 18:05:52.91ID:???仕様書なり設計書なりを見た人物（自分含む）が
誤認しないか？正しく伝わるか？と思ったからです。
過去にカラム追加が必要だと思ってたら、既にあったということがありました。
正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
とかく順序を意識して行いと、そういった不具合や誤認が生まれます。
リレーショナルデータベースとしては何が正しいか・正しくないかではなく、
扱うのは人間です。人間にわかりやすいのが一番だと思っています。
その上で出た疑問です。
0210NAME IS NULL
2018/01/25(木) 18:08:44.34ID:???という需要があったからこそ用意されたのではないでしょうか？
そうでなければ末尾でも良いわけです。
0211NAME IS NULL
2018/01/25(木) 18:12:05.73ID:???そういう整形はフロントエンドの役目
0212NAME IS NULL
2018/01/25(木) 18:13:18.10ID:???まさかと思うけど
リレーショナルデータベースをphpMyAdminで直接編集しようとしている？
(そんなはずはない、と思いたい)
>カラム追加が必要だと思ってたら、既にあったということがありました
というのは、単にモデリングの欠陥を言っているだけで、
>正規化しても1テーブルに100近いカラムが並ぶこともあるわけで、
これもよくあるアンチパターンで、1テーブル100カラムというのはほとんどが設計ミス
>人間にわかりやすいのが一番だと思っています
とか言い訳しているけど、単なる知識不足にすぎないのでは
0213NAME IS NULL
2018/01/25(木) 18:19:21.67ID:???「カラム位置のパフォーマンスへの影響ですが、一般的にRDBMSは可変長カラムを後ろに持っていった方が性能は良いです。可変長カラムより後ろのカラムに対しては、実際のデータ長を見て毎回オフセットを計算する必要があるためです。」
これを読み解くと、カラム位置って大事じゃないんですかね？
この回答者が間違っていると言われればそれまでですが。
0214NAME IS NULL
2018/01/25(木) 18:26:41.60ID:???これまでの君の主張は見た目の順序のことだから
的外れの突っ込みだぞ
0215NAME IS NULL
2018/01/25(木) 18:41:36.73ID:???別テーブル作ってそこにコピーしてリネームすれば
0216NAME IS NULL
2018/01/25(木) 18:54:38.23ID:???MySQLに順序変更に関するコマンドがある以上、
私の質問ってそんな的外れじゃないと思うんですけどね
「DBに順序という概念はない」っていう意味はわかりますけども。
0217NAME IS NULL
2018/01/25(木) 19:13:05.84ID:???>>216 の動機はやはり的はずれだと思うけど
みんなが言っているようにアプリで対応するのじゃ駄目なの？
0218NAME IS NULL
2018/01/25(木) 19:36:37.81ID:???最終更新日や削除フラグ(笑)の後ろに項目あると、ああ、あとから追加したんだなと切ない気持になる
ＤＢＭＳ的にはカラムは後ろにしか追加できない場合がほとんどだろうけど
ＧＵＩ系の管理ツールだとテーブル作り直して間に追加したかのごとくしてくれる物もあるぞ
0219NAME IS NULL
2018/01/25(木) 19:37:01.16ID:Kd6btbkDまた馬鹿が調子こいてでまかせ言ってたみたいだなw
迷惑かけてすまんのうw
×：「DBに順序という概念はない」
○：「関係モデルに順序という概念はない」
RDBMSの標準SQLでは定義された列の順番が存在する
よってお前の質問は全く的外れではないし
後から途中に列を挿入するという仕様変更も間違いではない
0220NAME IS NULL
2018/01/25(木) 19:40:17.60ID:???「DBに順序という概念はない」は216だけが言ってるんじゃないかな
そして標準SQLでは, 途中に列を挿入する処理は存在していないんじゃない？
0221NAME IS NULL
2018/01/25(木) 19:52:49.07ID:???少なくとも質問者である私は「DBに順序という概念はない」って言っていません。
回答者がそうおっしゃるから、自身の知識を改めただけです。
0222NAME IS NULL
2018/01/25(木) 19:55:46.45ID:???って思うだけです。自分も切なくなるから質問したわけですし。
かといってテーブル作り直すレベルまでもとめていません。
何度も書きますが、MySQLだとカラム同士の間に挿入できるわけですから。
ググっても「こうするべき」的な情報もないので質問したわけですが、
よくわからなくなってきました。もう半端な知識で適当に行きます。
みなさん、色々ありがとうございました。
0223NAME IS NULL
2018/01/25(木) 19:57:33.96ID:???>>216でそう言っているよね？ 正解は>>219の通りだけど
>>199 や >>201 や >>204 も, みんな同じことを言っていると思う
0224NAME IS NULL
2018/01/26(金) 02:01:50.61ID:???MySQLでしか通用しない小手先をもって「こうするべき」なんて言うやつおらんて
0225NAME IS NULL
2018/01/26(金) 02:15:25.24ID:???順序に拘る、気にするよりも設計に問題がなかったか見直した方が良いように思う
0226NAME IS NULL
2018/01/26(金) 02:18:38.09ID:???カラムの順番が重要視される会社で開発しているとしよう
同僚のコードはテストを通っていたが、マージはリジェクトされてしまった
あなたが先にマージしたコードのせいで、カラムの位置が不適切になったためだ
同僚はコードを修正する事より、規約を考えたあなたを殴る事を優先するだろう
0227NAME IS NULL
2018/01/26(金) 02:35:15.34ID:???心情的にはこれに同意だな
実務的な話をするなら、工程による。設計中なら、気の済むようにしたらいいけど、運用後の仕様変更だと、間に挟む為だけにテーブル作り直すとは客に説明できん..
MySQLは使ったことないけど、便利な機能があるんだな
0228NAME IS NULL
2018/01/26(金) 12:46:04.91ID:pxozcjcA後から追加した列だとわかるメリットもあるけどな。
0229NAME IS NULL
2018/01/26(金) 12:47:20.40ID:pxozcjcAそれたぶん見かけの問題だと思う。本当にできるとしたら、内部では作り直しをやっているはず。
0230NAME IS NULL
2018/01/26(金) 13:23:06.33ID:???たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
個人的に1対1の関係（必ずJOINする）ならテーブルを分ける必要ないと思います。
それは正規かと違うような。
>>226
会社で順番が重視されるとかはないかと。
ただ個人的に>>203のように思うだけなんで。
>>228
テーブル設計書に追加したカラムはどれか明記してますからね。
それでも確かに末尾に追加した方がわかりやすいとは思います。
DBはMySQL、PostgreSQL、SQLiteぐらいしか知らないので
SQL ServerとかAccessとかはどうかわかりません。
だから私の質問が「こいつ何言ってんだ？」レベルに感じたのだと思います。
0231NAME IS NULL
2018/01/26(金) 14:12:40.47ID:???>たとえば不動産のテーブル設計とか、カラム数が増えますからねぇ。
ここ詳しく
0232NAME IS NULL
2018/01/26(金) 15:30:10.66ID:???不動産販売会社の物件管理とか
賃貸マンションの入居者管理とか
あるいは資産としての不動産管理とか
0233NAME IS NULL
2018/01/26(金) 15:58:11.99ID:???0234NAME IS NULL
2018/01/26(金) 16:21:41.44ID:???あとはDESCしたときか
設計書上は途中の場所に書いておいて、DB上は末尾に追加しとくでいいじゃん
あと業務要件で都度カラムが増えるのはさすがに設計がおかしい
0235NAME IS NULL
2018/01/26(金) 16:28:53.58ID:???0236NAME IS NULL
2018/01/26(金) 20:41:14.34ID:???別にどんな分野でもいいけど、要件が変わってないのにカラム増えるのはさすがにおかしい
要件変更があれば当然増える事もあるだろう
0237NAME IS NULL
2018/01/26(金) 20:45:05.81ID:gcOPp+C3てか物理設計て言葉くらい覚えようねw
0238NAME IS NULL
2018/01/26(金) 21:53:37.57ID:HiY2mRrMhttp://rosie.5ch.net/test/read.cgi/liveplus/1516959000/l50
0239NAME IS NULL
2018/01/30(火) 17:06:10.21ID:???http://headlines.yahoo.co.jp/hl?a=20090319-00000026-tsuka-soci
この記事で問題になった通称やりすぎ防パトは、創価学会と警察署が引き起こしていたようです
掻い摘んで説明すると
・創価学会は、町内会や老人会、ＰＴＡ、商店会等の住民組織に関し、学会員が役員になるよう積極的に働きかける運動を
９０年代末から開始し、結果、多くの住民組織で役員が学会員という状況が生まれた
・防犯パトロールの担い手は地域の住民と住民組織で、防犯活動に関する会議や協議会には、住民組織の代表に役員が出席する為
防犯活動や防パトに、創価学会が間接的に影響力を行使可能となった
・防パトは住民が行う為、住民が不審者や要注意人物にでっち上げられるトラブルが起きていたが
創価学会はその緩さに目をつけ、住民組織を握っている状況を利用し、嫌がらせ対象者を不審者や要注意人物にでっち上げ
防パトに尾行や監視、付き纏いをさせるようになった
・防パトは地元警察署との緊密な連携により行われる為、創価学会は警察署幹部を懐柔して取り込んでしまい
不審者にでっち上げた住民への嫌がらせに署幹部を経由して警察署を加担させるようになった
・主に当該警察署勤務と考えられる創価学会員警察官を動かし、恐らく非番の日に、職権自体ないにもかかわらず
私服警官を偽装させて管轄内を歩いて回らせ、防犯協力をお願いしますと住民に協力を求めて回り
防犯とは名ばかりの、単なる嫌がらせを住民らに行わせた（防犯協力と称し依頼して回っていた警察官らの正体は恐らく所轄勤務の学会員警察官）
※これに加えて防犯要員が同様のお願いをして回る
・こうして防犯パトロールを悪用し、住民を欺いて嫌がらせをさせつつ、創価学会自体も会員らを動員し、組織的な嫌がらせを連動して行った
つまり警察署に勤務する学会員警察官、警察署幹部、創価学会が通称やりすぎ防犯パトロールの黒幕
詳細は下記スレをご覧下さい
やりすぎ防犯パトロールは創価学会と警察署の仕業だった
https://rio2016.5ch.net/test/read.cgi/bouhan/1516500769/
0240NAME IS NULL
2018/02/13(火) 16:59:54.49ID:???1対”0 or 1”は積極的に分割すべきかどうか検討した方がいいぞ
特にデータ量の多いテーブルは
意図的に非正規化した場合を除けば
カラム数が100を超えるようなテーブルは
本来別途管理すべきエンティティが埋もれてることが大半
0241NAME IS NULL
2018/02/14(水) 03:12:25.25ID:kUpzGWTPテーブルは意味のあるまとまりで作るのであって1：1だから、ひとつのテーブルにまとめてしまうのはかえって、同じテーブルのカラム同士の関連がわからなくなる。
0242NAME IS NULL
2018/02/14(水) 13:23:36.19ID:???改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
0243NAME IS NULL
2018/02/15(木) 19:48:19.21ID:L39WhMJw俺はおまえ、の日本語がわか、らなくなる
0244NAME IS NULL
2018/02/20(火) 15:44:48.62ID:???順次編成、ISAM VSAM
DB
項目つけるだけでしょ
それと関連性
0245NAME IS NULL
2018/02/20(火) 17:15:24.81ID:???扱いやすさが桁違い
Comparison of DB2 and VSAM
http://search400.techtarget.com/tip/Why-DB2-is-better-than-VSAM
0246NAME IS NULL
2018/02/20(火) 19:14:03.16ID:???(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど
0247NAME IS NULL
2018/02/21(水) 23:27:11.35ID:???Trに振りまら混ぜたりたいへんだから違うのはわかりますが
相当まーじとか冗談言っていた時代が懐かしいｗ
0248NAME IS NULL
2018/02/21(水) 23:29:59.45ID:???0249NAME IS NULL
2018/04/07(土) 17:29:50.05ID:???これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか？
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。
0250NAME IS NULL
2018/04/07(土) 17:51:30.32ID:???インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ
0251NAME IS NULL
2018/04/07(土) 18:32:05.17ID:???貸方か借方で違うテーブルに入るのはどうなのかな
0252NAME IS NULL
2018/04/25(水) 14:23:33.67ID:???そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな？
0253NAME IS NULL
2018/04/25(水) 17:25:06.73ID:0kFJEAdZコンピュータの仕組みを勉強してください。
0254NAME IS NULL
2018/04/27(金) 19:37:20.55ID:???未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね
0255NAME IS NULL
2018/04/28(土) 06:14:34.24ID:???問題起きたことないんか？
0256NAME IS NULL
2018/04/28(土) 10:38:35.05ID:???おじいちゃんなの？
そもそも問題ってなに？
0257NAME IS NULL
2018/04/28(土) 10:56:07.06ID:???今は2018年ですよ
0258NAME IS NULL
2018/04/28(土) 11:09:37.85ID:???こう？
0259NAME IS NULL
2018/04/28(土) 12:28:02.71ID:???0260NAME IS NULL
2018/04/28(土) 13:02:27.58ID:???0261NAME IS NULL
2018/04/28(土) 13:29:20.62ID:???もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな
0262NAME IS NULL
2018/04/28(土) 14:03:16.12ID:???http://www.mext.go.jp/b_menu/hakusho/nc/k19910628002/k19910628002.html
http://www.atmarkit.co.jp/news/200807/25/microsoft.html
0263NAME IS NULL
2018/04/28(土) 14:11:16.33ID:???これと個々のIT企業との関連は？
0264NAME IS NULL
2018/04/28(土) 14:14:36.67ID:???関係ないと思う
って言うような取引先なんて余計に不安になるだろ
0265NAME IS NULL
2018/04/28(土) 14:15:31.78ID:???なぜ？
0266NAME IS NULL
2018/04/28(土) 14:24:05.30ID:???みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。
常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。
0267NAME IS NULL
2018/04/28(土) 14:32:49.38ID:D5cEBG7Q0268NAME IS NULL
2018/04/28(土) 14:32:59.28ID:???常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ
0269NAME IS NULL
2018/04/28(土) 16:27:41.26ID:???つける派にもつけない派にも妙なこだわりがある人が混じってる
文化庁のやつにも慣例に応じて省略可能とちゃんと書いてある
https://ging.co.jp/tips/57001/
http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/gairai/honbun06.html
0270NAME IS NULL
2018/04/28(土) 16:36:14.55ID:???0271NAME IS NULL
2018/04/28(土) 18:13:36.79ID:???おおっっっそれは知らなかった！
0272NAME IS NULL
2018/05/12(土) 07:21:49.70ID:???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/
0273NAME IS NULL
2018/05/25(金) 21:13:08.94ID:Jccz1Fx2取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。
0274NAME IS NULL
2018/05/25(金) 21:15:53.50ID:???0275NAME IS NULL
2018/05/25(金) 21:21:20.27ID:Jccz1Fx20276NAME IS NULL
2018/05/25(金) 21:24:01.69ID:???0277NAME IS NULL
2018/05/25(金) 21:26:30.82ID:Z93MyXqjおまえ一人で共有しとけ
0278NAME IS NULL
2018/05/25(金) 21:34:37.41ID:???必要ないからdeleteしてるんでしょ？
0279NAME IS NULL
2018/05/25(金) 21:54:12.06ID:Jccz1Fx2それが必要だったから大トラブル
0280NAME IS NULL
2018/05/25(金) 22:01:35.26ID:Z93MyXqjというおはなしやな
少々笑えた
0281NAME IS NULL
2018/05/25(金) 23:10:40.85ID:???0282NAME IS NULL
2018/05/25(金) 23:17:56.83ID:TatbyLnb同じテーブルに残す方がわかりにくい。
0283NAME IS NULL
2018/05/25(金) 23:20:27.43ID:TatbyLnb実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。
0284NAME IS NULL
2018/05/25(金) 23:25:58.38ID:???例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している
0285NAME IS NULL
2018/05/25(金) 23:47:38.82ID:TatbyLnb言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。
単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。
0286NAME IS NULL
2018/05/26(土) 00:50:49.12ID:bRsNkwI2制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・
0287NAME IS NULL
2018/05/26(土) 06:48:26.89ID:???いやそれ削除フラグ云々以前のレベルやろ...
0288NAME IS NULL
2018/05/26(土) 07:04:47.67ID:n2n4g8U40289NAME IS NULL
2018/05/26(土) 08:11:25.72ID:bRsNkwI2削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる
0290NAME IS NULL
2018/05/26(土) 08:32:39.78ID:???0291NAME IS NULL
2018/05/26(土) 08:41:20.21ID:???削除フラグを見落として処理するコードが混入していて大混乱、とかね。
0292NAME IS NULL
2018/05/26(土) 09:43:20.38ID:bRsNkwI2それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。
0293NAME IS NULL
2018/05/26(土) 10:04:04.12ID:???0294NAME IS NULL
2018/05/26(土) 19:39:28.98ID:Pmk3UmpV同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。
0295NAME IS NULL
2018/05/26(土) 21:36:41.88ID:???ソース
0296NAME IS NULL
2018/05/26(土) 21:55:41.58ID:Pmk3UmpV集合演算子を知らない。
0297NAME IS NULL
2018/05/26(土) 22:16:19.76ID:???何言ってんのこいつｗｗｗ
0298NAME IS NULL
2018/05/26(土) 23:00:10.53ID:???そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話
これが理解できない奴が削除フラグの話をかきまわしてるだけ
0299NAME IS NULL
2018/05/26(土) 23:11:28.11ID:???0300NAME IS NULL
2018/05/26(土) 23:21:53.44ID:???0301NAME IS NULL
2018/05/27(日) 10:01:04.63ID:???0302NAME IS NULL
2018/05/27(日) 10:57:41.83ID:0Fr+f65wおまえの事やぞw
0303NAME IS NULL
2018/05/27(日) 11:14:49.09ID:???本人降臨乙w
0304NAME IS NULL
2018/05/27(日) 15:55:32.12ID:8hLmukSLステータスならフラグという持ち方は変。
0305NAME IS NULL
2018/05/27(日) 15:57:15.03ID:8hLmukSL0306NAME IS NULL
2018/05/27(日) 18:20:01.00ID:???状態がオン／オフしかないようなものならフラグでおかしくない
>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑
0307NAME IS NULL
2018/05/27(日) 21:18:51.26ID:8hLmukSL>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。
0308NAME IS NULL
2018/05/27(日) 21:20:22.92ID:8hLmukSLおまえ、ジジイだろ？
そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。
0309NAME IS NULL
2018/05/27(日) 21:25:12.75ID:???0310NAME IS NULL
2018/05/27(日) 22:50:53.39ID:Cl/1K8fEとにかく汎用機ジジイがリレーショナルデータベースを使うとこうなる。
またはExcelシートだと思っている素人が考えるとこうなる。
0311NAME IS NULL
2018/05/28(月) 12:33:38.94ID:JjIEU8hM0312NAME IS NULL
2018/05/28(月) 21:04:44.29ID:ZV4d+P4dリレーショナルデータベースをExcelと同じようなものと考えている人は多いぞ。
0313NAME IS NULL
2018/05/28(月) 22:09:34.92ID:HWd426F6一つの項目がステータスを表し、0〜9の値を持ち、2と7が削除扱いという設計を見たことがある。
2が取引先からのキャンセル、7がこちら都合のキャンセル。
嫌になった。
0314NAME IS NULL
2018/05/31(木) 21:41:41.10ID:???毎日の価格はどういうテーブルにしたらいいですか？
0315NAME IS NULL
2018/05/31(木) 21:59:40.22ID:???itemテーブルはそんなものだろうと思う。
毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う
0316NAME IS NULL
2018/05/31(木) 22:14:59.09ID:???価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。
0317NAME IS NULL
2018/05/31(木) 22:20:51.12ID:???それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね
0318NAME IS NULL
2018/05/31(木) 22:23:34.53ID:???0319NAME IS NULL
2018/05/31(木) 22:26:08.06ID:???記録したい項目をテーブルに用意して終わりでしょう
0320NAME IS NULL
2018/05/31(木) 23:07:07.03ID:???item_id
high_price
low_price
date
他に必要な項目があれば追加
0321NAME IS NULL
2018/06/01(金) 04:08:11.91ID:???プライマリキーは要らないんですか？
あとテーブル名ってどんな感じに付けますか？
0322NAME IS NULL
2018/06/01(金) 04:10:01.84ID:???どうしてもキーを付けるなら、
一意になりそうな日付かな？
テーブル名はお好きにどうぞ
0323NAME IS NULL
2018/06/01(金) 11:25:16.22ID:???チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)
select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日
0324NAME IS NULL
2018/06/01(金) 14:29:47.30ID:???そうだね、一意にするためには日付だけではなく
itemIDとセットにしないといけなかった
0325NAME IS NULL
2018/06/01(金) 21:03:43.61ID:???0326NAME IS NULL
2018/06/01(金) 21:04:55.21ID:???同じ果物が何度も売れてもいい
0327NAME IS NULL
2018/06/01(金) 21:48:46.17ID:???0328NAME IS NULL
2018/06/01(金) 22:16:10.56ID:???0329NAME IS NULL
2018/06/01(金) 22:30:46.29ID:???要件そのまま聞くとまあ後でおかしくなるよ
この場合だと、その日の最後に入力するので取引実績をメモしておかないといけないんだけどめんどくさい、だとか
最大最小を計算するのめんどくさいからどうにかして、といった具合
0330NAME IS NULL
2018/06/01(金) 23:15:49.45ID:???0331NAME IS NULL
2018/06/02(土) 00:24:27.89ID:gAkF9Xc40332NAME IS NULL
2018/06/02(土) 00:54:08.86ID:???insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる
0333NAME IS NULL
2018/06/02(土) 01:03:54.25ID:???それだと、レコード一つだけ見たときにそｒが最高値か最安値か分からないだろう
0334NAME IS NULL
2018/06/02(土) 07:10:37.22ID:???0335NAME IS NULL
2018/06/02(土) 07:36:22.88ID:???どうやったらこんなアホな発想に至るんだろう...
0336NAME IS NULL
2018/06/02(土) 07:39:23.98ID:???>>323
0337NAME IS NULL
2018/06/02(土) 07:44:01.56ID:???どう見てもidがキーとわかる
果物idと日付をキーにする派閥もあるが
後で見た人は同じ日に同じものが売れたらどうなるんだ？と疑問を感じざるをえない
0338NAME IS NULL
2018/06/02(土) 07:44:49.55ID:???せめて反論の形にしないと敗北宣言と同じだよ？
0339NAME IS NULL
2018/06/02(土) 07:48:00.32ID:???基本中の基本
最大値や最小値を1行に保存するということはこれに反する
統計値とは複数の事実から導き出されるものだからだ
0340NAME IS NULL
2018/06/02(土) 07:49:44.49ID:???え゛っ、マジで言ってるの？
値を参照するだけで>>323相当のSQL要るし、既に>>320みたいなまっとうな例もでてるのに w
0341NAME IS NULL
2018/06/02(土) 07:53:31.65ID:???基地害ｷﾀ━(ﾟ∀ﾟ)━!
0342NAME IS NULL
2018/06/02(土) 07:55:18.85ID:???統計値を参照するのに集計クエリが要るのは正常
>>320はまっとうじゃないよ
手作業で出した集計値を保存するという暗黙の手続きの上にかろうじて成立しているだけ
それと試しにこのテーブルにまっとうな名前をつけてみなさい
0343NAME IS NULL
2018/06/02(土) 07:55:39.30ID:???>>338
0344NAME IS NULL
2018/06/02(土) 08:01:53.58ID:???彼らは形式しかみないから>>320のような歪なテーブルを受け入れてしまうがそれはダメだ
意味的にも正しく正規化すべきだ
0345NAME IS NULL
2018/06/02(土) 08:05:20.94ID:???はっきりさせるべきだな。
0346NAME IS NULL
2018/06/02(土) 08:13:57.12ID:???「正規化」って用語を「正しいテーブル設計」の代名詞みたいに使う人は相変わらずいるねぇ。
意味的に正しい正規化ってなんだろう。
0347NAME IS NULL
2018/06/02(土) 08:19:27.67ID:???要件を間違えてる
「高値/安値を求める」のではなく「求められた高値/安値を記録」するってこと ⇒ >>316
統計関係ない
テーブル名？
果物取引実績 とかでいいだろ w
0348NAME IS NULL
2018/06/02(土) 08:21:54.17ID:???おまいら健康的だな
0349NAME IS NULL
2018/06/02(土) 08:22:47.57ID:???第一正規化とか でググれ
１つの列に>>332みたいに違う意味の情報を入れるのは最悪の設計であることがわかると思う
0350NAME IS NULL
2018/06/02(土) 08:32:59.12ID:???例えばhoge(id, foo_1, foo_2, foo_3)のようなテーブルは形式的には正規形だが意味的にはおかしなことだ
古いエンジニアは平気でこういうテーブルを書いてしまう
集計値を格納するのも同様に形式しか見ずに設計した酷いテーブル構造だ
0351NAME IS NULL
2018/06/02(土) 08:33:46.46ID:???>>332は属性の意味が定まらんという、正規化以前の問題。
0352NAME IS NULL
2018/06/02(土) 08:37:51.48ID:???だから、形式的に正規形だったら正規形なんだよ。意味的におかしいというのは別の話。
それを「正しい正規形じゃない」と言うのが変なだけ。
0353NAME IS NULL
2018/06/02(土) 08:54:32.67ID:???記録するという行為の本質を見誤ってるな
Aという事実から直ちにBという事実が導き出される場合に
Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
Aを記録したからといってBを記録していないということにはならない
例えば歩く速度と歩いた時間を記録すれば歩いた距離も記録したも同然だな
それと同じでここの取引価格を記録するということは同時に最安値・最高値を記録することでもある
要件には全く反していないということだな
それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
まっとうなテーブルじゃないからまっとうな名前をつけられない
0354NAME IS NULL
2018/06/02(土) 09:00:43.48ID:???あくまで苦肉の策だということ
手作業で集計値を出すまでに個々のデータは必ずあるのだから、その個々のデータを入れるのが正しいあり方だ
しかし、どうしても最安値・最高値だけ保存してそれ以外は手作業で計算したいという奇特なユーザーのためにこういう手もないことはないと提示しただけ
ちなみにこの最高値・最安値のレコードだけを登録する回避策は厳密には間違いではない
なぜなら最安値の取引実績も最高値の取引実績も実際に存在する事実だからだ
間違いがあるとすれば他にも存在したはずの事実の記録を怠った運用の仕方にある
0355NAME IS NULL
2018/06/02(土) 09:05:34.37ID:???完璧に定まってる
いつ、何が、幾らで取引された、という事実を単純明快に表している
そして、それぞれの事実を識別するための最もシンプルな手段であるidを導入した
時刻はアイデンティティを示すキーの一部にはならない
0356NAME IS NULL
2018/06/02(土) 09:07:03.57ID:???0357NAME IS NULL
2018/06/02(土) 09:07:23.66ID:???それは派閥による
セルコは意味的な部分にも踏み込んで正規化としているね
0358NAME IS NULL
2018/06/02(土) 09:11:43.30ID:???くだらないレスはやめよう
歩いた距離と時間を記録すれば速度を記録したようなものだ
これで速度計は不要になったね
次はなんだ？時計がないってか？
付き合いきれん
0359NAME IS NULL
2018/06/02(土) 09:12:48.97ID:???> Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
だから中途半端な>>332はバカだって言う話な
> それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
> まっとうなテーブルじゃないからまっとうな名前をつけられない
>>332に言ってやれよ w
0360NAME IS NULL
2018/06/02(土) 09:14:38.57ID:???必要もないのに苦肉の策をとるバカ乙
0361NAME IS NULL
2018/06/02(土) 09:27:03.02ID:???ここらで決着かな
0362NAME IS NULL
2018/06/02(土) 09:36:48.83ID:???そう？
少なくとも「プログラマのためのSQL」じゃ形式的な正規形についてしか説明していないようだけど。
曰く
「正規形は、データベースで真のデータを破壊したり、偽のデータを作成したりすることがないように
しようというのが目的です。」
0363NAME IS NULL
2018/06/02(土) 10:02:51.95ID:???> 言い返せなくなると罵倒する
> ここらで決着かな
ひょっとして「必要もないのに」って言われてる意味がわかってないとか？
てか既に決着してるだろ w
0364NAME IS NULL
2018/06/02(土) 19:53:26.96ID:???0365NAME IS NULL
2018/06/02(土) 20:25:43.70ID:gAkF9Xc40366NAME IS NULL
2018/06/03(日) 17:50:56.72ID:???>>345
>>320さんを参考に
テーブル作ってみたんですが
https://ideone.com/y6urpx
itemテーブルに同じ名前で重複してかきこまれてしまいます。
0367NAME IS NULL
2018/06/03(日) 18:21:59.24ID:???取引した日付と商品IDで重複しなくなるから、
その二つを使ってPrimary Keyを指定する。
PRIMARY KEY(`transaction_date`,`items_id`),
#varcharって書くと、サイズ1になるんだっけ？
0368NAME IS NULL
2018/06/05(火) 01:29:12.15ID:G6hVbWAVprimary key にすれば自動的にunique制約されるんですね
0369NAME IS NULL
2018/06/05(火) 13:48:16.07ID:???それをキーにして何通りも取得できたら
おかしいことになるだろうし
0370NAME IS NULL
2018/06/09(土) 06:56:35.90ID:Icn+Lx+K未回答は、nullを想定しますか？0を想定しますか？
理由も教えてください！
0371NAME IS NULL
2018/06/09(土) 07:24:58.49ID:???0372NAME IS NULL
2018/06/09(土) 08:20:27.48ID:???0373NAME IS NULL
2018/06/09(土) 10:32:23.91ID:???0374NAME IS NULL
2018/06/09(土) 17:01:40.73ID:???事前に決めた値で問題ないならそうするかもしれんが
まあnullだな
0375NAME IS NULL
2018/06/09(土) 18:03:57.54ID:hcbikbxQ0376NAME IS NULL
2018/06/09(土) 18:27:03.88ID:Icn+Lx+KQ1 性別 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のどちらを使うかです
0377NAME IS NULL
2018/06/09(土) 18:44:19.45ID:???0378NAME IS NULL
2018/06/09(土) 18:55:06.75ID:???未回答を避け、こういう選択肢を用意すると言うのも方法だと思う
0379NAME IS NULL
2018/06/09(土) 18:56:49.19ID:???どうせしばらく経ったら丸ごと捨てるんだろ？
0380NAME IS NULL
2018/08/11(土) 20:14:14.25ID:HUdhIw+bカラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん
最高値と最安値はその都度、SQL文書いて取り出せばよくない？
MaxとMinをいちいち記録する必要ある？
複雑化するだけじゃん。
0381NAME IS NULL
2018/08/11(土) 20:15:06.24ID:???最大、最小しかデータ入れられないのか
糞レスしてごめん
0382NAME IS NULL
2018/08/11(土) 20:48:43.90ID:???0383NAME IS NULL
2018/08/12(日) 01:13:04.21ID:444bh0X0ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。
最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。
0384NAME IS NULL
2018/08/18(土) 19:03:47.85ID:???日替わりのタイミングで取得して別テーブルに登録したいね
0385NAME IS NULL
2018/08/23(木) 20:53:10.04ID:5PrJS+b60386NAME IS NULL
2018/08/26(日) 10:09:20.42ID:???0387NAME IS NULL
2018/08/26(日) 10:12:25.44ID:l1qaluN3実際は、運用や移行無視の機能要件しか満たさないような設計も多い。
テスト工程の終盤で気付いて火を噴く
0388NAME IS NULL
2018/08/27(月) 03:53:49.73ID:???統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる？
0389NAME IS NULL
2018/08/27(月) 07:07:36.29ID:???0390NAME IS NULL
2018/08/27(月) 22:01:12.24ID:Ee+4ykO9データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。
0391NAME IS NULL
2018/08/28(火) 06:28:49.33ID:???データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う
0392NAME IS NULL
2018/08/30(木) 23:28:39.42ID:YS+AC+kz最初は別のテーブルにしようと思ったのですが、
1対1の関係であるため、ひとつにまとめた方が良いのではないか？と悩んでいます。
0393NAME IS NULL
2018/08/30(木) 23:32:31.99ID:lHt449yM改修コスト見合いだが
将来にわたり1:1ならいいんじゃね
0394NAME IS NULL
2018/08/30(木) 23:41:15.81ID:???0395NAME IS NULL
2018/08/30(木) 23:45:46.14ID:YS+AC+kzありがとうございます。分ける方法もよくあるんですね
0396NAME IS NULL
2018/09/03(月) 03:03:59.17ID:xugX4t13どちらかというと分けた方がいい。
あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。
カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。
コボラーさんや頭が古いひとはカラムを追加したがる。
0397NAME IS NULL
2018/09/03(月) 06:44:35.34ID:???まとまりに意味があるからテーブル分けろ？
他に理由ないならバカとしか思えない
0398NAME IS NULL
2018/09/03(月) 07:49:30.05ID:8k7Ekz6C0399NAME IS NULL
2018/09/03(月) 10:15:56.89ID:???象とはこういうものだと言い合っている絵を
思い浮かべる議論だな
0400NAME IS NULL
2018/09/03(月) 20:46:20.70ID:xugX4t13仏教徒か。仲間だな。
0401NAME IS NULL
2018/09/04(火) 19:00:44.56ID:PCCrVc8pコボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。
0402NAME IS NULL
2018/09/04(火) 19:13:28.23ID:NpqdKDu5つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。
0403NAME IS NULL
2018/09/04(火) 20:02:08.75ID:???JCLでレコード長の数字を弄らんといかんようになるからな w
0404NAME IS NULL
2018/09/04(火) 21:09:30.08ID:???0405NAME IS NULL
2018/09/05(水) 08:27:53.10ID:1yHvak3l0406NAME IS NULL
2018/09/05(水) 12:14:38.49ID:sxBfz2nK0407NAME IS NULL
2018/09/05(水) 21:29:08.15ID:???0408NAME IS NULL
2018/09/05(水) 23:49:38.89ID:w+IuU8zi0409NAME IS NULL
2018/09/06(木) 11:24:17.20ID:???0410NAME IS NULL
2018/09/06(木) 14:27:57.81ID:GycufIMP？
0411NAME IS NULL
2018/09/06(木) 18:52:24.46ID:???レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね
0412NAME IS NULL
2018/09/06(木) 22:15:09.33ID:???0413NAME IS NULL
2018/09/06(木) 23:46:24.34ID:???ただ計測したらそうなった
0414NAME IS NULL
2018/09/07(金) 19:37:22.26ID:KGOTOtzdそれは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか？
0415NAME IS NULL
2018/09/07(金) 19:58:59.63ID:KGOTOtzdレコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。
0416NAME IS NULL
2018/09/07(金) 20:01:04.05ID:???連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと？
0417NAME IS NULL
2018/09/07(金) 21:15:09.98ID:cf7Dw2jW0418NAME IS NULL
2018/09/09(日) 09:06:55.49ID:???SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
（個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで）
この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
（もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる）
0419NAME IS NULL
2018/09/09(日) 11:14:36.11ID:???0420NAME IS NULL
2018/09/09(日) 12:57:35.94ID:???まあ不定要素多すぎて何とも言えんけど
それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話
ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと
0421NAME IS NULL
2018/09/10(月) 14:21:33.58ID:???要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん
0422NAME IS NULL
2018/10/06(土) 14:35:50.55ID:Kml7Tt+s0423NAME IS NULL
2018/10/06(土) 16:33:44.55ID:i1VqU+gz・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄
これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。
0424NAME IS NULL
2018/10/06(土) 18:20:10.06ID:???趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか
0425NAME IS NULL
2018/10/13(土) 19:44:09.60ID:???0426NAME IS NULL
2018/10/14(日) 20:23:24.26ID:???『憲法改正國民投票法』、でググってみてください。
（へいわ）は、勝ち取るものです。拡散も含め、お願い致します。
0427NAME IS NULL
2018/10/14(日) 20:53:15.89ID:XnVgDh+Y戦争反対！
0428NAME IS NULL
2018/10/17(水) 23:43:26.92ID:???主キー 会員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日で日本全国で百万レコードとか行っちゃいますよね？
何かいい手があるんでしょうか？毎日テーブルを作ってるのかな？
0429NAME IS NULL
2018/10/17(水) 23:52:23.40ID:???何の為にDBに登録するのか、その目的次第だと思う
小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか
0430NAME IS NULL
2018/10/18(木) 00:21:22.13ID:tCAmet/Z例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない
0431NAME IS NULL
2018/10/18(木) 01:28:56.96ID:NAGDWV1s取る取る、もっと細かく取るよ。
0432NAME IS NULL
2018/10/18(木) 01:47:15.31ID:???個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな
0433NAME IS NULL
2018/10/18(木) 06:59:59.61ID:???> 1日で日本全国で百万レコードとか行っちゃいますよね？
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
１億レコード超えたら本気出す
0434NAME IS NULL
2018/10/18(木) 07:03:00.50ID:???0435NAME IS NULL
2018/10/18(木) 07:33:05.12ID:???「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの？テーブルを365個SQLに書かなきゃダメ？
0436NAME IS NULL
2018/10/18(木) 16:22:23.06ID:???購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ
0437NAME IS NULL
2018/10/18(木) 23:03:46.70ID:???0438NAME IS NULL
2018/10/18(木) 23:29:31.96ID:???数億人が毎日見てるんだぜ？考えるとすごくね？しかも検索結果の抽出も早いしどうなってんだ
0439NAME IS NULL
2018/10/19(金) 03:14:59.08ID:???0440NAME IS NULL
2018/10/20(土) 17:50:10.77ID:???0441NAME IS NULL
2018/10/20(土) 17:51:48.84ID:???0442NAME IS NULL
2018/10/23(火) 20:01:35.00ID:???検索にかかる時間は0,1mmのデータのたかだか４２倍
0443NAME IS NULL
2018/10/23(火) 22:33:49.87ID:hntOGwbv0444NAME IS NULL
2018/10/23(火) 22:45:12.23ID:???0445NAME IS NULL
2018/10/23(火) 22:45:58.51ID:???0446NAME IS NULL
2018/10/24(水) 01:29:31.23ID:???蛇腹だとたしかに月までどころか5mmにもならん
0447NAME IS NULL
2018/10/24(水) 01:45:22.86ID:???0448NAME IS NULL
2018/10/25(木) 03:15:40.01ID:???0449NAME IS NULL
2018/10/25(木) 09:51:00.34ID:???0450NAME IS NULL
2018/12/13(木) 23:16:46.44ID:Ht+aqMlR0451NAME IS NULL
2018/12/26(水) 10:07:27.12ID:IDBXTEXd0452NAME IS NULL
2019/03/20(水) 08:24:10.88ID:???0453NAME IS NULL
2019/03/30(土) 17:46:10.62ID:???DBMS何使ったらそうなんの？オラコー？
0454NAME IS NULL
2019/03/30(土) 17:52:56.67ID:klkn0vtv10明細x50の伝票！あと10年は変更ありません！
とかだとよくやる。官公庁だあとありがち。
正規化するといちいちJOIN書かないといかんし
0455NAME IS NULL
2019/03/30(土) 19:41:39.53ID:???見たのは確かOracle
項目多過ぎでSQLが実行できない
0456NAME IS NULL
2019/03/30(土) 22:37:17.45ID:???0457NAME IS NULL
2019/05/31(金) 20:09:56.83ID:h9fg3gjJ問題なのが、このテーブルはレコードを削除した後、復活(再度、新規登録)させる必要が出てくる可能性があることです。
その場合、復活させた時に番号が変わるserialを主キーにするのは、ありえないですよね？
0458NAME IS NULL
2019/05/31(金) 20:48:12.74ID:???それ以前におれなら復活必要なら論理削除にしとくが
0459NAME IS NULL
2019/05/31(金) 23:33:17.50ID:???0460NAME IS NULL
2019/06/04(火) 20:14:47.94ID:???ここで言ってるserialってのは、システム側で管理して勝手に数値入れてくれるものだと思うが
0461NAME IS NULL
2019/06/04(火) 20:52:02.44ID:???>>457のように一意性を保証する複合主キーが存在したうえでその代理とするのがサロゲートキー。
んだから元の複合主キーとserialからなるのがマスターだしそれが自動採番されることは矛盾しない。
0462NAME IS NULL
2019/06/04(火) 21:03:46.49ID:???自動採番（システム管理）される値をサロゲートキーにするって前提じゃないの？
0463NAME IS NULL
2019/06/04(火) 21:33:06.85ID:???>>457のようにデータ再投入時にサロゲートキーの値が変わるのを防ぎたいなら
そういうマスターを残しておけばいいという話。
採番が自動か手動かはこの際関係ない。
0464NAME IS NULL
2019/06/05(水) 00:34:03.47ID:???そういうマスターを残すには手動でそういうマスターを作らないとダメなわけで
前提を合わす気がないならちゃんとそういっとかないと議論にならん
0465NAME IS NULL
2019/06/05(水) 00:38:31.46ID:???その様な使い方を別なところでしているんじゃないかな
ログとか履歴とか
0466NAME IS NULL
2019/06/05(水) 08:10:00.40ID:???既に何度も書いているが、そのマスターのサロゲートキーはserialで自動採番して全然問題ないんだが？
あるいは、もともとデータテーブルが1テーブルだったものをマスターテーブルと分離したことを言っているなら
そりゃ当たり前だ。そう提案したんだからな。
0467NAME IS NULL
2019/06/26(水) 12:08:55.23ID:???ついて、原因を特定したと明らかにした。米オラクル（Oracle）のデータベース（DB）ソフト
「Oracle Database」のバグが原因だった。
https://egg.5ch.net/test/read.cgi/bizplus/1561468154/
0468NAME IS NULL
2019/06/26(水) 12:32:28.72ID:???ろくに保守サポートされないんだから有料契約の意味がない
0469NAME IS NULL
2019/06/26(水) 19:39:47.63ID:???突き止めることすら自前でやらなきゃならんのだぜ。
0470NAME IS NULL
2019/06/26(水) 19:52:43.63ID:???責任転嫁のための作業であって
復旧にはどのみち問い合わせじゃ間に合わん
0471NAME IS NULL
2019/06/26(水) 20:14:47.85ID:???「たまたまエラーになったけど原因がわからないからまた起きたらゴメンね。」で済むような仕事ならいいが。
0472NAME IS NULL
2019/06/27(木) 18:25:28.42ID:???あとは直ればラッキーぐらい
0473NAME IS NULL
2019/07/14(日) 19:52:47.78ID:???> 8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜む
> バグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。
> 米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。
https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/070200035/
0474NAME IS NULL
2019/07/14(日) 20:10:01.55ID:???0475NAME IS NULL
2019/07/15(月) 19:18:49.04ID:???0476NAME IS NULL
2019/07/28(日) 18:04:07.13ID:???0477NAME IS NULL
2019/08/21(水) 20:28:50.39ID:???値の組み合わせ全部入れるもんなの？
null値はすべての検索値にマッチとかルール決めて行数減らしたけど
わけわかめになった
0478NAME IS NULL
2019/09/01(日) 05:17:00.26ID:Kcb9iNar後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか？
※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。
0479NAME IS NULL
2019/09/01(日) 06:36:54.70ID:???その意味のない商品コードとやらで何をしたいんだ？
商品名と価格だけでいいだろ
0480NAME IS NULL
2019/09/01(日) 09:57:23.82ID:e+zeE2vd商品マスタに有効期間を作るのが定石かなあ
ついでに言うと当時の単価もマスタ側で
売り上げは数量かなあ
（集計用に金額持たせることはある）
あと消費税の扱いをどうするかとか考えておいたほうがいい
0481NAME IS NULL
2019/09/01(日) 16:19:32.45ID:???自分ならというか自分が作ったシステムの売上データは個数、単価、価格などを保持してる
マスタから参照するのはコードと商品名ぐらい
マスタのコードは別の商品に変わる可能性があるなら売上データと商品マスタを結合するキーは
商品コードでなく商品マスタのサロゲートキー
0482NAME IS NULL
2019/09/01(日) 16:38:47.41ID:???これがどういう状況を表しているのかはっきりさせないと設計も決められないだろ。
少なくとも「商品コード」で「商品」を特定できないことは読み取れるが、じゃあ
「商品コード」と「商品名」であれば特定できるのかそれともそうじゃないのか。
できるなら>>478のままでいいが、できないならばそれを特定できる情報を
追加しなければならない。
0483NAME IS NULL
2019/09/01(日) 16:51:19.34ID:???0484NAME IS NULL
2019/09/01(日) 17:30:57.16ID:???変更するって話とは全然違うわな。
0485NAME IS NULL
2019/09/01(日) 17:43:49.61ID:???商品コードを仕入れ先の企業が決めてくるって事？
0486NAME IS NULL
2019/09/01(日) 17:54:03.12ID:???0487NAME IS NULL
2019/09/02(月) 04:29:38.29ID:???もし本当に
>売り上げに登録する商品は、商品コードと商品名と価格だけで管理する
のならば、全情報コピーでいいだろ
現実的にはそんな単純な管理条件にはならんけどな
0488NAME IS NULL
2019/09/02(月) 12:28:21.25ID:???> 現実的に、商品コードが一意にならないような要求をする客はいるぞ
そりゃいるだろうよ
だから外部とやり取りするためのコードと内部で処理するためのコードは別に持ったりする
0489NAME IS NULL
2019/09/02(月) 15:56:14.03ID:???0490NAME IS NULL
2019/09/20(金) 22:43:01.69ID:isalmAv1ラックに限らずクラスタリングってもしもの時のバックアップとしては全く信用できない。
基本的に運が良ければダウン時間が短く済むかも程度で考えて、データのみ同期させる予備機もっとかないと。
0491NAME IS NULL
2019/10/13(日) 18:20:24.07ID:???でもPHPでカラムを見ながら弄りたい
PHPやらhtmlでいちいち書くのは面倒くさい
ってんで、カラムの名前の日本語対応データだけもったtable作る
ってのは変ですか？
0492NAME IS NULL
2019/10/15(火) 01:36:43.91ID:???0493NAME IS NULL
2019/10/15(火) 16:59:26.48ID:???ありがとうございます
論理名 物理名というのですね
参考になる文献が結構出てきて助かりました
0494NAME IS NULL
2019/10/16(水) 07:52:35.26ID:???0495NAME IS NULL
2019/10/16(水) 19:46:46.29ID:vHJKi6he項目名が頻繁に変わるという仕様が本当に必要なのか考えた方がいい。
0496NAME IS NULL
2019/10/17(木) 01:46:16.06ID:???0497NAME IS NULL
2019/10/17(木) 06:45:02.27ID:???> カラムの名前の日本語対応データだけもったtable作る
ってところじゃね？
0498NAME IS NULL
2019/10/17(木) 23:46:22.91ID:/2joG6dPウーバーイーツの利用者が初めての方は eats-5kqyfp のプロモーションコードを使うと、#Uber Eats の初回注文が ￥1,000 割引になります。https://t.co/Wxur8AeoEf 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01)
0499NAME IS NULL
2019/10/18(金) 04:25:29.95ID:???例えば、
歴史的建造物のテーブルと
国のテーブルが有るとします
建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか？
この入力段階では建造物テーブルにリレーション？や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか？
0500NAME IS NULL
2019/10/18(金) 09:22:20.96ID:???0501NAME IS NULL
2019/10/18(金) 19:29:58.26ID:d6MIxLxf建造物情報と国情報が紐付いてないのに、なぜ「オートコンプリート」という言葉が出てくるのか？
0502NAME IS NULL
2019/10/18(金) 21:21:09.59ID:???0503NAME IS NULL
2019/10/20(日) 20:29:56.45ID:???法隆寺は日本にしかないだろうに
国を入力したら、建物のリストを候補にだすってんなら、国と建物の紐づけが必要
0504NAME IS NULL
2019/10/20(日) 20:53:49.69ID:???0505NAME IS NULL
2019/10/20(日) 21:37:50.26ID:???0506NAME IS NULL
2019/10/22(火) 21:34:40.81ID:???0507NAME IS NULL
2019/10/22(火) 21:43:02.01ID:???＞入力操作の軽減を図る機能の一つである。
＞オートコンプリートに対応したソフトでは、ユーザーが入力したい言葉の
＞冒頭の文字を入れると、入力履歴の中から冒頭の文字が一致するものを
＞候補として一覧で表示する。候補は、文字を入力していくごとに絞り込まれ、
＞その一覧の中に入力したい言葉があれば、ユーザーは残りの文字を入力
＞することなく、一覧から選ぶだけで入力が完了する。
こういうことなんじゃ？
0508NAME IS NULL
2019/10/22(火) 22:57:39.65ID:???>>503
>>506
>建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
0509NAME IS NULL
2019/10/23(水) 09:25:30.42ID:CtOyw4yfだからどうしてそんな変なことを言っているのか？
0510NAME IS NULL
2019/10/23(水) 15:59:50.08ID:???0511NAME IS NULL
2019/10/23(水) 19:36:46.50ID:???おまえ読解力無さすぎだろう
0512NAME IS NULL
2019/10/23(水) 19:45:44.83ID:???誰でも考えつくことだし
0513NAME IS NULL
2019/10/23(水) 20:18:26.30ID:???・国名入力欄
・建造物名入力欄
があって、「国名入力欄に入力する際に国名をオートコンプリートしたい
（“に”って入力したら“日本”が候補にでてくる）」って認識でOk？
それとも「国名を入力したら建造物名入力欄の候補が絞り込まれる」ようにしたいってことを言ってる？
0514NAME IS NULL
2019/10/23(水) 20:43:21.25ID:???>オートコンプリート用国候補のデータ
こう書いてあるんだから普通わかるだろ。
0515NAME IS NULL
2019/10/23(水) 22:00:30.83ID:CtOyw4yf0516NAME IS NULL
2019/11/04(月) 00:05:11.75ID:???書いてあることを読めなかったりします
私もそうだから、よく分かります
0517NAME IS NULL
2019/11/22(金) 17:14:44.84ID:kYOxBcYUという条件だとします。
このとき、finiteカラム（int）が99であれば、99回利用できるとします。
利用するごとに1ずつ減っていくイメージです。
では、「無制限に利用できる」を表現したい場合、finiteカラムでできるのでしょうか？
それとも、infiniteカラムなどを追加し、そこが1（有効）のユーザーは
無制限に利用できるというような、フラグ的な使い方をすればいいのでしょうか？
どう設計するのがベストプラクティスかわかりません。教えて下さい。
0518NAME IS NULL
2019/11/22(金) 17:19:37.29ID:???finiteが -1 なら無制限ユーザーとする、とか
0519NAME IS NULL
2019/11/22(金) 19:58:57.97ID:???とりあえずfiniteにNULLでいいだろ
NULLから1引いてもNULLだからな
0520NAME IS NULL
2019/11/22(金) 20:52:28.55ID:???0521517
2019/11/22(金) 21:24:33.78ID:???なるほど。-1って考えはありませんでした。
聞いたことありませんが良さそうですね。
>>519
int型のカラムにNULL入れちゃうのは抵抗があります・・・
0522NAME IS NULL
2019/11/22(金) 21:49:00.10ID:???あとで利用回数調べたりしがちだから
基本、利用上限＞利用回数で判定して
運用上、アホみたいに利用されないなら
利用上限をintのMAX_VAlUEとかにしとけば
実質無制限になるし、同じ判定で済む
0523517
2019/11/22(金) 23:00:06.56ID:???なるほど。その方が汎用性がありますね。
利用上限も制限がある場合は1〜99まで
無制限なら999とかにしておけばわかりやすいです。
-1だとorderの並び替えも難しいですが、999ならできますし
0524NAME IS NULL
2019/11/22(金) 23:21:12.77ID:???いや、できるよ
0525NAME IS NULL
2019/11/23(土) 21:33:05.59ID:???0526NAME IS NULL
2019/11/26(火) 17:10:04.54ID:???0527NAME IS NULL
2019/11/28(木) 13:21:29.42ID:j6IzqXGNどんなスキーマにしておくと後々使えるでしょうかね．
0528NAME IS NULL
2019/11/28(木) 20:58:42.03ID:???HTML ｖarchar(max);
);
0529NAME IS NULL
2019/11/28(木) 21:14:57.24ID:???0530NAME IS NULL
2019/11/29(金) 09:41:54.28ID:???ttps://monstermap.org/data/20191129.html
みたいなURLじゃなくて，その中身です．
名前，グーグルマップへのURL，住所 のフィクションデータが入っていて
ファイル名が日付で，中身には日本語の日付もある状態．
．
0531NAME IS NULL
2019/12/19(木) 10:39:22.96ID:iuFPOjkS自分が関わったシステムではただの連番をPKにした
画面の方は検索機能で対応
0532NAME IS NULL
2019/12/19(木) 10:51:59.59ID:iuFPOjkSPHPから、と言うより、WEBの入力画面で登録という解釈で良いのかな
国カラムって言い方が違和感あるけど、国項目だよね
保存ボタン押した時に国項目に入力した内容を建造物テーブルの国カラムに設定してINSERT、もしくはUPDATEするみたいな
関係云々はこの画面が建造物と国を関連を登録する機能じゃないのかな
0533NAME IS NULL
2020/01/24(金) 22:34:18.61ID:9xzHgBHv国項目って言い方が違和感あるけど、国カラムだよね
0534NAME IS NULL
2020/01/24(金) 23:19:54.20ID:Z+86jpdA日本語か英語の違いですw
0535NAME IS NULL
2020/01/29(水) 14:21:05.79ID:0X1l6BuN普通に
ALTER TABLE `テーブル名` ADD `カラム名` TEXT NOT NULL AFTER `カラム名`
みたいなSQLを実行するだけでいいのでしょうか？
それともこれを実行するとなにか問題が起きる可能性はあるでしょうか？
運用想定までできてないので、トラブルが起きる可能性があれば教えて下さい
0536NAME IS NULL
2020/01/29(水) 15:17:24.94ID:???特殊な事情がない限り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
0537NAME IS NULL
2020/01/29(水) 16:48:38.71ID:???ありがとうございます。MySQLを使っています。
運用中のデータ（つまり、読み書きが行われている）ものに対して
テーブルの追加変更ってまずいと思ったのですが、そうでもないみたいですね
0538NAME IS NULL
2020/01/29(水) 19:00:39.24ID:???もしバージョン5.x使ってるならそれなりにインパクトあるから
使ってるバージョンのマニュアル見てね
0539NAME IS NULL
2020/01/29(水) 19:12:12.64ID:???0540NAME IS NULL
2020/01/31(金) 21:28:37.66ID:Ep/cOiXA0541NAME IS NULL
2020/02/01(土) 03:03:34.39ID:???可能なら本番稼働中のDBでやるような処理じゃないぞ
0542NAME IS NULL
2020/02/01(土) 18:17:36.11ID:jPi9eO5v0543NAME IS NULL
2020/02/01(土) 18:53:13.82ID:5RS/C4xX0544NAME IS NULL
2020/02/09(日) 21:54:49.46ID:???SQL質疑応答19のスレ222でも質問した者なんですが
ブライマリキーって迷ったら全てのカラムに指定してもいいですか？
0545NAME IS NULL
2020/02/09(日) 21:58:21.18ID:???0546NAME IS NULL
2020/02/09(日) 22:01:46.73ID:???0547NAME IS NULL
2020/02/09(日) 22:07:40.17ID:vpKzpKVLそーゆー時はidにしとけばええねん
0548NAME IS NULL
2020/02/09(日) 22:08:42.02ID:???いいんじゃね？
お前さん以外は誰も困らんし
0549NAME IS NULL
2020/02/09(日) 22:10:54.01ID:???質問者はageでやるかトリップ付けた方が良いです
0550NAME IS NULL
2020/02/11(火) 21:42:03.27ID:kogHpQHL0551質問者
2020/02/11(火) 23:42:15.58ID:kogHpQHLどうしてもkey を変えたくないなら元情報用カラムをついかして元情報をそこに残すしかし複数の変更履歴残したいならば、変更用トランザクションデータを残して置けば変更履歴は追える
トランザクションデータというのはsqliteでも使えるのでしょうか？
別のテーブルを作って 変更のlogを保存するという方法はどうでしょうかね
0552NAME IS NULL
2020/02/11(火) 23:56:09.78ID:???登録するデータの内容とそれが追加か更新か（必要なら削除も）の処理内容を追記するテーブルを用意する
おそらくあなたの考えているLogと同じ事ではないかと思う。もちろんsqliteでも使える
0553NAME IS NULL
2020/02/12(水) 20:49:06.79ID:08I8SsIH0554NAME IS NULL
2020/02/12(水) 21:05:19.11ID:vYRA4Gos0555NAME IS NULL
2020/02/12(水) 21:23:59.53ID:???0556NAME IS NULL
2020/02/12(水) 22:35:55.16ID:???マスターとトランザクションデータの区別がまともにできないから気をつけろ
30オーバーのやつも含めてチーム全員が
マスターのことをトランザクションと呼んでて震撼したことがある
0557質問者
2020/02/12(水) 23:42:53.31ID:lI+lS+0+なるほどマスタとトランザクションという概念があるんですか、ためになるな
最新のデータはマスターに記録して変更履歴をトランザクションとして記録すればいいんすね
0558NAME IS NULL
2020/02/13(木) 00:02:14.97ID:???もっと基本的な所から勉強した方が良い
話を聞いている限り、テーブル設計がちゃんとできていない
0559NAME IS NULL
2020/02/13(木) 00:03:42.63ID:???0560質問者
2020/02/13(木) 00:17:07.26ID:IbwPir4sテーブル設計でいい本とかサイトありますか？
今、達人に学ぶDB設計指南って本読んでるんですけどフワッとしてるっていうかもっとテーブル設計の実例が見たい
0561NAME IS NULL
2020/02/13(木) 17:28:06.14ID:dDuhYxxEコボラーのおじいちゃんの概念なw騙されんなw現代においてはなんも意味ないでw
0562NAME IS NULL
2020/02/13(木) 21:03:05.33ID:???0563NAME IS NULL
2020/02/13(木) 21:16:52.08ID:???「業務別データベース設計のためのデータモデリング入門」渡辺幸三
0564NAME IS NULL
2020/02/14(金) 00:46:37.23ID:+QGsVRcrありがとうございます
レビュー見ると難しそうだけど読んでみます
0565NAME IS NULL
2020/02/14(金) 00:52:53.18ID:???賑わいはないけど真面目にレスが返る板だから
0566NAME IS NULL
2020/02/19(水) 21:02:42.95ID:dncf6ZkKおまえが気持ち悪い事ゆうから誰も居らんくなったやないか
0567NAME IS NULL
2020/02/19(水) 22:45:15.97ID:???0568NAME IS NULL
2020/02/20(木) 02:03:55.39ID:7o2dB+yghttps://ideone.com/oOlh4z
中間にINSERTされる場合があります。
SELECTする時は漏れなく連番の先頭から最後まで一括で取得することになります。
0569NAME IS NULL
2020/02/20(木) 03:27:31.79ID:???0570NAME IS NULL
2020/02/20(木) 04:23:11.02ID:???件数や更新頻度、データの使われ方による
一括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が一発でわかるデータは必要
0571NAME IS NULL
2020/02/20(木) 18:03:03.56ID:???順番を決められるような非整数の項目用意して
通常は整数値を入れておき、
挿入時に前後の項目の中間値を入れるなんてどうかな
0572NAME IS NULL
2020/02/20(木) 19:50:02.82ID:???取得する順番はどうでもいいのか？
0573NAME IS NULL
2020/02/20(木) 20:55:47.42ID:???>>570
振り直しとかｗ
0574NAME IS NULL
2020/02/20(木) 21:26:21.35ID:???再帰クエリを使う前提やろ
>>573
>振り直しとかｗ
RDBのページ分割と同じだぞ
0575NAME IS NULL
2020/02/20(木) 21:53:23.57ID:???二項関係を全部保持する設計だと参照は爆速。
0576NAME IS NULL
2020/02/20(木) 22:07:16.22ID:???0577NAME IS NULL
2020/02/21(金) 05:29:35.02ID:???入れ子集合
閉包テーブル
なんて方法もあります
0578NAME IS NULL
2020/02/21(金) 20:03:46.42ID:???振り直しは実は結構現実的なソリューション
>>574
まあ、再帰前提になるわな
再帰クエリってパフォーマンスどうなんだ
あと再帰のネスト深さとかけっこう制限あったような
0579NAME IS NULL
2020/04/28(火) 18:41:13.11ID:???例えば商品マスタ（ID,JANコード、名称、・・・）があって
こいつらにセール対象、まとめ買い対象、みたいなフラグカラム追加したいときってどういうカラム名がいいんでしょ？
セール対象テーブル追加してそっちみろは無しでお願いします
is_Bargain、is_MatomeGay(英語わからんので適当)とかにする？
0580NAME IS NULL
2020/04/28(火) 21:37:21.40ID:???命名規約次第だけど個人的には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に比べるとカラム名としてはマシ
0581NAME IS NULL
2020/04/28(火) 21:42:09.42ID:???アフィサイトみたいに表示管理だけでいいなら
それでも問題ないかもしれないけど、実際にキャンペーンやる会社なら
どの期間、どのキャンペーンの対象で、どういう適用条件かみたいなのが最低限必要だからboolじゃ破綻しそう
0582NAME IS NULL
2020/04/28(火) 23:30:35.91ID:???そうなんですよね。英語的にはマシかもだけどカラム名として何だか微妙になるんですよね
現状はフラグ1、フラグ2、..みたいな暗黒状態かつ命名規約何それなので、それよりはマシなのですが
実際は簡単なフラグ管理だけで良いので、バーゲン期間とかは考慮しなくて大丈夫です
良かろうと思って一般的なサンプルでっち上げると余計な検討点が出てきてダメですね
私の悩みを10年前に通過している列海王的な方がいたら、引き続きナイスな命名案をよろしくお願いします
0583NAME IS NULL
2020/04/29(水) 00:45:02.07ID:???on_saleやis_on_saleで命名してるのはそこそこ見つかる
0584NAME IS NULL
2020/05/02(土) 23:39:27.57ID:???遅くなりました。ありがとうございます
githubも見てみます
こういう時ネイティブ並の語彙力がほしくなる
0585NAME IS NULL
2020/05/03(日) 04:57:59.36ID:???ネイティブが違和感を感じるかどうかより、日本人が納得するかどうかだと思うぞ
DBMSにもよるだろうが、日本語環境以外での動作を考えないなら日本語カラム名でもいいと思う
0586NAME IS NULL
2020/05/04(月) 17:11:14.86ID:???最近は一貫性が取れてるならis_fooやis_barよりもベターなケースが多いと思うようになってきた
組織の英語力やDBリテラシー次第
0587NAME IS NULL
2020/05/04(月) 22:00:17.67ID:???boo(0,1)とるカラムがxx_kbn
int(0~9)とるカラムがxx_flag
せめて逆じゃね？
0588NAME IS NULL
2020/05/04(月) 23:04:59.53ID:???0589NAME IS NULL
2020/05/10(日) 15:13:42.60ID:DCNb3jN3普通は削除フラグにとどめて、よほどのことがないとdeleteするようなことってないと思いますが、
deleteしまくることによって何か問題が起きたりするのでしょうか？
あと消したあとも、ゴミ箱にいれたHDDの中身みたいに実は復旧可能だったりしますか？
問い合わせのログみたいなのを一定期間後に完全削除するのを考えてます。
0590NAME IS NULL
2020/05/10(日) 15:37:54.86ID:???削除するかどうかは要件次第
不要になったら一旦アーカイブに移動させて
その後、事前に決めた一定期間を過ぎたらメディアにバックアップとって削除する
メディアも事前に決めたメディア用の一定期間を過ぎたら廃棄する
そういうデータライフサイクルを要件定義時に決めて運用にのせるのが普通
復元できるかどうかはバックアップやトランザクションログの残し方による
0591NAME IS NULL
2020/05/19(火) 13:31:17.65ID:FzKBKTy1例えばブログの場合、
article → 記事テーブル
category → カテゴリーテーブル
article_cateogry →記事のカテゴリーテーブル
と設計することがあると思います。
ここに「特集」という別のコンテンツを追加したい場合、
special → 特集テーブル
special_category → 特集カテゴリーテーブル
special_special__cateogry →特集の特集カテゴリーテーブル
とするのは変です。
記事と特集はテーブル設計が異なるので、同じテーブルでまとめられません。
しかし、「カテゴリー」テーブルの設計は同じです。同名でも意味は通じます。
categoryではなく、type（種類）とかclass（クラス）とか別名にして対応するのでしょうか？
0592NAME IS NULL
2020/05/19(火) 15:41:38.69ID:???「特集」は特集記事であって記事の特化したものではないの？
ある一つのカテゴリーを選択した場合に
それに合致する記事も特集も拾いたいケースがあるなら
カテゴリーテーブルは一つにしたほうがよくて
特集テーブルも記事テーブルと1 ― 0..1 の関係で作るか
特集テーブルと記事テーブルを汎化したテーブルを検討する
0593NAME IS NULL
2020/05/19(火) 16:47:06.21ID:FzKBKTy1「特集」という例がわかりづらいなら、掲示板（bbs）でもいいです。
掲示板でも「カテゴリー」って分類は必要ですよね？
でも、記事のカテゴリーと掲示板のカテゴリーは内容そのものが違います。
たとえカラムが同じであっても、用途が異なるテーブルを共有し使うのはよくありません。
だからcategoryではない別名が必要なのですが、その命名が難しいという相談です。
0594NAME IS NULL
2020/05/19(火) 20:13:30.72ID:???0595NAME IS NULL
2020/05/19(火) 20:32:01.95ID:???0596NAME IS NULL
2020/05/19(火) 20:45:57.38ID:???この程度のことがググっても見つからないんです。
>>595
日本語だとそれでOKなのですが、>>591の命名に合わせるとおかしいと思う次第です。
そもそもですが、最初は単純に「category」というテーブル名にしてて、
あとから別の用途のカテゴリーがでてくる事ってありませんか？
最初から記事カテゴリーを作る想定をしていないと思うんです。
規模を拡張する時に命名が被る、だから困るってそんなおかしい悩みですかね・・・
0597NAME IS NULL
2020/05/19(火) 21:13:48.53ID:???モデリングがうまくできてないケース
0598NAME IS NULL
2020/05/19(火) 21:52:13.20ID:???1つのスキーマに複数必要になるケースってそうそうないよね
0599NAME IS NULL
2020/05/19(火) 21:58:57.66ID:???0600NAME IS NULL
2020/05/19(火) 22:14:36.92ID:???そもそも special_category という名称が意味不明
0601NAME IS NULL
2020/05/19(火) 23:39:26.48ID:???確かにただアプリとしてブログとか掲示板を作ってるだけなら無いですが、
サイト作ってる場合、要件の追加・カスタマイズってあると思うんですよね
カテゴリーみたいな分類が必要なコンテンツって、
記事、掲示板、お知らせ、特集、クチコミ、求人など様々思いつきますし。
それをWordpressのように単一参照テーブルで管理しろってのもちょっと・・。
>>599
それも考えたのですが、ひとつのDBに数テーブルしかない状態でわけるってのも
どうかと思うんです。JOINの効率も悪そうだし。
>>600
すみません。単に例題として出しただけです。
0602NAME IS NULL
2020/05/19(火) 23:45:42.87ID:???categoryじゃなくても、menuとかclassとかgenreとか似たような用途に使える
名前があるし、わざわざカテゴリーって呼び方にこだわらなくてもいいかもしれません
一般的な質問でない場合、上記のように解釈して妥協します。
0603NAME IS NULL
2020/05/20(水) 02:26:52.88ID:???記事カテゴリー
掲示板カテゴリー
お知らせカテゴリー
特集カテゴリー
クチコミカテゴリー
求人カテゴリー
普通のお客さんならキレるよ
0604NAME IS NULL
2020/05/20(水) 09:07:47.41ID:???お客さんに提供してないのでキレられることはないですが、
設計を見直すということは、既存のテーブルの名前を変えろということですか？
何度も記載していますが、最初はただの「カテゴリー」として作っていたものを
後から「記事カテゴリー」と別名にするのはリスク高いと思います。
だから力技で命名するしかないのではないか？と思う次第です。
「いや、後から用途が増えるなら変えるべきだろ」
というなら私の認識が間違っているので変更しますが、
確信的なレスがないので納得できないでいます。
0605NAME IS NULL
2020/05/20(水) 09:15:02.49ID:???（１）初期運用段階
article → 記事テーブル
category → カテゴリーテーブル
article_cateogry →記事のカテゴリーテーブル
（２）「カテゴリー付きの掲示板が必要」という要件が発生した
bbs → 掲示板テーブル
bbs_category → 掲示板カテゴリーテーブル
bbs_bbs__cateogry →掲示板の掲示板カテゴリーテーブル
[悩み]こういうテーブル設計を追加するのはおかしいと思う。
一般的にはどうするべきですか？
（補足）>>603さんの案：既存のテーブル名を変更
article_category → 記事カテゴリーテーブルに変更
article_article_cateogry →記事の記事カテゴリーテーブル
[悩み]途中で既存のテーブル名を変更するのはリスクが高くないか
0606NAME IS NULL
2020/05/20(水) 12:39:47.56ID:???>>603のは普通は全部一つのカテゴリーテーブルでまとめられるだとって話なんだけど・・・
CMSで管理するサイトコンテンツのカテゴリーでしょ？
記事に付けるタグと求人に付けるタグが共通でも問題ないし
どちらか一方にしか使えないタグが必要でも
いちいち別テーブルにしなくてもまとめて管理できるでしょ
力技の命名ってのは関連テーブルを示すprefix/infix/suffixを決めて
それを該当スキーマ内で一貫して使うみたいな規約で逃げるという意味
既存のテーブル名を変更するのがリスクが高いかどうかはアプリの作り次第だが
CMSならリスクは知れてる
0607NAME IS NULL
2020/05/20(水) 17:44:51.41ID:???もしかしてCMS＝既存のCMSを指してますか？
そうでなくて、自作の話なのですが・・。
それにひとつのカテゴリーテーブルで、>>603みたいなのをまとめるのは無理です。
例えば以下のようなカテゴリーが必要だとします。
記事 ｜全般、Web制作、システム開発、データベス
掲示板｜パソコン、ニュース、エンタメ
お知らせ｜サービス、イベント、運営会社
記事コンテンツで、掲示板で使用する「パソコン」というカテゴリーはいらないし、
お知らせコンテンツにある、運営会社というカテゴリーもおかしいです。
カテゴリーテーブル（category）を以下のカラム構成にして
id（pk）｜target｜name｜
1 ｜article｜全般
2 ｜bbs ｜パソコン
SELECT * FROM category WHERE target='article'
というSQLを実行すれば、「記事だけのカテゴリーを抽出」することは可能です。
しかし、こんな設計は明らかにアンチパターンですよね？
JOINするときはWHEREとセットになるし、SQLコストも増大します。
通常は要件に伴ったテーブルを用意するはずです。
それともアンチパターンとか関係なく、上記のようにするのが普通なのでしょうか？
あるいは、カラム設計自体も違うというのであれば、正しい設計を教えていただきたいです。
0608NAME IS NULL
2020/05/20(水) 18:55:01.20ID:???細かいところを置いておくとそのテーブルイメージの考え方はアンチパターンではないよ
同じ情報を管理するのに全部別テーブルにするほうがアンチパターン
JOINするときWHEREとセットになるんじゃなく
記事/掲示板/お知らせみたいな要素を指すIDが結合条件になる
仮にWHEREで指定することになったところで
カテゴリーテーブルの件数なんてめちゃくちゃ少ないし
きちんとインデックス付けてればSQLコストが増大とかしないから
0609NAME IS NULL
2020/05/20(水) 18:57:14.65ID:???0610NAME IS NULL
2020/05/20(水) 19:00:20.45ID:???それとそのカテゴリーの例を見ると
1つの記事や掲示板は1つのカテゴリーにしか属さない風にも見えるけど
複数カテゴリーに属する前提であってる？
0611NAME IS NULL
2020/05/20(水) 19:04:47.61ID:???俺は絶対スルー案件だわw
0612NAME IS NULL
2020/05/20(水) 19:28:50.40ID:???上でもそうだったけど、命名がおかしい気がする
掲示板のところにある「パソコン」「ニュース」「エンタメ」というのは
5ちゃんねるで言う板のこと？ (たとえばこのスレはデータベース板だけど)
記事・掲示板・お知らせの関係がわかると答えやすくなると思う
(例えば掲示板と記事は一対多の関係など)
0613NAME IS NULL
2020/05/20(水) 19:48:43.41ID:???こいつのアンチパターンだからダメって脅迫概念はどっからきてるんだ
0614NAME IS NULL
2020/05/20(水) 20:15:27.77ID:???> 正しい設計を教えていただきたいです。
そもそも絶対的に正しい設計なんてない
例えばカテゴリーテーブルを>>603の各項目毎に作るのか１つにまとめるのかも双方にメリット・デメリットあるからケースバイケースで常にどっちかが良いというわけじゃない
算数の答えみたいに正解が１つと思うのはやめた方がいい
0615NAME IS NULL
2020/05/20(水) 20:25:38.47ID:???>>613
何がどうアンチパターンか＝正規化ができてない
って判断はおかしいですかね？怒られる程なのでしょうか・・・
>>608
既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。
>>609
煽り抜きで教えてほしいのですが、
普通に「思ったより反響があって増築の必要が出た」
って要件、くさるほどあると思うんです。
1か100かじゃなくて、1・2・3って成長していくものだと思うんです。
0616NAME IS NULL
2020/05/20(水) 20:26:36.28ID:???591や605の例で中間テーブルを想定していますが、
>>607の例でも中間テーブルを用意すれば、多対多は可能だと思います。
>>611
真摯に議論したいし、間違っていたら教えてもらいたいだけです。
>>614
おしゃるとおりですが、そもそも私の質問自体「こいつ馬鹿じゃね？」
って感じのレスを頂くものですから、ベストプラクティスがあると思うんです。
それにみなさんはどうしているのかを聞きたいのが、希望ですし・・。
0617NAME IS NULL
2020/05/20(水) 21:04:01.67ID:???>中間テーブルを用意すれば、多対多は可能だと思います。
実現可能かどうかじゃなく要件として多対多が要求されてるの？
0618NAME IS NULL
2020/05/20(水) 21:17:12.37ID:???>既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ？
>単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。
自分のまずい設計を正当化するためにリスクが増大するんですって言ってるんじゃなく
微妙な設計になることのデメリットと既存の部分を触ることによるデメリットを
天秤に掛けた上の判断なら別にいいと思うよ
CMSでカテゴリーテーブルを使用する箇所が
あっちこっちに散在してるようならそもそもの設計がまずいとは思うけどね
0619NAME IS NULL
2020/05/20(水) 21:26:58.14ID:???要求されています。
>>618
618さんの解釈では、
「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」
ということですよね？それがまずい設計だと、
私は「ひとつのテーブルですべてのカテゴリーを管理する」
ことがまずい設計だと思っているんです。
なぜまずいと思うかというと、アンチパターンだったり、正規化できていなかったりと
一般的に悪いと言われるテーブル設計を採用しろと言われているからです。
618さんの言う「カテゴリーはカテゴリーなんだから、複数あるのはおかしい」
という主張は理解できます。
しかし、ひとつのテーブルに用途違いのデータが入ることの正当性が
私には理解できないので、618さんの主張が正しいと思えないんです。
煽っているのではなく、主張を正しいとする論拠がわからないんです。
0620NAME IS NULL
2020/05/20(水) 21:32:41.33ID:qpD3w8BM記事カテゴリは10000〜19999、特集カテゴリは20000〜29999みたいな
0621NAME IS NULL
2020/05/20(水) 21:34:11.67ID:???0622NAME IS NULL
2020/05/20(水) 21:49:45.25ID:???それで記事テーブルと結合する時はどうするんですか？
全てのSQLにWHERE id BETWEEN '10000' AND '19999'
を追加するのでしょうか？
>>621
5ちゃんねるでいうと板になるんですかね。
記事とか掲示板とかお知らせは1つのテーブル（1つのコンテンツが入る）であり、
カテゴリーというのは、そのテーブル内のデータを分類するために必要です。
1つの投稿に対して複数のカテゴリーを割り当てられることから、多対多ですね。
5ちゃんねるの場合、1つの投稿に複数カテゴリーを割り当てないと思いますが。
0623NAME IS NULL
2020/05/20(水) 22:07:40.68ID:???掲示板と記事は一対多なの？
0624NAME IS NULL
2020/05/20(水) 22:25:53.64ID:???>「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」ということですよね？
違う、そういう考え方じゃない
既存のしがらみは一旦忘れて同じエンティティなのか異なるエンティティなのかを考える
その答えは要件によって変わるんだが
今のところ異なるエンティティとして管理すべき要件は見当たらない
正規化できないというのは君の思い込み
コンテンツの種別ごとにカテゴリーテーブルとその中間テーブルを作らなきゃいけないのは
SQLアンチパターンの9章にある”Antipattern: Clone Tables or Columns”
0625NAME IS NULL
2020/05/20(水) 22:39:11.58ID:???共通に扱える仕組みを用意した上で個別に必要な拡張が施せるようにする
記事に特化した記事管理システムなら
そこに掲示板管理システムをそのまま増設するのは悪手で
DB含めてシステムを分けるか再構築してまともなCMSにする
0626NAME IS NULL
2020/05/20(水) 23:15:00.78ID:???自分のスキルが低いと思うんですが、理解できずに申し訳ないです。
それでは私が最初に構想していた>>591という
要件毎にテーブルを作るやり方ではなく、
>>607のような、ひとつのテーブルでまとめるやり方が正しい
（今回の相談ケースではこうするべき）という解釈で良いのでしょうか？
AでもBでも良いとか、AもBもよくないという結論では
モヤッとしてしまうので、どちらがベターか指摘してほしいです。
0627NAME IS NULL
2020/05/20(水) 23:35:03.93ID:???> ベストプラクティスがあると思うんです。
だからケースバイケースだっていう話
>>611
お前が正しかったわ
0628NAME IS NULL
2020/05/20(水) 23:41:09.52ID:???テレワークは終わりですよ
0629NAME IS NULL
2020/05/21(木) 01:00:34.53ID:???テーブル名とかまあどうでもいいわな
掲示板カテゴリーと記事カテゴリーが別だとするなら別テーブル作ればいいし
同じだが使用箇所が違うだけだと思えば一つで良い
0630NAME IS NULL
2020/05/21(木) 06:52:31.63ID:???それがいやならテーブル名を連番にでもすればいい
0631NAME IS NULL
2020/05/21(木) 11:31:44.45ID:???要件という言葉を理解してないw
無知なのにイキってる感じがQiitaっぽいな
0632NAME IS NULL
2020/05/21(木) 17:40:13.28ID:???その程度の変更もできないプログラムだったらプログラム側の設計も見直したほうがいいら
0633NAME IS NULL
2020/05/21(木) 18:10:57.18ID:???これってDB設計が糞だと思うんだけどどうだと思いますか？
0634NAME IS NULL
2020/05/21(木) 18:20:21.15ID:???0635NAME IS NULL
2020/05/21(木) 18:57:20.13ID:???多重申請ができるからといってDB設計が糞とは言い切れない
DV被害者対策や郵送申請もあるので
後続の業務はもともと多重申請がある前提で設計しておく必要がある
実際のところは短期間での開発を要求されたから
普通なら必要になる画面や機能を削った結果
多重申請を許容する仕様にせざるを得なかったんだろうな
0636NAME IS NULL
2020/05/21(木) 19:02:38.66ID:???間違った内容で申請した場合に後から正しい内容で申請できるようにするために
多重申請ができる仕様にしてるらしい
付け焼き刃だし仕方ないかもね
郵送に一本化しといたほうが効率的だった可能性もある
0637NAME IS NULL
2020/05/21(木) 19:29:00.39ID:???単に用紙の持ち込みをオンライン化しただけで
持ち込まれたデータのチェック・管理はすべて人力
分かりやすいシンプルな良いシステム
0638NAME IS NULL
2020/05/21(木) 19:49:25.34ID:???＞東京 調布市と福生市は入力された情報の確認に時間がかかり給付が遅れるおそれがあるとして、受け
＞付けや手続きを停止しました。オンライン申請を巡っては、同じような対応をとる自治体が各地で相次い
＞でいます。
https://www3.nhk.or.jp/news/html/20200521/k10012439151000.html
0639NAME IS NULL
2020/05/21(木) 21:19:53.32ID:C+Ki3nmV郵送分の処理も妨害して遅くするのでやめてほしいそうだ。
0640NAME IS NULL
2020/05/22(金) 15:56:07.78ID:???自分が俄で視点が近いからか微妙に解る気がするんだけどこの設計がEAVじゃないかって気になるって事であってる？
けどこれって>624の「同じエンティティなのか異なるエンティティなのかを考える」が全てで、
カテゴリーっていう同じエンティティなんだから同じテーブルに纏めたってEAVにはならないのではって事だと思うが
このテーブルに[targer:person_name, name:田中]みたいなレコード登録したらEAVだと思うけど
0641NAME IS NULL
2020/05/22(金) 23:25:58.05ID:???カテゴリーテーブルがサブカテゴリーにたいするEAVだって考え方もある
EAVだからアンチパターンでダメだって考えが間違ってる
アンチパターンと言われているものの、何がどうダメなのかちゃんと考えないと
0642NAME IS NULL
2020/05/23(土) 00:18:19.59ID:???Youtubeの動画に付けるタグとGmailのメールにつけるタグも1テーブルで管理することはまずない
(RDB使ってない可能性のほうが高いけど)
QiitaがもしQ&A掲示板を始めたり技術イベントの告知・集客サービスを始めて
各スレッドや各イベントにタグ付けできる機能を実装するようなケースは
既存の記事向けのタグと同じエンティティとして管理する可能性が高い
0643NAME IS NULL
2020/05/23(土) 09:51:07.58ID:???0644NAME IS NULL
2020/05/23(土) 11:30:26.74ID:???0645NAME IS NULL
2020/05/23(土) 12:34:48.23ID:???ケースバイケースとか考え方次第で済ませてその判断基準を何も提示しないのはゼロ回答に等しいからさ
0646NAME IS NULL
2020/05/23(土) 12:59:28.25ID:???0647NAME IS NULL
2020/05/23(土) 14:37:43.95ID:???0648NAME IS NULL
2020/05/23(土) 16:07:15.63ID:???0649NAME IS NULL
2020/05/23(土) 18:14:02.96ID:???それは「考え方次第」
0650NAME IS NULL
2020/05/23(土) 20:48:19.09ID:???0651NAME IS NULL
2020/05/23(土) 21:52:49.37ID:???それは「ケースバイケース」
0652NAME IS NULL
2020/05/27(水) 07:37:48.25ID:???csv ファイルを提供されて
数量データが4000なのですが
少数第二位までという4000.00の意味の
400000というデータで提供されます
毎回エクセルで100で割ってからインポートします
また、顧客コードが10桁で
数字の羅列が醜いので
12-3456-7890とハイフンの追加も行ってから
インポートします
毎月の事なのですが
この数量データ割算と、顧客データハイフンを
いちいちExcelで処理せずに
インポート時やインポート後にうまく処理する方法は無いでしょうか？
0653NAME IS NULL
2020/05/27(水) 10:55:44.11ID:???若干スレチな気もするがその内容ならCSVを変換するスクリプトを書くのが手っ取り早いと思う
どういう方法が最適かはDBMSの種類、既存のインポート方法・インポート時の処理内容、処理件数、所持スキル等による
0654NAME IS NULL
2020/05/27(水) 11:30:33.69ID:???0655NAME IS NULL
2020/05/27(水) 12:01:00.97ID:???0656NAME IS NULL
2020/05/27(水) 12:29:36.22ID:???今ここで話題にしているのはその事例なんだから
0657NAME IS NULL
2020/05/27(水) 13:37:12.83ID:???>そのケースバイケースを細かく教えて
これがケースバイケースが理解できてない典型例
0658NAME IS NULL
2020/05/27(水) 13:55:21.55ID:???0659NAME IS NULL
2020/05/27(水) 14:36:27.12ID:???この質問だけだと良くわからないんだよね
csvファイルはどういうDBにインポートされるのかとか
そもそもなぜ100で割ってからインポートするような謎な仕様になっているのかとか
ひとまずこの質問文だと, DB設計の話ではなく, DBを扱うプログラミングの話でしかない
DBにアクセスするプログラミング言語で実装すればよい
0660NAME IS NULL
2020/05/27(水) 14:47:02.83ID:???何を知りたいのかを他人が理解出来るようにまず説明して
0661NAME IS NULL
2020/05/27(水) 14:55:35.18ID:???0662NAME IS NULL
2020/05/27(水) 15:08:38.84ID:???それは「ケースバイケース」
0663NAME IS NULL
2020/05/27(水) 15:23:40.95ID:???「これはこうしろ」ってレスするほうが早くないか？
質問者に喜ばれるし、自己顕示欲も満たすし、スレも荒れない。
何も損しないんだが、なぜケースバイケースってまとめるのかわからん
0664NAME IS NULL
2020/05/27(水) 16:56:45.60ID:???早くない
質問する側がどういうケースなのかを特定するための説明をするほうが断然早い
どういうケースなのかを相手に伝える努力を放棄してるにもかかわらず
答える側にはケースを想定した回答を求めるのは無理筋
0665NAME IS NULL
2020/05/27(水) 17:28:19.42ID:???「それケースバイケース」って言えるか位は､
言えるだろう
それを聞いている
0666NAME IS NULL
2020/05/27(水) 17:28:52.80ID:???それならもっと詳しく聞けばいいだけじゃないか？
プログラム板とか情報足りないとそう答えてるぞ
荒れやすいニュース板でもケースバイケースとかどっちでもいいとか
クソレスするやつは少ないよ
ここぐらいだ。端からコミュニケーション放棄してるのは
0667NAME IS NULL
2020/05/27(水) 17:29:08.26ID:???0668NAME IS NULL
2020/05/27(水) 17:32:01.30ID:???「AまたはBですか？」
という的外れな質問でも
「Cだよ」って回答して
「いや、CじゃなくてAはこういう意味で〜」
ってな感じでスレが流れる。
しかしここは「AでもBでもどっちでもいい」だもん。
まるで会話になっていない
0669NAME IS NULL
2020/05/27(水) 17:39:29.67ID:???「それを聞いてる」じゃわからないよ
何を聞いてるの？
0670NAME IS NULL
2020/05/27(水) 18:00:58.87ID:???>それならもっと詳しく聞けばいいだけじゃないか？
それは単なる甘え
自分が努力せず他人に努力させようとしてるやつに
仕事でもないのに懇切丁寧に聞き返す労力を払うやつは少ないわな
0671NAME IS NULL
2020/05/27(水) 18:02:04.31ID:???これに尽きるな
0672NAME IS NULL
2020/05/27(水) 18:54:02.70ID:???ケースバイケースっていわれた段階で説明が足りんと気づけや
0673652
2020/05/27(水) 19:08:39.17ID:???659
スレチなのにご回答ありがとうございます
とりあえずデータベースだけで出来るような仕組みを考えます
0674NAME IS NULL
2020/05/27(水) 19:12:38.40ID:???内容がはっきりすればそれなりに回答してくれてるだろ、このスレは
0675NAME IS NULL
2020/05/27(水) 19:14:01.98ID:???ケース分けなどいらないぞ
0676NAME IS NULL
2020/05/27(水) 19:15:19.35ID:???0677NAME IS NULL
2020/05/27(水) 20:16:10.67ID:???加工するsqlでインポートはどうかな
0678NAME IS NULL
2020/05/27(水) 20:19:15.84ID:???0679NAME IS NULL
2020/05/27(水) 21:18:28.66ID:???0680NAME IS NULL
2020/05/27(水) 22:01:37.60ID:???参照整合性がどうなってんのか気になるが
0681NAME IS NULL
2020/05/27(水) 22:20:41.40ID:???セルに書式設定すればいいんじゃね
インポートして書式設定までVBAですぐできるだろ
0682NAME IS NULL
2020/05/28(木) 11:27:01.61ID:???>>676みたいな奴は読解力がないだけ
0683NAME IS NULL
2020/05/28(木) 12:11:39.95ID:???想像してるんじゃなくてDBだけでやりたいという形でケースの特定化がなされたことで>>677や>>680の回答が出やすくなってるんやで
0684NAME IS NULL
2020/05/28(木) 12:49:31.13ID:???これに関してケースバイケースなんて言われてないだろ
お前はそれ以前に日本語が読めないのか？
0685NAME IS NULL
2020/05/28(木) 16:48:42.27ID:???>>654
0686NAME IS NULL
2020/05/28(木) 17:13:38.87ID:???0687NAME IS NULL
2020/10/02(金) 04:29:53.32ID:8BLp41VJ現在、id (INTEGER) と user_name (TEXT) の2カラムで、以下のデータがあるとします。
1 , 東京営業所
2 , 沖縄営業所
3 , 北海道営業所
4 , 東北営業所
データを取得時、以下のように北のほうからの並びで取得したい場合は、並び順を設定するカラムを追加するしかないでしょうか？
3 , 北海道営業所 , 1
4 , 東北営業所 , 2
1 , 東京営業所 , 3
2 , 沖縄営業所 , 4
既存のテーブルで、設計を変更するとプログラム側も変更しないといけない場所が何か所か出てくるので、
極力変更したくないのですが・・・
0688NAME IS NULL
2020/10/02(金) 07:18:02.94ID:???素直にフィールド追加した方が後の保守は楽ですよ
プログラム側はフィールド追加で影響が出ない様に作るものですけどね
0689NAME IS NULL
2020/10/02(金) 08:33:57.24ID:???データを複製してるような処理しか思いつかない
そういう処理なら並び順もデータとして必要になるよね
0690NAME IS NULL
2020/10/02(金) 20:23:42.56ID:???0691NAME IS NULL
2020/10/02(金) 22:02:47.07ID:???最終目的地までカラムを指定せず全部出力するなら別だけど
0692NAME IS NULL
2020/10/02(金) 22:21:30.11ID:???どっちにしてもorder by指定する必要がある
今idでorder byしてるが、それを変えたくないなら、id振りなおすしかないわな
id振りなおすのとカラム追加＆プログラム変更とid振り直しとどっちが楽か判断して決めれば良いんじゃね
0693NAME IS NULL
2020/10/03(土) 20:16:27.73ID:???0694NAME IS NULL
2020/10/03(土) 23:37:33.72ID:???しかしorder byがなくて
バクるアプリを引き継いだワイにはタイムリーネタやで
0695NAME IS NULL
2020/10/03(土) 23:46:00.34ID:???並べたい順に自分で番号付けたテーブルを用意しないと無理でしょ
0696NAME IS NULL
2020/10/04(日) 02:18:43.41ID:???0697NAME IS NULL
2020/10/05(月) 16:37:36.91ID:???0698NAME IS NULL
2020/10/05(月) 19:58:12.35ID:mY4x3iPHそのIDにエリアの概念を持たせなかったのが失敗なんだよ。
0699NAME IS NULL
2020/10/05(月) 20:44:41.26ID:???0700NAME IS NULL
2020/10/05(月) 20:44:48.17ID:???さすが
0701NAME IS NULL
2020/10/05(月) 20:45:18.74ID:???0702NAME IS NULL
2020/10/06(火) 01:05:10.04ID:HE4gRaIT0703NAME IS NULL
2020/10/06(火) 09:23:09.69ID:???コード体系を作ったこともないのかね。
0704NAME IS NULL
2020/10/06(火) 10:17:55.36ID:???すぐ暗黙のコードを使おうとするんだよね
昔、東大卒のマーケティング屋さんが
10個以上の意味を埋め込んだオレオレ独自コードを
自信満々のドヤ顔で説明してきた時は困り果てたよ
0705NAME IS NULL
2020/10/06(火) 11:04:05.32ID:9/QKAQYT0706NAME IS NULL
2020/10/06(火) 11:47:26.23ID:???0707NAME IS NULL
2020/10/06(火) 11:47:30.72ID:???複数の意味を持たせるのがアンチパターン
0708NAME IS NULL
2020/10/06(火) 13:04:33.85ID:9/QKAQYT0709NAME IS NULL
2020/10/06(火) 13:25:17.40ID:???控えめに言ってガイキチなので気をつけろ
0710NAME IS NULL
2020/10/06(火) 14:07:09.38ID:9/QKAQYTidentityではなくidentifier。
0711NAME IS NULL
2020/10/06(火) 14:07:39.63ID:9/QKAQYTIDはユニークという意味しかない
0712NAME IS NULL
2020/10/06(火) 14:37:54.31ID:???0713NAME IS NULL
2020/10/06(火) 14:54:07.51ID:???必然それは代理キーとなるだろう、とは言えるが
導出項目をつねに代理キーにするとか言ってないし
代理キーが主キーに限定されているわけでもないし
そもそもコード体系云々以前に
一つの項目に複数の意味を持たせるなって大原則があるだけ
0714NAME IS NULL
2020/10/06(火) 16:27:35.99ID:9/QKAQYT0715NAME IS NULL
2020/10/06(火) 18:02:55.53ID:???もしそうなら誤訳以外のなにものでもないので別の訳語なり用語を選んだほうがいいと思うぞ
0716NAME IS NULL
2020/10/06(火) 18:11:26.80ID:???代理キー（だいりキー、英: alternate key）
代替キー (サロゲートキー、surrogate key)
これはやべぇw
英語の日本語の意味が完全に逆
0717NAME IS NULL
2020/10/06(火) 18:14:46.93ID:HE4gRaIT0718NAME IS NULL
2020/10/06(火) 18:24:08.59ID:HE4gRaITその代替キーはIPAでは代用キーと呼んでいる。
サロゲートキーのことを「代理キー」と呼ぶのは日本の慣習です。
英語の翻訳語は使われ方が反対になることがあるので注意してください。
0719NAME IS NULL
2020/10/06(火) 22:06:20.96ID:???wikipediaの記事ができるより前の時期で検索してみたが
surrogate keyは代理キーは、alternate keyは代替キーと正しく訳してるものしか見つからない
オラクル、富士通、ユニシス、@IT、オージス総研などなど
古いDBマガジンを確認しても代理キーはsurrogate keyの意味で使われてるものしかない
歴史修正主義なんかな？
0720NAME IS NULL
2020/10/06(火) 22:15:47.94ID:???0721NAME IS NULL
2020/10/20(火) 07:31:35.62ID:???ちょろっとググった感じだと、パフォーマンスが重要な要件だとテーブル結合をなるべく避けたい
とかが見つかりましたが
0722NAME IS NULL
2020/10/20(火) 07:34:17.42ID:???0723NAME IS NULL
2020/10/20(火) 07:40:17.35ID:???多重管理を避けることができ、それに付随して
・テーブルの意図が明確になる
・データ不整合の発生を防げる
などです
0724NAME IS NULL
2020/10/20(火) 10:09:11.35ID:???トランザクション処理中心の業務系データベースの場合は基本的に正規化する
更新異常を防いで整合性を維持するため
ただしパフォーマンス最適化のために正規化されたものを非正規化することはある
その場合でも設計時には正規化された場合の構造を明確にした上で非正規化する
そうしないと非正規化したことでどういう更新異常が発生しうるのかや
アプリ側で担保しなくてはいけないデータ整合性が明文化されないから
データウェアハウスのようにデータの追加はあっても更新のない情報系データベースの場合は
全く正規化しないわけではないけど最初から分析しやすい形を念頭に設計する
0725NAME IS NULL
2020/10/20(火) 14:09:08.77ID:???やはり特殊な用途を除き正規化するのが基本なのですね
ありがとうございます
身近で詳しそうな人に正規化した設計を提出したところ
フラットに作り直すよう指摘され、明確な理由がわからず
もやもやしておりました
開発観点の他に運用・保守観点（項目の追加/削除、データの追跡可能性）
を想像してみても特に正規化を避けるべき理由が思い当たりませんでした
0726NAME IS NULL
2020/10/20(火) 14:56:58.07ID:???そもそもそれほんとにちゃんとした正規化が出来てるのか？
正規化を避けるべき理由はないのか？
そもそも設計を提出ってなんだよ。業務なのか？
だったらなぜ上司ではなく詳しそうな人なんだ
0727NAME IS NULL
2020/10/20(火) 15:05:03.53ID:???まあ指摘した本人に理由を聞くべきなのは間違いない
0728NAME IS NULL
2020/10/20(火) 15:31:38.20ID:???そっちのほうがいい気がする
というようなことを言っていました
> もしかしてRDBじゃなくMongoみたいの使う前提なのかな？
RDBです
0729NAME IS NULL
2020/10/20(火) 16:12:36.27ID:???開発予算がないから手抜きで作るとか政治的な事だったり
0730NAME IS NULL
2020/10/20(火) 17:39:35.83ID:???もう少し具体的にわからんとなんとも言えないね
フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない
0731NAME IS NULL
2020/10/20(火) 19:58:51.65ID:???世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい
0732NAME IS NULL
2020/10/21(水) 00:08:11.04ID:???場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな
気にやまないことだと思います
0733NAME IS NULL
2020/10/21(水) 01:41:41.26ID:???必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい
0734NAME IS NULL
2020/10/21(水) 01:49:04.44ID:???気持ち悪い設計って確かにある
0735NAME IS NULL
2020/10/21(水) 13:04:54.08ID:???0736NAME IS NULL
2020/10/21(水) 13:07:36.31ID:???0737NAME IS NULL
2020/10/21(水) 17:30:47.48ID:???クソ設計なテーブルで、プログラム書かされて死にそうになったことある
0738NAME IS NULL
2020/10/23(金) 14:20:38.63ID:???ボイスコッドの方が難易上なの？
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある……
0739NAME IS NULL
2020/10/23(金) 23:40:51.85ID:???導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる
第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ
0740NAME IS NULL
2020/11/30(月) 22:31:04.06ID:???数字のみの連番にする？ 何か文字列も付与する？ ケースバイケース？
数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか
0741NAME IS NULL
2020/11/30(月) 23:55:06.66ID:???分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合
でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな
他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する
0742NAME IS NULL
2020/12/01(火) 00:00:33.65ID:???0743NAME IS NULL
2020/12/02(水) 02:52:19.08ID:???なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する
これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、２つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したｗ
0744NAME IS NULL
2020/12/02(水) 09:55:10.43ID:???それすでに代理キーじゃなくね
0745NAME IS NULL
2020/12/04(金) 10:49:18.51ID:???代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど
0746NAME IS NULL
2020/12/04(金) 11:41:14.98ID:???>>715
0747NAME IS NULL
2021/01/04(月) 11:20:12.25ID:???0748NAME IS NULL
2021/01/04(月) 12:28:55.25ID:???他は、コロコロ変わるものだから
別にして良いと思う
0749NAME IS NULL
2021/01/04(月) 18:53:45.42ID:???商品マスタの構成や商品マスタをどう使う前提なのかによる
一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い
18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)
あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通
0750NAME IS NULL
2021/01/04(月) 21:39:09.85ID:???スレ検索してもulid 出てこないね。
0751NAME IS NULL
2021/01/04(月) 22:01:16.35ID:???0752NAME IS NULL
2021/01/04(月) 23:04:35.94ID:???128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。
日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな？
0753NAME IS NULL
2021/01/04(月) 23:37:36.45ID:???UUIDを必要とするユースケース以外でULID使うことないでしょ
0754NAME IS NULL
2021/01/04(月) 23:55:03.99ID:???0755NAME IS NULL
2021/01/05(火) 00:56:58.70ID:???ありえないな。日時でソートしたいならちゃんと日時の項目もつべき
0756NAME IS NULL
2021/01/05(火) 01:50:26.16ID:???日時の意味を持たせてるということにはならないよ
ULIDから日時を取り出してデータ作成日時として利用するなら別だが
0757NAME IS NULL
2021/01/05(火) 15:53:27.55ID:???シーケンスとか生成順に使うような場合って実際には結構あるけど、本来それも間違ってる
昔のオラクルのマニュアルとか生成順は保証しないようなこと書いてあったんだがなぁ
0758NAME IS NULL
2021/01/05(火) 17:16:48.59ID:???オラクルが正だと思ってるようなやつは中途半端な知識で
斜め上の御託を並べ立てるやつが多くて困る
0759NAME IS NULL
2021/01/05(火) 20:05:33.88ID:???サロゲートキーに一意保障以外の意味を持たせるなって大原則をまず理解しような
0760NAME IS NULL
2021/01/05(火) 20:08:21.25ID:???UUIDは日時でソート出来ない。
ULIDはソート出来るだけでありがてぇ。パーティショニングで役に立ちそう。あ、DB発番しないよ。
0761NAME IS NULL
2021/01/05(火) 20:24:27.35ID:???インデックスの効率落ちそうだ
0762NAME IS NULL
2021/01/05(火) 22:59:49.77ID:???なんで2つ意味を持たせると良くないのかをまず考えろよ
その理由を理解せずにトンチンカンなことばっかり言ってマウント取ろうとするからいつもバカにされてるんだぞ
0763NAME IS NULL
2021/01/09(土) 14:41:54.56ID:???自分740の質問した人間なので気になる
きのこたけのこ論争みたいなもんで正解はないやつ？
0764NAME IS NULL
2021/01/09(土) 16:21:49.00ID:???ULID使いたければ特徴と限界を理解した上で使えばいい
まだ比較的新しいものだから標準ライブラリ相当で安定した実装が提供されてる言語は少ない
二つの意味を持たせてる云々は少し考えればわかるでしょ
0765NAME IS NULL
2021/01/10(日) 00:03:48.39ID:???0766NAME IS NULL
2021/01/10(日) 07:38:57.64ID:???インサートが遅くなるアレ？
ulid 解決できるんだ！？
0767NAME IS NULL
2021/01/10(日) 08:36:14.08ID:???0768NAME IS NULL
2021/01/10(日) 08:59:33.73ID:???0769NAME IS NULL
2021/01/10(日) 16:24:43.84ID:???データが無駄にデカイし
インデックスもやたら膨らむしで
主キーに使うのも考えもんだな
気持ちはわからんでもないが
0770NAME IS NULL
2021/01/10(日) 16:25:36.71ID:???0771NAME IS NULL
2021/01/10(日) 18:29:44.20ID:???衝突しない前提なら、衝突したときのリトライ処理等は不要だ
つまり衝突したときの対処してるかって質問だろ
0772NAME IS NULL
2021/01/10(日) 18:59:06.79ID:???ユーザーにリトライを促すような個別の対処はしてなくても集約エラーハンドラで結局対処してる
0773NAME IS NULL
2021/01/10(日) 20:54:05.63ID:???まあ、お前がやってないだろうことは理解した
GUIDが衝突したって話は聞いたことがある
UUID衝突の可能性はゼロではないんだが、まあ起こったときの重要度次第か
0774NAME IS NULL
2021/01/10(日) 20:58:18.48ID:???お前質問者じゃないじゃん
0775NAME IS NULL
2021/01/10(日) 21:33:58.44ID:???だったらオートインクリメントで良い気がする。
0776NAME IS NULL
2021/01/10(日) 21:36:18.27ID:???0777NAME IS NULL
2021/01/10(日) 22:06:27.15ID:???0778NAME IS NULL
2021/01/10(日) 22:26:37.20ID:???0779NAME IS NULL
2021/01/11(月) 18:12:04.80ID:???0780NAME IS NULL
2021/01/11(月) 19:03:34.36ID:???単純に内容がつまらない。
0781NAME IS NULL
2021/01/11(月) 21:33:51.50ID:???理解に苦しむ
0782NAME IS NULL
2021/01/11(月) 22:15:19.50ID:???0783NAME IS NULL
2021/01/11(月) 23:24:18.82ID:???机上の知識だけでコメントしやすい内容か
設計の経験がないとコメントしにくい内容かの違い
珍しくにぎわってるからいいんじゃないの
0784NAME IS NULL
2021/01/27(水) 15:50:40.26ID:???https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8
扱ってる題材のレベルが低いのは初心者向けだからいいとしても
こんな問題だらけのデータモデルとユースケース書いて平気な顔してる開発者はやばいよな？
0785NAME IS NULL
2021/01/27(水) 18:11:58.87ID:???これの気持ちだけちょっとわかる
やれoop、やれdddのお作法に合わせて
少ない件数でテストしてできました！
とかやる奴
0786NAME IS NULL
2021/01/27(水) 21:24:38.53ID:???0787NAME IS NULL
2021/01/27(水) 22:06:01.60ID:???0788NAME IS NULL
2021/01/27(水) 22:17:56.84ID:???判断力がない奴が読むと、とても危険
0789NAME IS NULL
2021/01/27(水) 23:20:18.99ID:???>>783は至言
0790NAME IS NULL
2021/01/27(水) 23:29:01.05ID:???グルグルSQLどころか
ぐるぐるコネクションされて
性能調査に回って来た時には吹いたから
気持ちはまあわかる
コードのオブジェクト指向的
美しさ、べき論を説かれたが
俺はプログラマーじゃないから
ようわからんかった
0791NAME IS NULL
2021/01/27(水) 23:59:32.65ID:???0792NAME IS NULL
2021/01/28(木) 00:19:06.32ID:???0793NAME IS NULL
2021/01/28(木) 00:57:25.39ID:???前任者はどう作ったかというと、まず商品一覧を取得するSQLを発行した
そのSQLが返してくれる商品一覧に対して、一つずつ詳細取得するSQLを発行した
10件位の時は問題がなかった。多分前任者はこれでOKにしたんだろう
ショップがオープンして、100件、1000件と扱うようになった途端、
メチャクチャに処理に時間が掛かるようになった
で、どう直したかというと、商品一覧を取得する段階で、細かく詳細も取得するようにした
詳細取得が商品種類毎に違っていて、SQLは場合分けが必要で複雑になってしまったが
客は結果を見て喜んでOKを出してくれた
なんでこうなったかと考えて見ると、詳細設計書段階で、
取得する手順の記述があったからのようだ
設計書はとてもシンプルで綺麗な記述になっていた
※この話はフィクションです、実在する人物・企業とは関係ありません
0794NAME IS NULL
2021/01/28(木) 07:25:30.60ID:???まあなんにしても、DB設計の話じゃないな
0795NAME IS NULL
2021/01/28(木) 11:06:31.58ID:???マイクロサービスに限らず逐次処理と一括処理とでAPIを分けるのが常識なので
テスト以前のAPIのレビュー時に気づくべきことじゃないか？
0796NAME IS NULL
2021/01/28(木) 13:02:17.02ID:???ORM経由のN+1は仕組みをよく理解してない人間がやらかすけど
そういうのも本番環境に出る前には確実に修正される
DB側で検知する仕組み入れとくと確実かもね
0797NAME IS NULL
2021/01/28(木) 19:08:58.61ID:???これはヒドイ
プレミアム会員フラグや商品価格を変更できないw
ぐるぐる以前の問題
0798NAME IS NULL
2021/01/28(木) 20:39:20.13ID:???「価格改定の場合は新規に商品IDを発行する」なんて条件が書いてあったりする
情報処理試験のパターン。
0799NAME IS NULL
2021/01/29(金) 14:26:13.74ID:???同じ商品に対して複数のPKを発行できるようにするならモデルが違ってくる
0800NAME IS NULL
2021/01/29(金) 16:10:44.32ID:???0801NAME IS NULL
2021/01/29(金) 18:53:57.86ID:???読み取り用にはViewを用意してやるといい
各SQLで毎回ケアするのは無駄
0802NAME IS NULL
2021/01/29(金) 22:45:33.21ID:???>同じ商品に対して複数のPKを発行
意味不明。
「同じ商品に対して複数の商品ID」なら意味が通じなくもないが
その部分は>>784には描かれていない。
0803NAME IS NULL
2021/01/29(金) 23:19:36.29ID:???「同じ商品に対して複数の商品ID」を発行するとして
どうやって同じ商品かどうかを判別するの？
0804NAME IS NULL
2021/01/29(金) 23:26:28.28ID:???0805NAME IS NULL
2021/01/30(土) 00:26:36.49ID:???それを一般的には商品IDと呼ぶことが多いから複数の商品IDじゃなく複数のPKと書いたわけ
名前は別にいいんだけど
同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
それをモデルに描かないのはありえない
それにある商品の標準価格を変えようとすると
対応するプレミアム価格も変更が必要になる
なら別テーブルにする意味ない
0806NAME IS NULL
2021/01/30(土) 03:02:35.12ID:???0807NAME IS NULL
2021/01/30(土) 08:22:17.42ID:???>名前は別にいいんだけど
>同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
>それをモデルに描かないのはありえない
そりゃ設計書としてならあり得なんだろうが実際>>784には商品とか
商品名とか描いてないじゃん。そこで説明したいポイントには関係ないから
省略したんだろうが。
>同じ商品かどうかを判別するための識別子が必要だよね
>それを一般的には商品IDと呼ぶことが多いから
一般にはそういうことが多いとしても、「商品ID」は絶対そうでなくては
ならないという決まりも無いわけなんで、そこはちゃんと定義を
確認しなきゃならん。
>複数の商品IDじゃなく複数のPKと書いたわけ
PKってのはテーブルの定義なんでそこは明らかに間違い。
「商品に対する商品ID」か「商品テーブルのPK」じゃなきゃ
意味が通じない。
0808NAME IS NULL
2021/01/30(土) 11:58:25.05ID:???>「価格改定の場合は新規に商品IDを発行する」
その場合でも注文データに確定した支払い金額を記録するぞ
バッチ処理でユーザーごとの購入金額を集計するのに
マスタから価格持ってくるような設計はやばい
0809NAME IS NULL
2021/01/30(土) 12:01:57.13ID:???わかってないのに無理してレスすんな
0810NAME IS NULL
2021/01/30(土) 12:23:10.14ID:???0811NAME IS NULL
2021/01/30(土) 12:49:10.58ID:???ぐるぐる SQLは性能に問題が出るからやめようねって話なんじゃないの？
テーブル設計はあくまで例であって、そこをここで突っ込んでも…
0812NAME IS NULL
2021/01/30(土) 15:04:12.14ID:???0813NAME IS NULL
2021/01/30(土) 16:13:55.14ID:???0814NAME IS NULL
2021/01/30(土) 17:35:24.51ID:???まともなDB設計ならぐるぐるSQLすら発生しないだろ
0815NAME IS NULL
2021/01/30(土) 18:02:21.65ID:???0816NAME IS NULL
2021/01/30(土) 18:13:42.82ID:???コードの美しさとは無関係というか両立できる問題じゃないかなあという気がするんだがどうなんだろう
> ぐるぐるコネクションって、ループの内部で都度接続と切断繰り返してる処理であってる？
>>808
現時点の注文（＝買い物かご）と注文履歴は別管理なんじゃねって言う勝手な想像
0817NAME IS NULL
2021/01/30(土) 18:14:32.10ID:???うちの販売システムは発注伝票の内容は全てトランザクションデータとして保存するし
商品マスタは通常もセットも含めて1テーブルだけど
0818NAME IS NULL
2021/01/30(土) 18:49:31.12ID:???顧客や顧客種別ごとに単価を管理する場合はそうするのが普通
ただプレミアム会員向けの単価が登録されてなければ標準単価を採用するみたいなロジックはアンチパターンだから普通はやらない
単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する
0819NAME IS NULL
2021/01/30(土) 23:22:05.33ID:???コードの美しさ云々は単なるいいわけでしょ
リモートのAPI呼び出しをローカルに閉じた関数呼び出しと同じように扱おうとする連中と同じ
0820NAME IS NULL
2021/01/30(土) 23:26:08.18ID:???俺「一瞬で終わって草ァ！SQLすげぇｗｗｗｗｗｗｗｗ」
陰キャ先輩「はぁ…ぐるぐるSQLは止めてください」
俺「あっ すみません気を付けます… ぐるぐるって何でしょうか…」
陰キャ先輩「知らないの？スキーマがこうでアプリのコードがこうだとするでしょ」
俺「あっあっ はい」
陰キャ先輩「ループがねオーバーヘッドがねマイクロサービスとか言ってる奴等なんて」
俺「はい… はい…」
0821NAME IS NULL
2021/01/31(日) 05:54:37.13ID:???>そこで説明したいポイントには関係ないから省略したんだろうが。
そもそも、元のやつの設計が複数の商品IDを発行する設計だと思ってるのか？
つかまあ、あれはほんとのシステムの設計としてはあり得んレベルだけどな
あの記事が言いたかったのはそんなことじゃないだろ
0822NAME IS NULL
2021/01/31(日) 09:41:56.04ID:???本番稼働を前提に設計レビューをしてくれる掲示板
0823NAME IS NULL
2021/01/31(日) 11:13:07.54ID:???単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する
これと、価格テーブルが1個であることとは矛盾しない
価格種別を決定するコンテキストがあれば良い
0824NAME IS NULL
2021/01/31(日) 11:17:15.54ID:???あれを許容できるやつは普段同レベルの設計をしてるとしか思えない
0825NAME IS NULL
2021/01/31(日) 11:24:40.01ID:???0826NAME IS NULL
2021/01/31(日) 11:31:41.57ID:???それ同じこと言い換えてるだけだよ
0827NAME IS NULL
2021/01/31(日) 15:21:03.28ID:???それを理解せずに場当たり的なSQLの修正しか考えないのは悪手でしかないわな
0828NAME IS NULL
2021/01/31(日) 15:53:35.89ID:???下請け孫請けでDB設計には口出しできないんだろ
0829NAME IS NULL
2021/02/02(火) 10:43:18.74ID:???運用中のものを停止してでもやり直す？
それとも現状を変えずに追加し続ける？
0830NAME IS NULL
2021/02/02(火) 12:21:21.06ID:???放置
ちょろっと修正
次のプロジェクトで合わせて修正
独立した修正プロジェクトで対応
障害として対応
0831NAME IS NULL
2021/02/02(火) 14:32:11.31ID:???良くて修正プロジェクト、悪いと障害対応だろうな
0832NAME IS NULL
2021/02/02(火) 19:43:17.14ID:???問題がなければ基本放置だが、遅いとかいうクレームでたらまあ協議だな
0833NAME IS NULL
2021/02/02(火) 22:02:04.11ID:???データや処理の間違いで被害を出す恐れがあるなら早めに対処しなきゃならんだろうが、
それも予想される被害の大きさと発生確率によるリスク算定次第。
運用で逃げられるようなものだったら後回しにしたり。
>>831
障害と言えるような具体的な不具合って挙がってたっけ？
0834NAME IS NULL
2021/02/02(火) 22:40:37.58ID:???DB設計は単体で障害になるわけじゃないから
アプリの仕様や運用、ビジネス要件との合わせ技
0835NAME IS NULL
2021/02/03(水) 10:02:04.48ID:???悪い設計のまま追加するか、それともやり直すか
前者だとコストもリスクも低いが、将来困る
後者だとその逆。
経営判断なら前者になるだろうな
0836NAME IS NULL
2021/02/03(水) 12:42:18.54ID:???0837NAME IS NULL
2021/02/03(水) 13:14:58.53ID:???似たようなことは日常茶飯事で起きてると思うぞ
0838NAME IS NULL
2021/02/03(水) 18:03:06.12ID:???注文っていったら1回で複数商品注文とかするだろ？
注文テーブルにそんな考慮もないようなシステムで何をするんだい？ｗ
0839NAME IS NULL
2021/02/03(水) 18:27:35.71ID:???1注文あたり1種類の商品のみというビジネスモデルも実際に存在するぞ
0840NAME IS NULL
2021/02/03(水) 19:35:01.61ID:???0841NAME IS NULL
2021/02/03(水) 20:13:09.59ID:???単にテーブルＡがテーブルＢを参照し、とか言ってればよかったのにな
0842NAME IS NULL
2021/02/03(水) 20:24:10.77ID:???UIで制限することはあってもそんなビジネスモデル前提で設計しないと思うけどなぁ
まあ要件みたせばあんなDB設計でもいい人もいるんだからいいのか
0843NAME IS NULL
2021/02/03(水) 20:44:09.02ID:???そういう要求がない限りシンプルな構造にしておくという考え方はあると思うが。
0844NAME IS NULL
2021/02/03(水) 21:48:04.89ID:???価格変更時は必ず新しい商品IDになるとかは実際にあるけど
注文データに金額を記録しないのは伝票としての要件を満たさないからまずありえない
0845NAME IS NULL
2021/02/03(水) 22:24:40.50ID:???どんな要件を満たしてない？
0846NAME IS NULL
2021/02/04(木) 15:35:48.76ID:???特定のDBMSや永続化技術を意識するレイヤーと
ループしながらビジネスルールの判定をするレイヤーを分けたい場合に
ループが途中でブレイクしても確実にコネクションを切断する仕掛けが必要になる
言語やプログラマのスキルによってはその仕掛けが実現できないので
ぐるぐるコネクションになっちゃう
0847NAME IS NULL
2021/02/04(木) 16:05:13.13ID:???0848NAME IS NULL
2021/02/04(木) 20:16:34.87ID:???0849NAME IS NULL
2021/02/04(木) 21:22:56.40ID:???一応、日時(例えば20210204125959001)と乱数(80bit分)は作った。
BASE32に変換出来無いから、10進数を36進数(0-9 A-Zの36。CONV関数使用)してみた。
内部だけで使うならアリなんだけど、ユーザーに見えるところはBASE32がいいんだよなぁ。。。
0850NAME IS NULL
2021/02/04(木) 22:57:48.90ID:???MySQLへスレへどうぞ
0851NAME IS NULL
2021/02/05(金) 07:22:54.69ID:???は結論出てたりする？
https://gihyo.jp/dev/serial/01/sql_academy2/000301
うちの古いシステムは大量にある名称マスタをこの方法で取り扱ってるけど、
やめた方がいいのかなと。
0852NAME IS NULL
2021/02/05(金) 12:23:22.50ID:???DB設計の観点からだけいえばEAVと一緒で100%やめたほうがいい
ポリモーフィズムでもなければオブジェクト指向は全く関係ない
RDB以前の汎用機で使われてたやり方
実際にやめるかどうかはシステムの寿命や変更の頻度を考えた場合に
手間をかけるメリットがあるかどうか
0853NAME IS NULL
2021/02/05(金) 12:31:10.80ID:???流石に動いてるものは触れない。
仮に新しく作り直すとしたら
大量にマスタが作られて、大量にCRUDの画面が作られる問題が出てくる
これ皆どう解決してるんだろう
もう気にせず愚直に作った方が精神的にもシステム的にもいいんだろうか。
0854NAME IS NULL
2021/02/05(金) 17:00:05.17ID:???自分だったら単一参照テーブルにするなら内部キー(PK)・識別子・外部キー・内容の様にして
トランザクションには内部キーを保持したい
理由はテーブルの結合の際にトランザクションとマスタを外部キーで結合して
さらに識別子をハードコードするのは抵抗があるから
でもこういう設計をしても結合の際に識別子を条件に付ける人がいそうなので困る
0855NAME IS NULL
2021/02/05(金) 18:14:28.40ID:???複合キーじゃなくサロゲートキーを導入するという話なんだろうけど
識別子や外部キーって用語の使い方を間違えてるから全然伝わらないぞ
識別子は基本的にそれによって行を特定できるキーのこと
外部キーはForeign Keyのこと
商品IDとJANコードのようなのは内部ID/外部IDとは言うけど外部キーとは言わない
0856NAME IS NULL
2021/02/05(金) 18:17:26.28ID:???マスタメンテ画面が必要ないものもたくさんあると思うんだけど
必要なら汎用的なマスタメンテ画面を作ればいいんじゃない
0857NAME IS NULL
2021/02/05(金) 19:08:27.08ID:???お前が勝手に言葉変えてるだけだろ
0858NAME IS NULL
2021/02/05(金) 19:08:56.72ID:???いっぱいお客さんいると男女ですら変更したいという要件もある…
さらにやっぱり英語名も持ちたいとか色々要件増えて管理する項目も微妙に変わってくんだよな…
で、それを汎用項目みたいな持たせ方してるんだよ…
恥ずかしながらこの記事の作者同様、若い頃は便利だなあと思ってた。
よし、一念発起してSexMaster作るか
0859NAME IS NULL
2021/02/05(金) 21:09:23.08ID:???0860NAME IS NULL
2021/02/05(金) 21:31:59.63ID:???メンテが必要でSQLで手動更新しないなら画面用意する他ないな
Railsのようなのでscaffoldでサクサク作るか
metadata用のAPI使ってOTLTと同じような共通汎用メンテ画面を作るか
0861NAME IS NULL
2021/02/05(金) 21:34:13.42ID:???わざわざ説明して欲しいの？
0862NAME IS NULL
2021/02/05(金) 21:42:58.60ID:???そういうスレだしな。
でも根拠なしにテキトーなこと言ってるだけの奴は「ググれ」「自分で考えろ」とかいってごまかす。
0863NAME IS NULL
2021/02/05(金) 22:54:38.55ID:???記事に欠点が列挙されてるんだがそれは読んだのか？
0864NAME IS NULL
2021/02/05(金) 23:09:49.13ID:???0865NAME IS NULL
2021/02/06(土) 00:05:44.88ID:???SQLには詳しいけどDB設計に詳しい人ではないから
0866NAME IS NULL
2021/02/06(土) 00:11:31.24ID:???記事にメリットとしてあげられてる点も鵜呑みにせず本当かどうか考えたほうがいい
0867NAME IS NULL
2021/02/06(土) 05:47:12.37ID:???0868NAME IS NULL
2021/02/06(土) 09:45:46.26ID:???正確に言うと、件のマスターの主キーが複合主キーになるから参照整合性制約をかけようとするなら
面倒くさい＆無駄ってことだね。
それを必要としない用途で使う分には問題ないかもしれない。
0869NAME IS NULL
2021/02/06(土) 14:26:16.22ID:???そう
担保するためには複合主キー+チェック制約がいるので
OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
参照する側が取りうる値の範囲を参照制約以外で担保する前提で
異なるコード体系じゃなく統一されたコード体系のテーブルなら
DB設計的にも有りだけどそれはもうOTLTじゃない
0870NAME IS NULL
2021/02/06(土) 19:44:15.11ID:???0871NAME IS NULL
2021/02/06(土) 20:44:19.48ID:???> OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
とか感覚で語ってる奴の相手しなくていいかと
0872NAME IS NULL
2021/02/06(土) 21:33:46.92ID:???0873NAME IS NULL
2021/02/06(土) 21:40:35.94ID:???1:男←性別
2:女
3:北海道←ここから都道府県
4:青森
...
80:赤←ここから色
81:青
みたいに管理するってこと？
0874NAME IS NULL
2021/02/06(土) 21:58:10.25ID:???自分が設計したDBは可変特にユーザーが何か設定するようなデータは必ずマスタとして登録してたわ
何でもかんでも使うのは乱暴だけど純粋にシステムとして値と内容だけで完結するようなデータであればありだと思う
0875NAME IS NULL
2021/02/06(土) 22:46:52.67ID:???よくわからん
必ずマスタとして登録って、つまりOTLT的なマスタのこと？
0876NAME IS NULL
2021/02/06(土) 23:18:19.50ID:???0877NAME IS NULL
2021/02/07(日) 08:38:41.24ID:???0878NAME IS NULL
2021/02/07(日) 10:46:31.05ID:???セックスマスター持ってるかどうかまでは言及しないな
0879NAME IS NULL
2021/02/07(日) 13:58:15.18ID:???それは統一されたコード体系で扱えるデータじゃないからすぐ破綻すると思うが
データ構造だけで言えば下のように管理して特定の値はIDのみで引けるようにしておくイメージ
表示の多言語対応なんかで使う
ID:カテゴリ:表示名
1:性別:男
2:性別:女
3:都道府県:北海道
4:都道府県:青森
...
80:色:赤
81:色:青
0880NAME IS NULL
2021/02/07(日) 13:59:52.25ID:???作る場合はgenderテーブル
0881NAME IS NULL
2021/02/07(日) 14:01:55.50ID:???0882NAME IS NULL
2021/02/07(日) 14:58:31.26ID:???うちは男性、女性、不明で管理してるけど
この手の区分は全てドキュメントの辞書管理してるだけでわざわざテーブルに登録してない
0883NAME IS NULL
2021/02/07(日) 20:16:00.19ID:???性別は名称付きでってなったらどうするの？
0884NAME IS NULL
2021/02/07(日) 20:25:45.49ID:???case で名前に変換すりゃいいだけじゃね
0885NAME IS NULL
2021/02/07(日) 20:48:57.88ID:???0886NAME IS NULL
2021/02/07(日) 21:03:19.72ID:???0887NAME IS NULL
2021/02/07(日) 21:09:16.30ID:???生年月日は和暦でお願いといっしょでここでする話じゃない
0888NAME IS NULL
2021/02/07(日) 21:11:51.65ID:???今日だけSQL書き換えればいいだけでしょ
アドホックな要求ならそれで充分
0889NAME IS NULL
2021/02/07(日) 22:24:53.92ID:???0890NAME IS NULL
2021/02/07(日) 22:40:40.47ID:???保守性が低い
あなたの会社は毎回sql書き換えてリリースされるのですか
0891NAME IS NULL
2021/02/07(日) 22:54:02.61ID:???マスタを変更するほうが保守性が低い
0892NAME IS NULL
2021/02/07(日) 23:07:35.14ID:???0893NAME IS NULL
2021/02/07(日) 23:10:40.93ID:???令和のために元々管理していなかった元号をマスタ管理するようになったところは多いと思う
0894NAME IS NULL
2021/02/07(日) 23:12:38.92ID:???それを含む会員データをいろんな用途で使うなら間違いなく性別マスターを作る
でも今回発送するDMに限っては”男性”じゃなく”♂”で表示したいとなっても
性別マスターを更新して対応したりはしない
アドホックに表示をカスタマイズしたいという要望が
恒常的に発生してシステム化が必要な場合は
カノニカルな表記とは別にマッピング機能を追加する
0895NAME IS NULL
2021/02/08(月) 05:59:15.42ID:???アドホックの意味わかる？
まあ100万件超えないならExcelにエクスポートして置換でもいいかもな
0896NAME IS NULL
2021/02/08(月) 06:07:15.07ID:???保守性と言うかどこで使われてるかわからんマスタの変更なんて簡単にできないよね
本当にいろいろな表示の仕方が恒常的に要求されるならマスタに表示用の列を複数持つわ
id|表示名1|表示名2|表示名3|…
1|男|♂|雄|…
2|女|♀|雌|…
0897NAME IS NULL
2021/02/08(月) 07:03:16.85ID:???ラテン語はわからないです…
0898NAME IS NULL
2021/02/08(月) 07:58:09.88ID:???0899NAME IS NULL
2021/02/08(月) 12:49:21.91ID:???「今日だけ絵文字で表示したいんですけど〜」
「じゃ、お列追加しときますね〜」
0900NAME IS NULL
2021/02/08(月) 15:13:29.86ID:???日本語理解できないのか？
> "恒常的" に要求されるならマスタに表示用の列を複数持つ
今日だけの話ならcaseでも専用の表示マスタでも好きにやってくれ
0901NAME IS NULL
2021/02/08(月) 15:45:13.95ID:???0902NAME IS NULL
2021/02/08(月) 16:19:26.78ID:???俺の中では851なんて全体で合意をとればいい話でどっちだってかまわないと思ってる話題
ただ値（ID、コード）にAは数値、Bは文字と意味を持たせたいなら別管理したほうがストレスはないと思う
0903NAME IS NULL
2021/02/08(月) 16:44:21.38ID:???で、お前さんならどうするの？
0904NAME IS NULL
2021/02/08(月) 17:50:13.97ID:???id|表示名1|表示名2|表示名3|表示名4|表示名5|表示名6|表示名7|表示名8|…
↑こういう設計見たらどうするの？
0905NAME IS NULL
2021/02/08(月) 17:51:51.04ID:???マスタを全て分けると必要最低限の管理画面が必要。その開発工数がバカにならない。
上でも挙がっているが
Rubyのスキャフォールドは便利だが、大規模システムで動的型付け言語は別の点でやばくなる。
asp.net mvcのスキャフォールドはrubyのパクリだが静的型付けなのでまだマシ。
これらに限らず最近のフレームワークは似たような構築機能があるだろう。
加えてシステムの変更に強い。
この名称マスタだけカラムを追加したいみたいなことに対応しやすい。
小規模で変更がないシステムであれば…名称マスタも少ないだろからやっぱりちゃんとマスタ作ったほうがいいんじゃない？
0906NAME IS NULL
2021/02/08(月) 18:32:42.95ID:???いいんじゃないの？
表示名nみたいな名前はどうかと思うけど
で、>>903の回答は？
0907NAME IS NULL
2021/02/08(月) 19:34:38.74ID:???0908NAME IS NULL
2021/02/08(月) 20:10:58.13ID:???0909NAME IS NULL
2021/02/08(月) 20:54:45.84ID:???0910NAME IS NULL
2021/02/08(月) 21:12:25.50ID:???セックスマスターにインサートしちゃう
0911NAME IS NULL
2021/02/08(月) 21:27:56.93ID:???そういうゴタクはよりマシなセックスマスター提示してから言わないと恥ずかしいだけやでww
0912NAME IS NULL
2021/02/08(月) 21:34:52.75ID:???TO_DOU_FU_KEN_MASTERも作らないの？
0913NAME IS NULL
2021/02/08(月) 22:34:51.69ID:???0914NAME IS NULL
2021/02/08(月) 22:52:38.12ID:???マスタを分けてもテーブルの構造に応じて
メンテ画面の内容が変わるようなのを1つ作っとけばいいだけでしょ
異なるコード体系を1カラムに詰め込むのはC#でdynamic typeを使うようなもの
0915NAME IS NULL
2021/02/08(月) 23:14:23.60ID:???都道府県マスターと同じでメンテ画面は必要ないことのほうが多い
0916NAME IS NULL
2021/02/09(火) 12:09:04.76ID:???異なるコード体系を1カラムに突っ込むなんて書いてないつもりなんだが。
んで、そういう動的に画面生成されるようなやつってどうなんだろ
動的にsql組み立てることになって結局メンテナンスしづらくなると思う。
0917NAME IS NULL
2021/02/09(火) 12:45:28.48ID:???使用するユーザーが決める
それと同じように作ればいい
0918NAME IS NULL
2021/02/09(火) 16:02:15.61ID:???>加えてシステムの変更に強い。
>この名称マスタだけカラムを追加したいみたいなことに対応しやすい。
じゃ”この名称マスタ”ってどういう構造を想定して言ってるの？
0919NAME IS NULL
2021/02/09(火) 16:11:20.57ID:???それをRDBでやる方法がよくわからないからOTLTみたいなものになってるんだろうね
0920NAME IS NULL
2021/02/09(火) 17:16:30.95ID:???バカが話を脱線させるから851みたいな話はおわらないｗ
0921NAME IS NULL
2021/02/09(火) 17:51:32.88ID:???おれはOTLTじゃなくて
性別マスタ、都道府県マスタで別に管理しましょう派だよ？
たとえば都道府県マスタに名産物列を追加しましょう。
メンテナンス画面はめんどくさいけどちまちま直しましょう。
ってこと。
0922NAME IS NULL
2021/02/09(火) 17:56:14.58ID:???OTLTを前提にするならコードと名称以外の属性はもたないでしょ
0923NAME IS NULL
2021/02/09(火) 18:15:45.02ID:???そんな前提はすぐ崩れる
ソフトウェアには変更がつきもの
0924NAME IS NULL
2021/02/09(火) 18:32:23.44ID:???なるほど読み間違えてた
0925NAME IS NULL
2021/02/09(火) 18:44:25.95ID:???もともとの要件にない話なら問題外
開発中の変更であれば別テーブルに変更すればいいだけ
そもそもコードと名称しか管理しない前提の都道府県情報に
名産物なんて項目を増やすようなシステムなら最初から別テーブルになるし
そんなこと言い出したらOTLT禁止の前提でシステム（DB）設計してると思うわ
こういう話はごねたいだけの話題にしかならんね
0926NAME IS NULL
2021/02/09(火) 18:45:47.69ID:???>動的にsql組み立てることになって結局メンテナンスしづらくなると思う。
動的sql的なものは使わざるをえないけどORM使えば全然大変じゃない
0927NAME IS NULL
2021/02/09(火) 19:25:24.73ID:???だから禁止っつうかOTLT使うなって言ってるつーの
0928NAME IS NULL
2021/02/09(火) 19:27:36.02ID:???そんなORMあるか…？
そのobjectの型定義はどうなってるんだ？
AcriveRecord？
0929NAME IS NULL
2021/02/09(火) 19:53:07.87ID:???0なし
1あり
しか持たない〇〇テーブルたくさん持つの？
0930NAME IS NULL
2021/02/09(火) 20:30:48.58ID:???他の人も書いてるように、メンテナンスが発生しない&コードが少ないのであれば
メモリ内に持つ
意外とOTLT派が多いね
自分も大昔使っていたが、害の方が多いという印象。
0931NAME IS NULL
2021/02/09(火) 21:24:37.20ID:???「OTLT派」ってほど積極的に肯定している人はいないんじゃないかな。
ダメな理由がないなら使ってもいいじゃん、程度だと思うけどね。
>自分も大昔使っていたが、害の方が多いという印象。
その「害」を具体的に挙げたら建設的な議論になると思う。
ひとつは上で参照制約の話が挙げられていたが。
0932NAME IS NULL
2021/02/09(火) 21:47:29.79ID:???レコードが増えすぎると性能に影響が出る。そんな大量に突っ込むなよってはなしだが、使い所を分かってない人間はなんでも入れてくる。
変更に強いようで弱い。汎用性を意識して予備カラムみたいなのを用意するが結局足りなかったり、数値型と言ってもintとnumber、日付も時間まで持つかどうかで変わる。
型は厳密に。null非許容にできないのも痛い。
汎用性を重視するあまりカラム名が曖昧になる（なんとか1,2,3）
名前が適当だと後でわからなくなる。
それぞれにViewを定義したりして誤魔化してきたけど、使い所を誤る人がどうしても出てくるのだ。
0933NAME IS NULL
2021/02/09(火) 21:56:11.05ID:???そうやって具体的に挙げてもらえたら、あとは自分の案件にとってそれが
「害」になるのかどうか判断すりゃいいだけだね。
0934NAME IS NULL
2021/02/09(火) 22:13:24.03ID:???ActiveRecordにしろEFにしろORM経由でテーブルを扱うタイミングでは
ORMがテーブルの型を認識できてる必要はあるよ
Rubyなら動的に型定義可能なので
実行時に汎用メンテ画面で扱うテーブル一覧をDBから読み込んで
それ用のclassを定義したらActiveRecordで扱える
C#でも動的に型定義できるけどちょっと面倒くさいので
テーブルを新規に追加した時はスキャフォールドして型定義をプログラムに追加しとけばいい
テーブル名を変数で渡されたらリフレクションで型にすればあとは普通に使える
0935NAME IS NULL
2021/02/09(火) 22:33:31.23ID:???スキャフォールドって
モデルからViewとコントローラーのコードが生成されるけど
それぞれモデル名が頭につくから
SexControllerみたいになるよね
それにテーブル名渡すの？
urlがapi/v1/Sex/Index?table=sexみたいになるのかな？
で、EFは使わず、動的にsqlを組み立てるってこと？
なかなか強引だな。
0936NAME IS NULL
2021/02/09(火) 22:38:32.80ID:???これ書いといてなんだけど、同じデータベースの構成でいろんなお客さんにシステム導入しようとするとEAVの問題が出てくるんだよな
で、xmlやjsonを列に突っ込んでる
型を厳密にと言っときながら厳密でない型の列を定義してる俺を罵ってくれ
0937NAME IS NULL
2021/02/09(火) 22:53:09.69ID:???誰が見ても使っても満点の設計なんてできない以上それでかまわないと思うけど
0938NAME IS NULL
2021/02/09(火) 22:58:26.92ID:???0939NAME IS NULL
2021/02/09(火) 23:00:45.47ID:???ビューやコントローラを生成する必要はないから
モデルファーストでテーブルを追加/更新するならそのモデル定義をプログラムに追加するだけ
スキャフォールドって言ったのはデータベースの定義を読んでEFで扱えるようにするための話
> dotnet ef dbcontext scaffold --table Hoge
0940NAME IS NULL
2021/02/09(火) 23:38:34.79ID:???ViewContoroller使わないのは納得した。
渡したテーブル名はどこで使うの？
pocoで定義されたクラスに値入れて、addしてsavechanges
てのがEFの普通の流れだけど
そのクラス名はhogeだよね
そのクラス名が動的に変わる？
0941NAME IS NULL
2021/02/11(木) 09:05:41.50ID:???この手のほぼ更新のないマスタテーブルはDB管理者がsqlでメンテだな
0942NAME IS NULL
2021/02/11(木) 11:59:29.12ID:???リフレクション使うんだよ
カラム名やデータ型を共通化できるなら
リフレクションじゃなくジェネリックでも対応可
0943NAME IS NULL
2021/03/27(土) 19:52:09.74ID:JXErytnT日本人はカス民族。世界で尊敬される日本人は大嘘。
日本人は正体がバレないのを良い事にネット上で好き放題書く卑怯な民族。
日本人の職場はパワハラやセクハラ大好き。 学校はイジメが大好き。
日本人は同じ日本人やアジア人には厳しく白人には甘い情け無い民族。
日本人は中国人や朝鮮人に対する差別を正当化する。差別を正義だと思ってる。
日本人は絶対的な正義で弱者や個人を叩く。日本人は集団イジメも正当化する。
日本の芸能人は人の悪口で笑いを取る。視聴者もそれで笑う民族性。
日本人はコロナ感染者を一方的に差別し叩く。感染する奴が悪い主義の民族。
日本人は犯罪者の死刑拷問大好き。でもネットに書くだけで実行は他人任せ前提。
日本人は己の手は汚さない。
日本人は鯨やイルカを殺戮して何が悪いと開き直るが猫や犬には虐待する事すら許さない動物差別主義的民族。
日本人は「外国も同じだ」と言い訳するが文化依存症候群の日本人限定の対人恐怖症が有るので日本人だけカスな民族性なのは明らか。
世界中で日本語表記のHikikomori(引きこもり)Karoshi(過労死)Taijin kyofushoは日本人による陰湿な日本社会ならでは。
世界で日本人だけ異様に海外の反応が大好き。人の顔色を伺う媚びへつらう民族性。
世界幸福度ランキング先進国の中で日本だけダントツ最下位。欧米は上位。
もう一度言う「外国も一緒」は通用しない。日本人だけがカス。カス民族なのは日本人だけ.
陰湿な同級生、陰湿な身内、陰湿な同僚、陰湿なネットユーザー、他者を見下すのが生き甲斐の国民達。
こんなカス民族によるカス国家滅びたってどうでも良いし愛国心を持つ価値も無い。
0944NAME IS NULL
2021/03/27(土) 20:37:34.41ID:xBIdyDrIカスの日本人より
0945NAME IS NULL
2021/05/27(木) 22:14:23.71ID:???いろんな仕組みが発達したのに
いまだにDBのデッドロックの回避チェックを
人間が人力でやらんといかんのだ
0946NAME IS NULL
2021/05/28(金) 00:25:17.31ID:???0947NAME IS NULL
2021/05/28(金) 00:44:50.60ID:???呼び出し側のコードも含めて解析するとなると面倒くさいわな
普通に設計すればデッドロックで困ることなんてないからニーズもない
0948NAME IS NULL
2021/05/28(金) 10:16:32.81ID:???products
- id
- name
- description
product_classes
- id
- product_id
- type
- price
こんな設計でよろしいのでしょうか？
今まで1商品1レコードの単純なものしか扱った事がなかったので、こう言った場合のセオリーがわかりません
よろしければご教授下さい
0949NAME IS NULL
2021/05/28(金) 22:11:41.96ID:???0950NAME IS NULL
2021/05/29(土) 00:13:12.94ID:???種類の軸が1つだけで固定的なら基本的にはそれでいいと思う
2つのテーブルの関係は1対多の親子関係(親が存在しないと子も存在しない)なので
product_id + typeの複合主キーにするか
id付与してproduct+id + typeはユニークかつNOT NULLにするか
あとは
商品単位で管理する項目
派生商品単位で管理する項目
現物のみ・DLのみで管理する項目
を精査してモデルを調整する
種類の軸が複数ある(複数になる確率が高そう)なら
それをモデルに取り込んでいく必要がある
classはカテゴリに近い概念に使われるのでやめたほうがいい
英語ならproduct, product_variantが定番
0951948
2021/05/29(土) 08:38:41.36ID:???質問する前に調べていた所 EC-CUBEが、dtb_product, dtb_product_class と言う関係のようだったので、product_classes としましたが、正直自分も違和感があったので、product_variant採用させていただきます
主キーやユニークなども適宜設定していきたいと思います
丁寧な回答ありがとう御座いました
0952NAME IS NULL
2021/07/07(水) 07:18:27.74ID:???文字列扱いの列とはいえ、センサONを1,0で表して数値型の列として扱ったほうが適切なのでしょうか？
Id | data |
--------------
1 | 120 |
--------------
2 | 55 |
--------------
3 | センサON |
0953NAME IS NULL
2021/07/07(水) 09:41:32.05ID:???そのテーブルやdata列の意図・目的と
CREATE/UPDATE側・READ側でそれぞれどういう風に使うのかによる
アプリケーション全体の設定値を1テーブルに格納するようなケースで
型を揃えられないような場合は文字列で保存して読み取り側で変換する方法はそれなりに使われてる
(設定ファイルと同じ)
0954NAME IS NULL
2021/07/17(土) 19:18:27.33ID:???Q「DB使えますか？」
できる人「（論理設計やSQLなどの基本的なレベルでは）扱えます」
できない人「（接続先情報指定したら他のことは大体やってくれるORマッパーライブラリがやってくれるから）扱えます」
これを客観的に揃えてくれるのが資格。
凄い人だなとは見られないけど、しょうもない人ではないと安心してもらえる要素として有用
経歴の説明だけで嘘八百じゃないと信じてもらえるコミュ力の人にとっては無用かもしれない
0955NAME IS NULL
2021/07/17(土) 19:42:59.19ID:???何だコイツw
0956NAME IS NULL
2021/07/17(土) 20:20:24.66ID:???>Q「DB使えますか？」
質問がアホなので回答もアホになる
できる人は「使えますか？」の意図や定義を確認しようとする質問で返すか
自分でそれを補完して共通認識を明確しやすい回答をする
質問の意図を確認する質問をする人は
盲目的に回答する人に比べてできる人材である確率が飛躍的に高い
0957NAME IS NULL
2021/07/17(土) 22:12:13.49ID:???Javaのシルバーかゴールドも全員持ってたけどオブジェクト指向的な設計がまともにできる人も一人もいなかった
一般的な資格はできる・できないの指標ではなく最低限の表面的な座学知識を持ってるかどうかの指標
0958NAME IS NULL
2021/07/18(日) 02:20:49.23ID:???0959NAME IS NULL
2021/07/18(日) 08:19:42.48ID:???木に縁りて魚を求む
0960NAME IS NULL
2021/07/18(日) 08:31:55.54ID:???0961NAME IS NULL
2021/07/18(日) 11:25:11.08ID:???0962NAME IS NULL
2021/07/18(日) 13:04:22.39ID:???0963NAME IS NULL
2021/07/18(日) 14:19:58.12ID:???0964NAME IS NULL
2021/07/18(日) 14:48:22.38ID:???広い知識は必要なことが多いけどDB屋は何でも屋じゃないからな
0965NAME IS NULL
2021/07/18(日) 17:35:07.35ID:???かわいそうなやつ
0966NAME IS NULL
2021/07/18(日) 18:11:25.20ID:???用語の定義を軽視する人は論理設計に向かない
0967NAME IS NULL
2021/07/18(日) 18:12:46.43ID:???もしあるならぜひ知りたい
0968NAME IS NULL
2021/07/18(日) 18:19:37.52ID:???不必要なところまで偏狭な思想を持ち込むと煙たがられるぞ
0969NAME IS NULL
2021/07/18(日) 19:19:52.47ID:???0970NAME IS NULL
2021/07/18(日) 21:46:58.28ID:???高度試験合格してると「お勉強よく頑張ったんですね」って評価はできる
0971NAME IS NULL
2021/07/18(日) 22:02:15.15ID:???まさかER図を奇麗に描く能力とかじゃないだろうが。
0972NAME IS NULL
2021/07/18(日) 22:53:26.92ID:???バカはいいから黙ってろよｗ
0973NAME IS NULL
2021/07/19(月) 08:02:57.54ID:???設計に必要な最低限の知識を持っていることくらいはわかるだろう。
少なくともリレーションの正規化も知らないような箸にも棒にもかからないような奴は弾ける。
>>956のような面接での数回の質問よりはあてにできるんじゃないかねぇ。
0974NAME IS NULL
2021/07/19(月) 09:35:56.32ID:???って資格も取れない奴の捨てゼリフだろw
資格なんて>>973が言うように最低限の読み書きレベルの保証でしかない
0975NAME IS NULL
2021/07/30(金) 14:38:44.71ID:yprK+x+f0976NAME IS NULL
2021/08/03(火) 06:37:39.50ID: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 ■■■
いやぁ、ブルマ姿の女の子って、すごくいいもんですね。
お尻に砂がついてても気にせずにはしゃぎまわる子、
ブルマから下着がはみ出ていても気づかずに元気よく走り回る子、
ブルマに下着のラインが浮き出ていても元気よく動き回る子など、
魅力的な女の子たちの画像が満載となっています。
画像の中には既出や重複がある場合があることをご了承ください。
今夜はブルマ姿の女の子たちを遅くまでごゆっくりとご鑑賞ください。
では、また！
0977NAME IS NULL
2021/08/28(土) 16:28:41.43ID:ufCxb7Gf0978NAME IS NULL
2021/08/28(土) 17:39:11.36ID:PkRMMA3g0979NAME IS NULL
2021/08/28(土) 17:53:44.11ID:???考え方が偏った変な設計になっている気がする。
0980NAME IS NULL
2021/08/28(土) 18:17:32.02ID:PkRMMA3g0981NAME IS NULL
2021/08/28(土) 18:29:16.56ID:???実務でたまたま出会える設計なんて限られたものだろう。
0982NAME IS NULL
2021/08/28(土) 18:47:15.12ID:ufCxb7Gf0983NAME IS NULL
2021/08/28(土) 18:47:51.18ID:???0984NAME IS NULL
2021/08/28(土) 19:23:25.68ID:P8TnL8ql0985NAME IS NULL
2021/08/28(土) 20:11:55.56ID:???>いろんな設計に対応できる知識や能力を問うのが試験
なんてものが存在すればいいんだけどね
少なくともデータベーススペシャリストの試験ではそんなものは問われない
0986NAME IS NULL
2021/08/28(土) 20:46:37.45ID:???試験細目はこれ。
https://www.jitec.ipa.go.jp/1_13download/syllabus_db_ver4_0.pdf
0987NAME IS NULL
2021/08/28(土) 21:07:54.26ID:???そこに書いてる内容が全て試験で問われるわけじゃないんだよ
実務を知らないのかそれとも試験内容を知らないのか
0988NAME IS NULL
2021/08/28(土) 21:16:51.62ID:???設計能力を問う試験 == 「これは第何正規形か？」
0989NAME IS NULL
2021/08/28(土) 21:25:12.13ID:PkRMMA3gデータベーススペシャリストやオラクルマスターの一部はこうなりやすい。
0990NAME IS NULL
2021/08/28(土) 21:41:20.39ID:???相当なルサンチマンがあるようでｗ
0991NAME IS NULL
2021/08/28(土) 22:05:41.57ID:P8TnL8ql0992NAME IS NULL
2021/08/28(土) 22:09:51.55ID:P8TnL8qlDB設計を語るスレ 11
https://mevius.5ch.net/test/read.cgi/db/1630156137/
0993NAME IS NULL
2021/08/28(土) 22:12:15.87ID:P8TnL8ql0994NAME IS NULL
2021/08/28(土) 22:17:42.12ID:PkRMMA3gデータベース板でそう主張するやつがいるんだよ！
0995NAME IS NULL
2021/08/28(土) 22:41:54.46ID:???物理設計はベンダー資格はある程度役に立つ
論理設計は資格試験は全くといっていいほど役に立たない
0996NAME IS NULL
2021/08/29(日) 11:32:43.63ID:ns1fXrgZなるほど。。当方は非エンジニアなんだけども今後、データベース領域の人達と交じるにあたり、データベーススペシャリスト受けようと思ってるのよね。上で誰かも言っていたし、他の多くの試験と同様、最低限の共通言語を持っていると捉えてくれるだろうと期待して。
0997NAME IS NULL
2021/08/29(日) 11:34:54.60ID:ns1fXrgZ0998NAME IS NULL
2021/08/29(日) 11:35:16.40ID:ns1fXrgZ0999NAME IS NULL
2021/08/29(日) 11:36:05.25ID:ns1fXrgZ1000NAME IS NULL
2021/08/29(日) 11:36:36.96ID:ns1fXrgZ10011001
Over 1000Thread新しいスレッドを立ててください。
life time: 1559日 18時間 58分 6秒
10021002
Over 1000Thread運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 2040年「日本は新興国並み」経産省見通し、失われた30年続けば ★2 [少考さん★]
- 【サッカー】U23日本代表 松木玖生、藤田譲瑠チマら、準々決勝カタール戦のスタメン発表 [久太郎★]
- たぬかな、スポンサー契約解除に 弱者男性を「ガス室に入れて一気に命奪った方が世の中のため」「アウシュビッツ！ 」等と発言 [Anonymous★]
- 無印「インフラゼロハウス」に行ってきた 上下水道・電気がなくても暮らせる… [少考さん★]
- 【日本社会】未婚中高年男性の死亡率は、既婚男性の2.8倍も高い [ぐれ★]
- 【作家】北原みのり「頂き女子りりちゃんの懲役９年は重すぎる！」 [シャチ★]
- AFC U23アジアカップ カタール2024★19
- AFC U23アジアカップ カタール2024★18
- AFC U23アジアカップ カタール2024★20
- AFC U23アジアカップ カタール2024★17
- AFC U23アジアカップ カタール2024★21
- こいせん 全レス転載禁止
- 【悲報】ヴィーガンは色んな奴が居る方が倫理の議論は、彼らは論じるのだから
- 【パリ五輪出場を懸けた】カタール vs 日本U23【最後の戦い】 [234233522]
- 鳴き声スレ
- 鳴き声スレ
- たぬかな「弱者男性はガス室に入れて殺せ！ひとまとめにして焼いてしまえ！アウシュビッツ！ 収容所！」→スポンサー契約解除 [302983237]
- 襟粘ぬわ粘職人さんのお🏡