DB設計を語るスレ 10 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
さすがにSAMとISAMでは違うだろ
(M)ISAMでちゃんと設計できるならそのままRDBに持っていける気はするけど 順次SAMは総なめしたり
Trに振りまら混ぜたりたいへんだから違うのはわかりますが
相当まーじとか冗談言っていた時代が懐かしいw 経理システムは一つの仕分けテーブルに借方も貸方も詰め込んでフラグで分別してると思うけど
これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか?
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。 >>249
インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ 振替伝票1枚ごとに伝票番号振るとすると、
貸方か借方で違うテーブルに入るのはどうなのかな マスタデータをJavaServletのアプリケーションスコープ変数に格納して
そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな? >>252
コンピュータの仕組みを勉強してください。 >>253
未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね え、逆にIT業界で省略しないとかあるの?
問題起きたことないんか? >>255
おじいちゃんなの?
そもそも問題ってなに? >マスターデーターをJavaServletのアプリケーションースコープー変数に格納して
こう? わざわざ慣用に逆らう必要性説明できる?
もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな >>263
関係ないと思う
って言うような取引先なんて余計に不安になるだろ 最近思うんだけどみんな無知な奴を相手にし過ぎ。
みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。
常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。 無知には教えたくない()教えたがりのジレンマwいじらしいのおwww >>266
常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ 論理削除否定派のヤツが設計したシステム
取引先からの依頼データなど大事なデータ平気でdeleteしてるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。 だけどその議論はいつも、ユーザーデータはみんなで使ってる共有資産であるという重要な視点が抜けてる。 >>273
必要ないからdeleteしてるんでしょ? つまり必要なデータを削除してしまったマヌケを論理削除の問題だと勘違いしてしまったもっとマヌケな>>273
というおはなしやな
少々笑えた postgresで一切vacuumしないで運用したらいいんじゃね。time machineで任意の時点に戻れるぞ。 >>281
実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。 具体例で考えた方が良いと思う
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している >>284
言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。
単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。 >>280
制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・ >>286
いやそれ削除フラグ云々以前のレベルやろ... >>287
削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる 考慮漏れで問題を起こす可能性を考えたらなんでもありだろう。
削除フラグを見落として処理するコードが混入していて大混乱、とかね。 >>291
それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。 レコードの削除をしても他のテーブルで保管するのが普通。
同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。 削除して良い要件と、削除方法は別の話なんだが
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話
これが理解できない奴が削除フラグの話をかきまわしてるだけ 継続して議論したいなら、コテハン付けるなりトリップ表示させなよ 削除フラグの話題にすらついてこれない人がどうしてこのスレにいるの? ちゃんと削除フラグの話題で進めばいいけど>>286とか>>294みたいに頓珍漢なこと持ち出してグダグダになった過去が何回もあるからなぁ w >>298
ステータスならフラグという持ち方は変。 ひとつのレコードにたくさんフラグ項目を持っていて、それを複雑な条件で判断するようなやつは死ねよ! >>304
状態がオン/オフしかないようなものならフラグでおかしくない
>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑 >>306
>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。 >>306
おまえ、ジジイだろ?
そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。 削除フラグの泥沼スレという名前のスレを建ててそこでやれよ。 だいたい削除フラグなんていらないしな。
とにかく汎用機ジジイがリレーショナルデータベースを使うとこうなる。
またはExcelシートだと思っている素人が考えるとこうなる。 >>311
リレーショナルデータベースをExcelと同じようなものと考えている人は多いぞ。 >>305
一つの項目がステータスを表し、0〜9の値を持ち、2と7が削除扱いという設計を見たことがある。
2が取引先からのキャンセル、7がこちら都合のキャンセル。
嫌になった。 毎日の果物の価格を記録するデータベースを作りたいんですがどういうテーブルをつくったらいいですか?とりあえずitemsテーブルに果物の種類とidのカラムを作ります。
毎日の価格はどういうテーブルにしたらいいですか? >>314
itemテーブルはそんなものだろうと思う。
毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う >>315
価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。 その高値と安値の取得は、システム側でリアルタイムに行うのか、
それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね では、難しく考える必要はない
記録したい項目をテーブルに用意して終わりでしょう 例えばこんな感じかな
item_id
high_price
low_price
date
他に必要な項目があれば追加 >>320
プライマリキーは要らないんですか?
あとテーブル名ってどんな感じに付けますか? 必要かどうか分からないが、
どうしてもキーを付けるなら、
一意になりそうな日付かな?
テーブル名はお好きにどうぞ 果物取引実績(果物取引実績ID PK, 果物ID NN, 取引年月日 NN, 取引価格 NN)
チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)
select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日 >>323
そうだね、一意にするためには日付だけではなく
itemIDとセットにしないといけなかった しかし>>323はindex付けただけでuniqueにはしていないという 販売実績だからユニークにしなくていい
同じ果物が何度も売れてもいい 客は要件わかってないからな
要件そのまま聞くとまあ後でおかしくなるよ
この場合だと、その日の最後に入力するので取引実績をメモしておかないといけないんだけどめんどくさい、だとか
最大最小を計算するのめんどくさいからどうにかして、といった具合 入手できるデータが取引単位なのか日単位なのかなんて開発者が勝手に決められるわけないわな。 どうしても日単位の最大最小でしかデータを入れられないなら
insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる >>332
それだと、レコード一つだけ見たときにそrが最高値か最安値か分からないだろう こういう、なにがキーかわからないテーブルを設計してしまうID厨 >>332
どうやったらこんなアホな発想に至るんだろう... >>334
どう見てもidがキーとわかる
果物idと日付をキーにする派閥もあるが
後で見た人は同じ日に同じものが売れたらどうなるんだ?と疑問を感じざるをえない >>335
せめて反論の形にしないと敗北宣言と同じだよ? データベースは1行に1つの事実を保存する
基本中の基本
最大値や最小値を1行に保存するということはこれに反する
統計値とは複数の事実から導き出されるものだからだ >>338
え゛っ、マジで言ってるの?
値を参照するだけで>>323相当のSQL要るし、既に>>320みたいなまっとうな例もでてるのに w >>340
統計値を参照するのに集計クエリが要るのは正常
>>320はまっとうじゃないよ
手作業で出した集計値を保存するという暗黙の手続きの上にかろうじて成立しているだけ
それと試しにこのテーブルにまっとうな名前をつけてみなさい 形式だけ正規化して満足してしまう人が多すぎる
彼らは形式しかみないから>>320のような歪なテーブルを受け入れてしまうがそれはダメだ
意味的にも正しく正規化すべきだ そろそろ最初の質問者である>>314が出てきて要件について後出しでも何でも良いから(というか思ってることでもいいから)
はっきりさせるべきだな。 >>344
「正規化」って用語を「正しいテーブル設計」の代名詞みたいに使う人は相変わらずいるねぇ。
意味的に正しい正規化ってなんだろう。 >>342
要件を間違えてる
「高値/安値を求める」のではなく「求められた高値/安値を記録」するってこと ⇒ >>316
統計関係ない
テーブル名?
果物取引実績 とかでいいだろ w >>346
第一正規化とか でググれ
1つの列に>>332みたいに違う意味の情報を入れるのは最悪の設計であることがわかると思う >>346
例えばhoge(id, foo_1, foo_2, foo_3)のようなテーブルは形式的には正規形だが意味的にはおかしなことだ
古いエンジニアは平気でこういうテーブルを書いてしまう
集計値を格納するのも同様に形式しか見ずに設計した酷いテーブル構造だ >>344が言っているのは>>320のことだが。
>>332は属性の意味が定まらんという、正規化以前の問題。 >>350
だから、形式的に正規形だったら正規形なんだよ。意味的におかしいというのは別の話。
それを「正しい正規形じゃない」と言うのが変なだけ。 >>347
記録するという行為の本質を見誤ってるな
Aという事実から直ちにBという事実が導き出される場合に
Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
Aを記録したからといってBを記録していないということにはならない
例えば歩く速度と歩いた時間を記録すれば歩いた距離も記録したも同然だな
それと同じでここの取引価格を記録するということは同時に最安値・最高値を記録することでもある
要件には全く反していないということだな
それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
まっとうなテーブルじゃないからまっとうな名前をつけられない >>349
あくまで苦肉の策だということ
手作業で集計値を出すまでに個々のデータは必ずあるのだから、その個々のデータを入れるのが正しいあり方だ
しかし、どうしても最安値・最高値だけ保存してそれ以外は手作業で計算したいという奇特なユーザーのためにこういう手もないことはないと提示しただけ
ちなみにこの最高値・最安値のレコードだけを登録する回避策は厳密には間違いではない
なぜなら最安値の取引実績も最高値の取引実績も実際に存在する事実だからだ
間違いがあるとすれば他にも存在したはずの事実の記録を怠った運用の仕方にある >>351
完璧に定まってる
いつ、何が、幾らで取引された、という事実を単純明快に表している
そして、それぞれの事実を識別するための最もシンプルな手段であるidを導入した
時刻はアイデンティティを示すキーの一部にはならない 速度計を持っているかどうかもわからんのに速度を入力しろとか。 >>352
それは派閥による
セルコは意味的な部分にも踏み込んで正規化としているね >>356
くだらないレスはやめよう
歩いた距離と時間を記録すれば速度を記録したようなものだ
これで速度計は不要になったね
次はなんだ?時計がないってか?
付き合いきれん >>353
> Bを記録する方法はBを直接的に記録するのとAを記録する方法がありうる
だから中途半端な>>332はバカだって言う話な
> それと果物取引実績という名前から最高値・最安値を直接的に記録するテーブルだと解釈するのは無理がある
> まっとうなテーブルじゃないからまっとうな名前をつけられない
>>332に言ってやれよ w >>357
そう?
少なくとも「プログラマのためのSQL」じゃ形式的な正規形についてしか説明していないようだけど。
曰く
「正規形は、データベースで真のデータを破壊したり、偽のデータを作成したりすることがないように
しようというのが目的です。」 >>361
> 言い返せなくなると罵倒する
> ここらで決着かな
ひょっとして「必要もないのに」って言われてる意味がわかってないとか?
てか既に決着してるだろ w 回答ありがとうございました
>>345
>>320さんを参考に
テーブル作ってみたんですが
https://ideone.com/y6urpx
itemテーブルに同じ名前で重複してかきこまれてしまいます。 >>366
取引した日付と商品IDで重複しなくなるから、
その二つを使ってPrimary Keyを指定する。
PRIMARY KEY(`transaction_date`,`items_id`),
#varcharって書くと、サイズ1になるんだっけ? >>367
primary key にすれば自動的にunique制約されるんですね そういうことになるね
それをキーにして何通りも取得できたら
おかしいことになるだろうし 皆さんがアンケートの答えを格納するテーブルを作るとしたら
未回答は、nullを想定しますか?0を想定しますか?
理由も教えてください! It depends on the situation. 任意項目への未回答は空文字か、回答無し値(事前に決めた値)にする 要件次第だな
事前に決めた値で問題ないならそうするかもしれんが
まあnullだな >>370 は未回答という状態が存在しているとしているのなら、未回答という状態のレコードが存在しないとおかしい。 説明不足でした
Q1 性別 1.男 2.女
Q2 参加して 1.よかった 2.どちらとも 3.悪かった
Q3 よかったもの(複数回答可) 1.下着 2.靴 3.帽子
こんなアンケートの結果を
man int, ans1 int, ans2 int, ans3_1 bool, ans3_2 bool, ans3_3 bool
のカラムを持つテーブルに記録しようと思っています
manは1番から自動で割り振りのpkです
ans3_?はTRUE,FALSEで判断して未回答はFALSEと同義になります
問題はans1, ans2の未回答に0かnullのどちらを使うかです アンケートで、「答えたくない」って選択を用意しているときがあるな
未回答を避け、こういう選択肢を用意すると言うのも方法だと思う 適当に安価なオブジェクトストアを建ててそのまま保存かな
どうせしばらく経ったら丸ごと捨てるんだろ? >>332
カラムを_id, fruit_name, date, priceにして、すべての取引を記録すればいいじゃん
最高値と最安値はその都度、SQL文書いて取り出せばよくない?
MaxとMinをいちいち記録する必要ある?
複雑化するだけじゃん。 >>332
最大、最小しかデータ入れられないのか
糞レスしてごめん >>380
ものによってはレコード数が多すぎて毎回、最少値、最大値を求めるのはおかしい設計になることもある。
最少値、最大値を別のテーブルで管理していても要件次第ではこちらの方が正しい。 一日毎のレコードで最大最小が確定するんだったら
日替わりのタイミングで取得して別テーブルに登録したいね >>386
実際は、運用や移行無視の機能要件しか満たさないような設計も多い。
テスト工程の終盤で気付いて火を噴く DB設計に限れば運用ってバックアップ/リストアぐらいしかないんじゃね
統計情報更新とかフラグメント対策とかの運用をちゃんと設計段階で織り込んでる? >>388
データ容量が見積もりと、過去データ削除方式の設計など考慮すべきは山ほどある。 DBAがいないと漏れがちなこと、ってのが趣旨なんでは
データ容量や保持期間の設計は費用に直結することだからやらないなんてあり得なくて、ちょっと違うと思う 既存のテーブルに後から10カラムほど追加するというのはありなのでしょうか?
最初は別のテーブルにしようと思ったのですが、
1対1の関係であるため、ひとつにまとめた方が良いのではないか?と悩んでいます。 >>392
改修コスト見合いだが
将来にわたり1:1ならいいんじゃね >>393-394
ありがとうございます。分ける方法もよくあるんですね >>395
どちらかというと分けた方がいい。
あとから追加するものはそのカラムのまとまりに意味があるはずで、別エンティティにすべき。
カラムの追加をし始めるとどんどん追加されて、テーブルがただの入れ物になる。
コボラーさんや頭が古いひとはカラムを追加したがる。 >>396
まとまりに意味があるからテーブル分けろ?
他に理由ないならバカとしか思えない ただスキルがないだけなのにバカ呼ばわりは少しかわいそうw それぞれが巨象の一部にふれて、
象とはこういうものだと言い合っている絵を
思い浮かべる議論だな >>396
コボラーさんはカラムを後から追加はしません。
基本的に予備領域を割り当てます。
コボラーさんがRDBで設計すると、予備1〜予備10みたいな項目が全てのテーブルに初期装備されます。 >>401
つまらん。コボラーが項目が追加できると知るとどんどん追加する。そしてテーブルの結合を嫌がる。 >>401
JCLでレコード長の数字を弄らんといかんようになるからな w それ以前にテープに格納されてるマスタのレコード長とか変えれんから 小学生相手に威張る中学生、みたいな。叩ける相手がコボラーくらいしかいないんだろう。 列追加は構わんけど処理速度への影響も含めて検討してほしい >>410
レコード長が倍違うテーブルのデータをupdateしたら、updateにかかる時間が倍になるって話
例えば主キー指定のupdate文で1項目だけ値を変更するとして、1件あたりはミリ秒以下でも何百万〜何千万件と積み上げたら明確に差が出る
DBMSによって違いはあるだろうけどね まさかレコード単位でIOかましてるとでも思ってるのか >>411
それは追加したカラムのデータを別の物理ファイルや領域に格納するRDBMS製品の話ではないのか? カラムを追加したら、明らかに処理が遅くなるのなら、同じレコードであってもカラムを飛び飛びで持っている証拠になる。
レコードのデータを連続データとして格納していないRDBMSは、SELECTもINSERTもUPDATEも当然、遅くなる。 分からないんだけど、
連続データなら一挙にできるが
分散していると、一つ一つがバラバラに処理されるってこと? 昔SQL鯖でカラム追加した時に、クラスタインデックスが断片化して酷い目にあったなぁ >>414>>415
SQLServerなんだけどね
カラムを追加したとかではなく元々レコード長が倍違うテーブルで、どっちも主キーはInteger型の一項目だけ、主キー以外のインデックスなんかは削除した状態
この2つのテーブルの一項目だけを更新するのに、これとは別に主キーと更新したい値だけを持つ2カラムのテーブルをカーソルで読み込んで、主キーをwhere条件に1件1件更新する処理を流した結果、時間が倍違った
(個人的な検証なのでカーソル使わずに一括Updateすりゃいいじゃんてのは無しで)
この違いの理由を考えた結果、単純に1ページ辺りのレコード件数が倍違うのが差に出てきたのかなあと思ったわけ
SQLServer特有のことかもだけど、レコード長が大きいテーブルは要注意、ひいてはカラム追加も注意が必要だと自分の中で結論を出した
(もちろん、カラム追加が絶対悪というつもりは毛頭なく、処理次第だと思ってる) 主キーはクラスタ化なのかとか、断片化してないのとか、ページ分割が起こってないのとか
まあ不定要素多すぎて何とも言えんけど
それはそもそもレコード長が違うテーブルの更新時間が違うって話で
カラム追加するかどうかと別な話
ちゃんと比較するなら、カラム追加したときと、別テーブルにカラム持ったばあいの処理で比較しないと >>420
要は最後の1文に書いてくれたことも検討したほうがいいよって言いたかったの
まわりくどくなっちゃってごめん ・ニックネーム
・id・
・パスワード・
・最終ログイン日時
・最後にパスワードを設定した日時
・備考欄
これらのデータを管理する場合どのようなテーブル構成にしたら良いのか本を購入して学びたいのですが
良い本を教えてください。
会員サイト用のデータベースです。 >>422
趣味で作るんならともかく、仕事で作るのにやりがいもへったくれもあるか 私たち日本人の、日本国憲法を改正しましょう。
『憲法改正國民投票法』、でググってみてください。
(へいわ)は、勝ち取るものです。拡散も含め、お願い致します。 イオンみたいな巨大小売で、個人客が買い物した商品なんかのDBってどう管理してるんでしょうか?
主キー 会員ID 購入商品 品数 日付
1 a01 チロルチョコ 10 2018/10/17
2 a01 牛乳 1 2018/10/17
3 a02 牛肉 1 2018/10/17
4 a02 ポカリ 2 2018/10/17
こんな感じでテーブルに購入された商品1つ1つ登録してたら、1日で日本全国で百万レコードとか行っちゃいますよね?
何かいい手があるんでしょうか?毎日テーブルを作ってるのかな? >>428
何の為にDBに登録するのか、その目的次第だと思う
小売店での現金販売だとそこまで細かくデータはとってないだろうし
そこまで細かくデータが取れるとすれば通販でクレジット決済したときくらいか >>428
例示のレコードでレコード長40byteくらいだとする
1日100万でも40Mとかだから現代ではそこまででもない 小売店で取れるデータって、POSレジの範囲だぞ
個人を特定可能なデータはとってない
特定可能なポイントカードを使わせれば良いかもだが
すべての客が使う訳じゃないからな >>428
> 1日で日本全国で百万レコードとか行っちゃいますよね?
今時そこら辺に転がってるPCでもヤ楽々処理できるレベル
1億レコード超えたら本気出す 顧客のだけでなく業者からの仕入データだって膨大になるだろうに毎日テーブル作ってたらどうなるんだよ >>428の例で、毎日テーブルを作るとしてさ、
「今年会員IDa01が購入した商品全部抽出して」って言われたらSQL文てどうやるの?テーブルを365個SQLに書かなきゃダメ? 本だと
購入日、性別、年代、書籍コード(ISBNや雑誌コード)、冊数が
届いてたなあ パーティショニングはしてるかもしれんが、テーブル毎日つくるとかないわ ようつべとか、視聴履歴をめっちゃ昔まで遡れるやん?
数億人が毎日見てるんだぜ?考えるとすごくね?しかも検索結果の抽出も早いしどうなってんだ 厚さ0.1mmの新聞紙でも42回折ったら月まで届く高さになる つまり月まで届くほどデータがあっても
検索にかかる時間は0,1mmのデータのたかだか42倍 0.1mmの42倍て4.2mmじゃね?それで月まで届くの? しかし折り方を指定してないからな
蛇腹だとたしかに月までどころか5mmにもならん よってYouTubeの検索速度を再現する事は不可能である YouTube を実際に使っているユーザーがいないんじゃ? YouTube を仮に使ってるユーザーぐらいいるんじゃね? 特殊な炭素素材で水を水素と酸素に分解 ゼビオHDのグループ企業、クロステクノロジーラボが開発 500項目超とかの巨大テーブルいい加減ヤメてほしい >>452
DBMS何使ったらそうなんの?オラコー? 紙の業務の置き換えで
10明細x50の伝票!あと10年は変更ありません!
とかだとよくやる。官公庁だあとありがち。
正規化するといちいちJOIN書かないといかんし >>452
見たのは確かOracle
項目多過ぎでSQLが実行できない 主キーをサロゲートキー(serial)にするか、複合カラムの組み合わせでUNIQUE制約をつけて主キーっぽく使うかで悩んでいます。
問題なのが、このテーブルはレコードを削除した後、復活(再度、新規登録)させる必要が出てくる可能性があることです。
その場合、復活させた時に番号が変わるserialを主キーにするのは、ありえないですよね? そのDBがserial値の明示的挿入を許して、それが滅多に起きないんならなくはないんじゃね
それ以前におれなら復活必要なら論理削除にしとくが データレコード削除してもサロゲートキーのマスター残しておけば問題ないんでないの。 サロゲートキーのマスターとは?
ここで言ってるserialってのは、システム側で管理して勝手に数値入れてくれるものだと思うが 単なるserial;はふつうサロゲートキーとは言わんだろう。
>>457のように一意性を保証する複合主キーが存在したうえでその代理とするのがサロゲートキー。
んだから元の複合主キーとserialからなるのがマスターだしそれが自動採番されることは矛盾しない。 で、データレコード削除しても残るサロゲートキーのマスターって何?って話だが
自動採番(システム管理)される値をサロゲートキーにするって前提じゃないの? だから複合主キーとサロゲートキーの対応表だよ。そう書いたつもりだったが。
>>457のようにデータ再投入時にサロゲートキーの値が変わるのを防ぎたいなら
そういうマスターを残しておけばいいという話。
採番が自動か手動かはこの際関係ない。 >>463
そういうマスターを残すには手動でそういうマスターを作らないとダメなわけで
前提を合わす気がないならちゃんとそういっとかないと議論にならん serialを変えたくないってことは、
その様な使い方を別なところでしているんじゃないかな
ログとか履歴とか >>464
既に何度も書いているが、そのマスターのサロゲートキーはserialで自動採番して全然問題ないんだが?
あるいは、もともとデータテーブルが1テーブルだったものをマスターテーブルと分離したことを言っているなら
そりゃ当たり前だ。そう提案したんだからな。 大阪市は2019年6月24日、6月7日から翌8日にかけて発生した基幹系システムの障害に
ついて、原因を特定したと明らかにした。米オラクル(Oracle)のデータベース(DB)ソフト
「Oracle Database」のバグが原因だった。
https://egg.5ch.net/test/read.cgi/bizplus/1561468154/ やっぱ脱Oracleだな
ろくに保守サポートされないんだから有料契約の意味がない でも金で解決してくれるサポートがなけりゃ、問題がDBMS側にあることを
突き止めることすら自前でやらなきゃならんのだぜ。 突き止めることに意味がないからな
責任転嫁のための作業であって
復旧にはどのみち問い合わせじゃ間に合わん 原因がわからなきゃ対策のとりようもないだろう。
「たまたまエラーになったけど原因がわからないからまた起きたらゴメンね。」で済むような仕事ならいいが。 オラクルは、問題がDBMSにあることをつきとめるんじゃなくて、その問題をまず認めてもらうのにサポート窓口が必要なんだよ
あとは直ればラッキーぐらい > 大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、
> 8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜む
> バグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。
> 米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。
https://tech.nikkeibp.co.jp/atcl/nxt/mag/nc/18/020600011/070200035/ それゆえMySQLとかPostgreSQL移行が進んでる デシジョンテーブルのつくりかたがわからん
値の組み合わせ全部入れるもんなの?
null値はすべての検索値にマッチとかルール決めて行数減らしたけど
わけわかめになった 売上を管理するテーブルを設計したいんですが、
後になって、同じ商品コードに別の商品が割り当てられる事も想定して設計する場合、
売上テーブルには、商品コードと商品名と価格すべてを登録するのが普通でしょうか?
※売り上げに登録する商品は、商品コードと商品名と価格だけで管理すると仮定します。 >>478
その意味のない商品コードとやらで何をしたいんだ?
商品名と価格だけでいいだろ >>478
商品マスタに有効期間を作るのが定石かなあ
ついでに言うと当時の単価もマスタ側で
売り上げは数量かなあ
(集計用に金額持たせることはある)
あと消費税の扱いをどうするかとか考えておいたほうがいい >>478
自分ならというか自分が作ったシステムの売上データは個数、単価、価格などを保持してる
マスタから参照するのはコードと商品名ぐらい
マスタのコードは別の商品に変わる可能性があるなら売上データと商品マスタを結合するキーは
商品コードでなく商品マスタのサロゲートキー >同じ商品コードに別の商品が割り当てられる事も想定して
これがどういう状況を表しているのかはっきりさせないと設計も決められないだろ。
少なくとも「商品コード」で「商品」を特定できないことは読み取れるが、じゃあ
「商品コード」と「商品名」であれば特定できるのかそれともそうじゃないのか。
できるなら>>478のままでいいが、できないならばそれを特定できる情報を
追加しなければならない。 同じ商品コードを別の商品に割り当てるって言うんだから、ある商品の商品名を
変更するって話とは全然違うわな。 商品コードが一意にならないって理解しにくいんだが
商品コードを仕入れ先の企業が決めてくるって事? おそらく現実の問題ではなくて、>>478が深く考えないで書いた脳内想定だと思う。 現実的に、商品コードが一意にならないような要求をする客はいるぞ
もし本当に
>売り上げに登録する商品は、商品コードと商品名と価格だけで管理する
のならば、全情報コピーでいいだろ
現実的にはそんな単純な管理条件にはならんけどな >>487
> 現実的に、商品コードが一意にならないような要求をする客はいるぞ
そりゃいるだろうよ
だから外部とやり取りするためのコードと内部で処理するためのコードは別に持ったりする 横着して客が提示した項目だけでまかなおうとするからコケル >>467
ラックに限らずクラスタリングってもしもの時のバックアップとしては全く信用できない。
基本的に運が良ければダウン時間が短く済むかも程度で考えて、データのみ同期させる予備機もっとかないと。 カラムに日本語使わないほうがいい
でもPHPでカラムを見ながら弄りたい
PHPやらhtmlでいちいち書くのは面倒くさい
ってんで、カラムの名前の日本語対応データだけもったtable作る
ってのは変ですか? 日本語っていうか、論理名を物理名とは別に持って管理するのは珍しくない >>492
ありがとうございます
論理名 物理名というのですね
参考になる文献が結構出てきて助かりました 多少長くなっても意味の通じるカラム名で管理した方が楽かな >>493
項目名が頻繁に変わるという仕様が本当に必要なのか考えた方がいい。 どこから項目名が頻繁に変わるという仕様を導き出したんだ まあ強いて言えばわざわざ
> カラムの名前の日本語対応データだけもったtable作る
ってところじゃね? お腹がすいていませんか?
ウーバーイーツの利用者が初めての方は eats-5kqyfp のプロモーションコードを使うと、#Uber Eats の初回注文が ¥1,000 割引になります。https://t.co/Wxur8AeoEf 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01) PHPからデータを入力することを考えているのですが、初心者ゆえ取っ掛かりがわからなくて途方にくれています
例えば、
歴史的建造物のテーブルと
国のテーブルが有るとします
建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい
という場合、オートコンプリート用国候補のデータを"国"テーブルから取得して提示
という流れでいいのでしょうか?
この入力段階では建造物テーブルにリレーション?や結合といった処理で"国"の関連付け考えなくてもいいという感じでしょうか? >>499
建造物情報と国情報が紐付いてないのに、なぜ「オートコンプリート」という言葉が出てくるのか? つか、建物入力して、国を絞るのか?
法隆寺は日本にしかないだろうに
国を入力したら、建物のリストを候補にだすってんなら、国と建物の紐づけが必要 法隆寺のデータをこれから入力しようって時に紐付けデータが先に存在しているわけなかろう。 オートコンプリート用国候補のデータを"国"テーブルから取得して すでに歴史的建造物のテーブル(にレコード)があるって前提ではないのか >オートコンプリートとは、ユーザーによるキーボード入力履歴を活用して、
>入力操作の軽減を図る機能の一つである。
>オートコンプリートに対応したソフトでは、ユーザーが入力したい言葉の
>冒頭の文字を入れると、入力履歴の中から冒頭の文字が一致するものを
>候補として一覧で表示する。候補は、文字を入力していくごとに絞り込まれ、
>その一覧の中に入力したい言葉があれば、ユーザーは残りの文字を入力
>することなく、一覧から選ぶだけで入力が完了する。
こういうことなんじゃ? >>501
>>503
>>506
>建造物のデータを入力する時に建造物の国カラムに、国のテーブルからオートコンプリートで入力したい >>508
だからどうしてそんな変なことを言っているのか? 変なことっていうのは違うな
誰でも考えつくことだし >>499
・国名入力欄
・建造物名入力欄
があって、「国名入力欄に入力する際に国名をオートコンプリートしたい
(“に”って入力したら“日本”が候補にでてくる)」って認識でOk?
それとも「国名を入力したら建造物名入力欄の候補が絞り込まれる」ようにしたいってことを言ってる? >国のテーブルからオートコンプリート
>オートコンプリート用国候補のデータ
こう書いてあるんだから普通わかるだろ。 年取ると、書いてないことを読んだり、
書いてあることを読めなかったりします
私もそうだから、よく分かります 「利用回数が制限されているユーザーとされていないユーザーがいる」
という条件だとします。
このとき、finiteカラム(int)が99であれば、99回利用できるとします。
利用するごとに1ずつ減っていくイメージです。
では、「無制限に利用できる」を表現したい場合、finiteカラムでできるのでしょうか?
それとも、infiniteカラムなどを追加し、そこが1(有効)のユーザーは
無制限に利用できるというような、フラグ的な使い方をすればいいのでしょうか?
どう設計するのがベストプラクティスかわかりません。教えて下さい。 制限ユーザーかどうかを識別するカラムを追加か、
finiteが -1 なら無制限ユーザーとする、とか ベストプラクティスなんて、アプリの設計方法次第で変わるわ
とりあえずfiniteにNULLでいいだろ
NULLから1引いてもNULLだからな >>518
なるほど。-1って考えはありませんでした。
聞いたことありませんが良さそうですね。
>>519
int型のカラムにNULL入れちゃうのは抵抗があります・・・ 個人的には、利用上限と利用回数で項目分けたい
あとで利用回数調べたりしがちだから
基本、利用上限>利用回数で判定して
運用上、アホみたいに利用されないなら
利用上限をintのMAX_VAlUEとかにしとけば
実質無制限になるし、同じ判定で済む >>522
なるほど。その方が汎用性がありますね。
利用上限も制限がある場合は1〜99まで
無制限なら999とかにしておけばわかりやすいです。
-1だとorderの並び替えも難しいですが、999ならできますし DB設計をどうするかと、データ取得はどういう順にしたいかは別の問題 モンスターマップのhtmlのデータをDB化しようとすると,
どんなスキーマにしておくと後々使えるでしょうかね. Create Table MonsterMap (
HTML varchar(max);
); >>528 中身をDB化したい場合.
ttps://monstermap.org/data/20191129.html
みたいなURLじゃなくて,その中身です.
名前,グーグルマップへのURL,住所 のフィクションデータが入っていて
ファイル名が日付で,中身には日本語の日付もある状態.
. >>33
自分が関わったシステムではただの連番をPKにした
画面の方は検索機能で対応 >>499
PHPから、と言うより、WEBの入力画面で登録という解釈で良いのかな
国カラムって言い方が違和感あるけど、国項目だよね
保存ボタン押した時に国項目に入力した内容を建造物テーブルの国カラムに設定してINSERT、もしくはUPDATEするみたいな
関係云々はこの画面が建造物と国を関連を登録する機能じゃないのかな >>532
国項目って言い方が違和感あるけど、国カラムだよね 運用中の既存のテーブルにカラムを一つ追加したい場合、どうするのがベストでしょうか?
普通に
ALTER TABLE `テーブル名` ADD `カラム名` TEXT NOT NULL AFTER `カラム名`
みたいなSQLを実行するだけでいいのでしょうか?
それともこれを実行するとなにか問題が起きる可能性はあるでしょうか?
運用想定までできてないので、トラブルが起きる可能性があれば教えて下さい >>536
ありがとうございます。MySQLを使っています。
運用中のデータ(つまり、読み書きが行われている)ものに対して
テーブルの追加変更ってまずいと思ったのですが、そうでもないみたいですね >>537
もしバージョン5.x使ってるならそれなりにインパクトあるから
使ってるバージョンのマニュアル見てね ロックなしでスキーマ変更するのが安全だと?
可能なら本番稼働中のDBでやるような処理じゃないぞ すみません
SQL質疑応答19のスレ222でも質問した者なんですが
ブライマリキーって迷ったら全てのカラムに指定してもいいですか? それはアドバイスしても理解できるかどうか疑うレベル >>544
いいんじゃね?
お前さん以外は誰も困らんし こういうなりすます奴が出てくるので
質問者はageでやるかトリップ付けた方が良いです 238 NAME IS NULL sage 2020/02/09(日) 18:00:13.65 ID:???
どうしてもkey を変えたくないなら元情報用カラムをついかして元情報をそこに残すしかし複数の変更履歴残したいならば、変更用トランザクションデータを残して置けば変更履歴は追える
トランザクションデータというのはsqliteでも使えるのでしょうか?
別のテーブルを作って 変更のlogを保存するという方法はどうでしょうかね ここでいうトランザクションデータというのは、個別の取引レコードの事だと思う
登録するデータの内容とそれが追加か更新か(必要なら削除も)の処理内容を追記するテーブルを用意する
おそらくあなたの考えているLogと同じ事ではないかと思う。もちろんsqliteでも使える いまどきマスターとかトランザクションとか言っとるジジイは放置でええねん DB設計の経験が浅いプログラマーは
マスターとトランザクションデータの区別がまともにできないから気をつけろ
30オーバーのやつも含めてチーム全員が
マスターのことをトランザクションと呼んでて震撼したことがある >>552
なるほどマスタとトランザクションという概念があるんですか、ためになるな
最新のデータはマスターに記録して変更履歴をトランザクションとして記録すればいいんすね いや、そういうことじゃなくて
もっと基本的な所から勉強した方が良い
話を聞いている限り、テーブル設計がちゃんとできていない マスターの履歴とマスターにに対する変更イベントを記録(トランザクション)は微妙に違う >>558
テーブル設計でいい本とかサイトありますか?
今、達人に学ぶDB設計指南って本読んでるんですけどフワッとしてるっていうかもっとテーブル設計の実例が見たい >>557
コボラーのおじいちゃんの概念なw騙されんなw現代においてはなんも意味ないでw >>560
「業務別データベース設計のためのデータモデリング入門」渡辺幸三 >>563
ありがとうございます
レビュー見ると難しそうだけど読んでみます 分からない事があれば、ここで聞くといいよ
賑わいはないけど真面目にレスが返る板だから >>565
おまえが気持ち悪い事ゆうから誰も居らんくなったやないか 連番管理する必要がある場合、以下のどちらのほうほうがよいでしょうか?
https://ideone.com/oOlh4z
中間にINSERTされる場合があります。
SELECTする時は漏れなく連番の先頭から最後まで一括で取得することになります。 前後の関係を知りたいのが主なら1だけど、汎用的には2 >>568
件数や更新頻度、データの使われ方による
一括SELECT時のパフォーマンスが重要なら連番順のインデックスを作れるようにする
例えば有理数で管理して1/5, 2/5, 3/5と並んでるところに
データを挿入したければ3/10, 5/10
それで2/10, 3/10, 4/10, 5/10, 6/10の並びになる
他には101000, 102000, 103000のような飛び番で管理して
番号が埋まってきたら番号を振り直す方法もある
挿入時のパフォーマンスが重要なら書いてるようなLinked List的な方法で良いと思う
previousを知る必要がなければ2の方法で十分だがrootが一発でわかるデータは必要 INSERTする頻度がそれほどでないなら
順番を決められるような非整数の項目用意して
通常は整数値を入れておき、
挿入時に前後の項目の中間値を入れるなんてどうかな >SELECTする時は漏れなく連番の先頭から最後まで一括で取得
取得する順番はどうでもいいのか? どう考えても2だろ1とかいみふ
>>570
振り直しとかw >>572
再帰クエリを使う前提やろ
>>573
>振り直しとかw
RDBのページ分割と同じだぞ 用途によるわな。
二項関係を全部保持する設計だと参照は爆速。 >>568
入れ子集合
閉包テーブル
なんて方法もあります >>573
振り直しは実は結構現実的なソリューション
>>574
まあ、再帰前提になるわな
再帰クエリってパフォーマンスどうなんだ
あと再帰のネスト深さとかけっこう制限あったような フラグ系のカラム名付け質問
例えば商品マスタ(ID,JANコード、名称、・・・)があって
こいつらにセール対象、まとめ買い対象、みたいなフラグカラム追加したいときってどういうカラム名がいいんでしょ?
セール対象テーブル追加してそっちみろは無しでお願いします
is_Bargain、is_MatomeGay(英語わからんので適当)とかにする? まとめゲイw
命名規約次第だけど個人的にはon_saleやfor_bulkみたいな名前をつける
is/has縛りなら商品に対応する単語をくっつけたほうがいいかも
セール対象商品 => is_bargain_item
まとめ買い対象商品 => is_matomegai_item
item.is_bargainだと英語的には超微妙
item.is_for_bargainならわりと自然だけどis_for_bargainというカラム名は微妙
item.is_bargain_itemも冗長だけど冠詞がないだけでまあ自然でis_for_bargainに比べるとカラム名としてはマシ ただ現実問題としてis_bargainみたいなboolフラグで管理可能なの?
アフィサイトみたいに表示管理だけでいいなら
それでも問題ないかもしれないけど、実際にキャンペーンやる会社なら
どの期間、どのキャンペーンの対象で、どういう適用条件かみたいなのが最低限必要だからboolじゃ破綻しそう ありがとうございます
そうなんですよね。英語的にはマシかもだけどカラム名として何だか微妙になるんですよね
現状はフラグ1、フラグ2、..みたいな暗黒状態かつ命名規約何それなので、それよりはマシなのですが
実際は簡単なフラグ管理だけで良いので、バーゲン期間とかは考慮しなくて大丈夫です
良かろうと思って一般的なサンプルでっち上げると余計な検討点が出てきてダメですね
私の悩みを10年前に通過している列海王的な方がいたら、引き続きナイスな命名案をよろしくお願いします github検索してみたが
on_saleやis_on_saleで命名してるのはそこそこ見つかる >>583
遅くなりました。ありがとうございます
githubも見てみます
こういう時ネイティブ並の語彙力がほしくなる どうせそれを見るのも日本人だろ
ネイティブが違和感を感じるかどうかより、日本人が納得するかどうかだと思うぞ
DBMSにもよるだろうが、日本語環境以外での動作を考えないなら日本語カラム名でもいいと思う 以前はfoo_flag, bar_flagみたいな命名はダサいから可能な限り避けようとしてたが
最近は一貫性が取れてるならis_fooやis_barよりもベターなケースが多いと思うようになってきた
組織の英語力やDBリテラシー次第 うちのアカンDB
boo(0,1)とるカラムがxx_kbn
int(0~9)とるカラムがxx_flag
せめて逆じゃね? 普通はデータベースって蓄積するもので、
普通は削除フラグにとどめて、よほどのことがないとdeleteするようなことってないと思いますが、
deleteしまくることによって何か問題が起きたりするのでしょうか?
あと消したあとも、ゴミ箱にいれたHDDの中身みたいに実は復旧可能だったりしますか?
問い合わせのログみたいなのを一定期間後に完全削除するのを考えてます。 >>589
削除するかどうかは要件次第
不要になったら一旦アーカイブに移動させて
その後、事前に決めた一定期間を過ぎたらメディアにバックアップとって削除する
メディアも事前に決めたメディア用の一定期間を過ぎたら廃棄する
そういうデータライフサイクルを要件定義時に決めて運用にのせるのが普通
復元できるかどうかはバックアップやトランザクションログの残し方による 同じ設計で別の用途に使用したいテーブルがある場合、テーブル名をどうしていますか?
例えばブログの場合、
article → 記事テーブル
category → カテゴリーテーブル
article_cateogry →記事のカテゴリーテーブル
と設計することがあると思います。
ここに「特集」という別のコンテンツを追加したい場合、
special → 特集テーブル
special_category → 特集カテゴリーテーブル
special_special__cateogry →特集の特集カテゴリーテーブル
とするのは変です。
記事と特集はテーブル設計が異なるので、同じテーブルでまとめられません。
しかし、「カテゴリー」テーブルの設計は同じです。同名でも意味は通じます。
categoryではなく、type(種類)とかclass(クラス)とか別名にして対応するのでしょうか? >>591
「特集」は特集記事であって記事の特化したものではないの?
ある一つのカテゴリーを選択した場合に
それに合致する記事も特集も拾いたいケースがあるなら
カテゴリーテーブルは一つにしたほうがよくて
特集テーブルも記事テーブルと1 ― 0..1 の関係で作るか
特集テーブルと記事テーブルを汎化したテーブルを検討する >>592
「特集」という例がわかりづらいなら、掲示板(bbs)でもいいです。
掲示板でも「カテゴリー」って分類は必要ですよね?
でも、記事のカテゴリーと掲示板のカテゴリーは内容そのものが違います。
たとえカラムが同じであっても、用途が異なるテーブルを共有し使うのはよくありません。
だからcategoryではない別名が必要なのですが、その命名が難しいという相談です。 この程度のことを聞ける人が会社にいないんだろうかw 記事カテゴリーと掲示板カテゴリーでなんの不都合がある? >>594
この程度のことがググっても見つからないんです。
>>595
日本語だとそれでOKなのですが、>>591の命名に合わせるとおかしいと思う次第です。
そもそもですが、最初は単純に「category」というテーブル名にしてて、
あとから別の用途のカテゴリーがでてくる事ってありませんか?
最初から記事カテゴリーを作る想定をしていないと思うんです。
規模を拡張する時に命名が被る、だから困るってそんなおかしい悩みですかね・・・ 命名がうまくいかないケースの7~8割は
モデリングがうまくできてないケース 悩みは理解できるがmany-to-manyで管理が必要なカテゴリーテーブルが
1つのスキーマに複数必要になるケースってそうそうないよね >>591
そもそも special_category という名称が意味不明 >>598
確かにただアプリとしてブログとか掲示板を作ってるだけなら無いですが、
サイト作ってる場合、要件の追加・カスタマイズってあると思うんですよね
カテゴリーみたいな分類が必要なコンテンツって、
記事、掲示板、お知らせ、特集、クチコミ、求人など様々思いつきますし。
それをWordpressのように単一参照テーブルで管理しろってのもちょっと・・。
>>599
それも考えたのですが、ひとつのDBに数テーブルしかない状態でわけるってのも
どうかと思うんです。JOINの効率も悪そうだし。
>>600
すみません。単に例題として出しただけです。 とにかく的確な答えがない=よくある設計の悩みじゃないってことですかね
categoryじゃなくても、menuとかclassとかgenreとか似たような用途に使える
名前があるし、わざわざカテゴリーって呼び方にこだわらなくてもいいかもしれません
一般的な質問でない場合、上記のように解釈して妥協します。 力技で命名するより先に設計見直したほうがいいって言われてるのが理解できないのかな
記事カテゴリー
掲示板カテゴリー
お知らせカテゴリー
特集カテゴリー
クチコミカテゴリー
求人カテゴリー
普通のお客さんならキレるよ >>603
お客さんに提供してないのでキレられることはないですが、
設計を見直すということは、既存のテーブルの名前を変えろということですか?
何度も記載していますが、最初はただの「カテゴリー」として作っていたものを
後から「記事カテゴリー」と別名にするのはリスク高いと思います。
だから力技で命名するしかないのではないか?と思う次第です。
「いや、後から用途が増えるなら変えるべきだろ」
というなら私の認識が間違っているので変更しますが、
確信的なレスがないので納得できないでいます。 自分の説明の仕方が悪いと思うので、もう一度整理します。
(1)初期運用段階
article → 記事テーブル
category → カテゴリーテーブル
article_cateogry →記事のカテゴリーテーブル
(2)「カテゴリー付きの掲示板が必要」という要件が発生した
bbs → 掲示板テーブル
bbs_category → 掲示板カテゴリーテーブル
bbs_bbs__cateogry →掲示板の掲示板カテゴリーテーブル
[悩み]こういうテーブル設計を追加するのはおかしいと思う。
一般的にはどうするべきですか?
(補足)>>603さんの案:既存のテーブル名を変更
article_category → 記事カテゴリーテーブルに変更
article_article_cateogry →記事の記事カテゴリーテーブル
[悩み]途中で既存のテーブル名を変更するのはリスクが高くないか いやいやw
>>603のは普通は全部一つのカテゴリーテーブルでまとめられるだとって話なんだけど・・・
CMSで管理するサイトコンテンツのカテゴリーでしょ?
記事に付けるタグと求人に付けるタグが共通でも問題ないし
どちらか一方にしか使えないタグが必要でも
いちいち別テーブルにしなくてもまとめて管理できるでしょ
力技の命名ってのは関連テーブルを示すprefix/infix/suffixを決めて
それを該当スキーマ内で一貫して使うみたいな規約で逃げるという意味
既存のテーブル名を変更するのがリスクが高いかどうかはアプリの作り次第だが
CMSならリスクは知れてる >>606
もしかしてCMS=既存のCMSを指してますか?
そうでなくて、自作の話なのですが・・。
それにひとつのカテゴリーテーブルで、>>603みたいなのをまとめるのは無理です。
例えば以下のようなカテゴリーが必要だとします。
記事 |全般、Web制作、システム開発、データベス
掲示板|パソコン、ニュース、エンタメ
お知らせ|サービス、イベント、運営会社
記事コンテンツで、掲示板で使用する「パソコン」というカテゴリーはいらないし、
お知らせコンテンツにある、運営会社というカテゴリーもおかしいです。
カテゴリーテーブル(category)を以下のカラム構成にして
id(pk)|target|name|
1 |article|全般
2 |bbs |パソコン
SELECT * FROM category WHERE target='article'
というSQLを実行すれば、「記事だけのカテゴリーを抽出」することは可能です。
しかし、こんな設計は明らかにアンチパターンですよね?
JOINするときはWHEREとセットになるし、SQLコストも増大します。
通常は要件に伴ったテーブルを用意するはずです。
それともアンチパターンとか関係なく、上記のようにするのが普通なのでしょうか?
あるいは、カラム設計自体も違うというのであれば、正しい設計を教えていただきたいです。 >>607
細かいところを置いておくとそのテーブルイメージの考え方はアンチパターンではないよ
同じ情報を管理するのに全部別テーブルにするほうがアンチパターン
JOINするときWHEREとセットになるんじゃなく
記事/掲示板/お知らせみたいな要素を指すIDが結合条件になる
仮にWHEREで指定することになったところで
カテゴリーテーブルの件数なんてめちゃくちゃ少ないし
きちんとインデックス付けてればSQLコストが増大とかしないから はじめからそういう要件を想定できなかった以上、きれいな設計にしたいなら作り直せ >>607
それとそのカテゴリーの例を見ると
1つの記事や掲示板は1つのカテゴリーにしか属さない風にも見えるけど
複数カテゴリーに属する前提であってる? この態度で回答するやついたら神だな
俺は絶対スルー案件だわw >>607
上でもそうだったけど、命名がおかしい気がする
掲示板のところにある「パソコン」「ニュース」「エンタメ」というのは
5ちゃんねるで言う板のこと? (たとえばこのスレはデータベース板だけど)
記事・掲示板・お知らせの関係がわかると答えやすくなると思う
(例えば掲示板と記事は一対多の関係など) なにがどうアンチパターンなのかも判断できないのに
こいつのアンチパターンだからダメって脅迫概念はどっからきてるんだ >>607
> 正しい設計を教えていただきたいです。
そもそも絶対的に正しい設計なんてない
例えばカテゴリーテーブルを>>603の各項目毎に作るのか1つにまとめるのかも双方にメリット・デメリットあるからケースバイケースで常にどっちかが良いというわけじゃない
算数の答えみたいに正解が1つと思うのはやめた方がいい レス前後しますが、
>>613
何がどうアンチパターンか=正規化ができてない
って判断はおかしいですかね?怒られる程なのでしょうか・・・
>>608
既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ?
単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。
>>609
煽り抜きで教えてほしいのですが、
普通に「思ったより反響があって増築の必要が出た」
って要件、くさるほどあると思うんです。
1か100かじゃなくて、1・2・3って成長していくものだと思うんです。 >>610
591や605の例で中間テーブルを想定していますが、
>>607の例でも中間テーブルを用意すれば、多対多は可能だと思います。
>>611
真摯に議論したいし、間違っていたら教えてもらいたいだけです。
>>614
おしゃるとおりですが、そもそも私の質問自体「こいつ馬鹿じゃね?」
って感じのレスを頂くものですから、ベストプラクティスがあると思うんです。
それにみなさんはどうしているのかを聞きたいのが、希望ですし・・。 >>616
>中間テーブルを用意すれば、多対多は可能だと思います。
実現可能かどうかじゃなく要件として多対多が要求されてるの? >>615
>既存テーブルのカテゴリーを使用する箇所すべてで、SQLを組み直すんですよ?
>単純にリスクが増大すると思うんですよね。手間云々だけじゃなくて。
自分のまずい設計を正当化するためにリスクが増大するんですって言ってるんじゃなく
微妙な設計になることのデメリットと既存の部分を触ることによるデメリットを
天秤に掛けた上の判断なら別にいいと思うよ
CMSでカテゴリーテーブルを使用する箇所が
あっちこっちに散在してるようならそもそもの設計がまずいとは思うけどね >>617
要求されています。
>>618
618さんの解釈では、
「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」
ということですよね?それがまずい設計だと、
私は「ひとつのテーブルですべてのカテゴリーを管理する」
ことがまずい設計だと思っているんです。
なぜまずいと思うかというと、アンチパターンだったり、正規化できていなかったりと
一般的に悪いと言われるテーブル設計を採用しろと言われているからです。
618さんの言う「カテゴリーはカテゴリーなんだから、複数あるのはおかしい」
という主張は理解できます。
しかし、ひとつのテーブルに用途違いのデータが入ることの正当性が
私には理解できないので、618さんの主張が正しいと思えないんです。
煽っているのではなく、主張を正しいとする論拠がわからないんです。 意識低い系の自分はその場合カテゴリのテーブルは一つのままカテゴリの種類ごとにidの範囲を変えて運用してしまうな
記事カテゴリは10000〜19999、特集カテゴリは20000〜29999みたいな >>620
それで記事テーブルと結合する時はどうするんですか?
全てのSQLにWHERE id BETWEEN '10000' AND '19999'
を追加するのでしょうか?
>>621
5ちゃんねるでいうと板になるんですかね。
記事とか掲示板とかお知らせは1つのテーブル(1つのコンテンツが入る)であり、
カテゴリーというのは、そのテーブル内のデータを分類するために必要です。
1つの投稿に対して複数のカテゴリーを割り当てられることから、多対多ですね。
5ちゃんねるの場合、1つの投稿に複数カテゴリーを割り当てないと思いますが。 >>619
>「すでにカテゴリーテーブルが有るのに同じようなものを用意する必要はない」ということですよね?
違う、そういう考え方じゃない
既存のしがらみは一旦忘れて同じエンティティなのか異なるエンティティなのかを考える
その答えは要件によって変わるんだが
今のところ異なるエンティティとして管理すべき要件は見当たらない
正規化できないというのは君の思い込み
コンテンツの種別ごとにカテゴリーテーブルとその中間テーブルを作らなきゃいけないのは
SQLアンチパターンの9章にある”Antipattern: Clone Tables or Columns” CMSならコンテンツを管理する単位が記事だろうと掲示板だろうと
共通に扱える仕組みを用意した上で個別に必要な拡張が施せるようにする
記事に特化した記事管理システムなら
そこに掲示板管理システムをそのまま増設するのは悪手で
DB含めてシステムを分けるか再構築してまともなCMSにする >>624-625
自分のスキルが低いと思うんですが、理解できずに申し訳ないです。
それでは私が最初に構想していた>>591という
要件毎にテーブルを作るやり方ではなく、
>>607のような、ひとつのテーブルでまとめるやり方が正しい
(今回の相談ケースではこうするべき)という解釈で良いのでしょうか?
AでもBでも良いとか、AもBもよくないという結論では
モヤッとしてしまうので、どちらがベターか指摘してほしいです。 >>616
> ベストプラクティスがあると思うんです。
だからケースバイケースだっていう話
>>611
お前が正しかったわ 突然伸びててビビったズラ
テレワークは終わりですよ お前の言うカテゴリーとは何なのかを詳細に詰めないとベストな答えなんか出ないわ
テーブル名とかまあどうでもいいわな
掲示板カテゴリーと記事カテゴリーが別だとするなら別テーブル作ればいいし
同じだが使用箇所が違うだけだと思えば一つで良い 命名規約があるなら結果変なテーブル名になっても仕方ない
それがいやならテーブル名を連番にでもすればいい >要件毎にテーブルを作るやり方ではなく
要件という言葉を理解してないw
無知なのにイキってる感じがQiitaっぽいな カテゴリと内容の関係ならカテゴリに記事と特集を示すフィールド入れれば解決ずら
その程度の変更もできないプログラムだったらプログラム側の設計も見直したほうがいいら 話題変わるけど10万円給付のオンライン申請で多重申請とかで問題出て停止しているようだけど
これってDB設計が糞だと思うんだけどどうだと思いますか? 多重申請を許容するかどうかは要件次第なので
多重申請ができるからといってDB設計が糞とは言い切れない
DV被害者対策や郵送申請もあるので
後続の業務はもともと多重申請がある前提で設計しておく必要がある
実際のところは短期間での開発を要求されたから
普通なら必要になる画面や機能を削った結果
多重申請を許容する仕様にせざるを得なかったんだろうな ググったら10人以上の世帯は複数回申請しないといけないからってのと
間違った内容で申請した場合に後から正しい内容で申請できるようにするために
多重申請ができる仕様にしてるらしい
付け焼き刃だし仕方ないかもね
郵送に一本化しといたほうが効率的だった可能性もある 今回の目的はギョウムカイゼンじゃなくて感染防止だから……
単に用紙の持ち込みをオンライン化しただけで
持ち込まれたデータのチェック・管理はすべて人力
分かりやすいシンプルな良いシステム >新型コロナウイルスの感染拡大に伴う現金10万円の一律給付を受けるためのオンライン申請について、
>東京 調布市と福生市は入力された情報の確認に時間がかかり給付が遅れるおそれがあるとして、受け
>付けや手続きを停止しました。オンライン申請を巡っては、同じような対応をとる自治体が各地で相次い
>でいます。
https://www3.nhk.or.jp/news/html/20200521/k10012439151000.html オンラインで申請すると郵送よりも処理に時間がかかる上、
郵送分の処理も妨害して遅くするのでやめてほしいそうだ。 >>607
自分が俄で視点が近いからか微妙に解る気がするんだけどこの設計がEAVじゃないかって気になるって事であってる?
けどこれって>624の「同じエンティティなのか異なるエンティティなのかを考える」が全てで、
カテゴリーっていう同じエンティティなんだから同じテーブルに纏めたってEAVにはならないのではって事だと思うが
このテーブルに[targer:person_name, name:田中]みたいなレコード登録したらEAVだと思うけど EAVかどうかなんて考え方次第
カテゴリーテーブルがサブカテゴリーにたいするEAVだって考え方もある
EAVだからアンチパターンでダメだって考えが間違ってる
アンチパターンと言われているものの、何がどうダメなのかちゃんと考えないと AmazonみたいなECサイトで商品カテゴリと顧客カテゴリを管理するとしたらほぼ確実に別エンティティ
Youtubeの動画に付けるタグとGmailのメールにつけるタグも1テーブルで管理することはまずない
(RDB使ってない可能性のほうが高いけど)
QiitaがもしQ&A掲示板を始めたり技術イベントの告知・集客サービスを始めて
各スレッドや各イベントにタグ付けできる機能を実装するようなケースは
既存の記事向けのタグと同じエンティティとして管理する可能性が高い 雑談っちゃ雑談だけど抽象化思考が苦手なやつが多いみたいだから具体的なインスタンスを示してみたんだよ
ケースバイケースとか考え方次第で済ませてその判断基準を何も提示しないのはゼロ回答に等しいからさ 事例に対する個人の判断結果を示してるだけで、肝心の判断基準を示してない件 質問です
csv ファイルを提供されて
数量データが4000なのですが
少数第二位までという4000.00の意味の
400000というデータで提供されます
毎回エクセルで100で割ってからインポートします
また、顧客コードが10桁で
数字の羅列が醜いので
12-3456-7890とハイフンの追加も行ってから
インポートします
毎月の事なのですが
この数量データ割算と、顧客データハイフンを
いちいちExcelで処理せずに
インポート時やインポート後にうまく処理する方法は無いでしょうか? >>652
若干スレチな気もするがその内容ならCSVを変換するスクリプトを書くのが手っ取り早いと思う
どういう方法が最適かはDBMSの種類、既存のインポート方法・インポート時の処理内容、処理件数、所持スキル等による ここまで回答見てきたけど、結局ケースバイケースで終わる話ばかりだな 経験浅いとケースバイケースが理解できないから仕方ない そのケースバイケースを細かく教えて
今ここで話題にしているのはその事例なんだから >>656
>そのケースバイケースを細かく教えて
これがケースバイケースが理解できてない典型例 >>652
この質問だけだと良くわからないんだよね
csvファイルはどういうDBにインポートされるのかとか
そもそもなぜ100で割ってからインポートするような謎な仕様になっているのかとか
ひとまずこの質問文だと, DB設計の話ではなく, DBを扱うプログラミングの話でしかない
DBにアクセスするプログラミング言語で実装すればよい >>658
何を知りたいのかを他人が理解出来るようにまず説明して 「ケースバイケースで終わる話」って説明が必要なの? 客観的に見て「それケースバイケースだよね」ってレスするより
「これはこうしろ」ってレスするほうが早くないか?
質問者に喜ばれるし、自己顕示欲も満たすし、スレも荒れない。
何も損しないんだが、なぜケースバイケースってまとめるのかわからん >>663
早くない
質問する側がどういうケースなのかを特定するための説明をするほうが断然早い
どういうケースなのかを相手に伝える努力を放棄してるにもかかわらず
答える側にはケースを想定した回答を求めるのは無理筋 何をもって
「それケースバイケース」って言えるか位は、
言えるだろう
それを聞いている >>664
それならもっと詳しく聞けばいいだけじゃないか?
プログラム板とか情報足りないとそう答えてるぞ
荒れやすいニュース板でもケースバイケースとかどっちでもいいとか
クソレスするやつは少ないよ
ここぐらいだ。端からコミュニケーション放棄してるのは 自分の好きな例を持ってくれば良いという、簡単な事だろう 普通ならそうだよ。
「AまたはBですか?」
という的外れな質問でも
「Cだよ」って回答して
「いや、CじゃなくてAはこういう意味で〜」
ってな感じでスレが流れる。
しかしここは「AでもBでもどっちでもいい」だもん。
まるで会話になっていない >>665
「それを聞いてる」じゃわからないよ
何を聞いてるの? >>666
>それならもっと詳しく聞けばいいだけじゃないか?
それは単なる甘え
自分が努力せず他人に努力させようとしてるやつに
仕事でもないのに懇切丁寧に聞き返す労力を払うやつは少ないわな ここは、AかBかって質問で充分なケース想定ができるならもともな答がかえってくるわ
ケースバイケースっていわれた段階で説明が足りんと気づけや 653
659
スレチなのにご回答ありがとうございます
とりあえずデータベースだけで出来るような仕組みを考えます ちゃんと説明しないやつはコミュニケーションが足らないって言ってるやつが相手してやればいいだろ
内容がはっきりすればそれなりに回答してくれてるだろ、このスレは 常にケースバイケースなら、
ケース分けなどいらないぞ ちゃんとやりたいことを説明しないからケースバイケースって言われるんだろ ワークテーブルにいれてから
加工するsqlでインポートはどうかな ハイフン入りの顧客コードは計算列という選択肢もある
参照整合性がどうなってんのか気になるが エクセルだろ
セルに書式設定すればいいんじゃね
インポートして書式設定までVBAですぐできるだろ >>677-681は想像して書いてるよな。
>>676みたいな奴は読解力がないだけ >>682
想像してるんじゃなくてDBだけでやりたいという形でケースの特定化がなされたことで>>677や>>680の回答が出やすくなってるんやで >>682
これに関してケースバイケースなんて言われてないだろ
お前はそれ以前に日本語が読めないのか? すみません。IDの設定について教えて下さい。
現在、id (INTEGER) と user_name (TEXT) の2カラムで、以下のデータがあるとします。
1 , 東京営業所
2 , 沖縄営業所
3 , 北海道営業所
4 , 東北営業所
データを取得時、以下のように北のほうからの並びで取得したい場合は、並び順を設定するカラムを追加するしかないでしょうか?
3 , 北海道営業所 , 1
4 , 東北営業所 , 2
1 , 東京営業所 , 3
2 , 沖縄営業所 , 4
既存のテーブルで、設計を変更するとプログラム側も変更しないといけない場所が何か所か出てくるので、
極力変更したくないのですが・・・ どうしても変更したくないならソートオーダーの為だけの新テーブルを追加
素直にフィールド追加した方が後の保守は楽ですよ
プログラム側はフィールド追加で影響が出ない様に作るものですけどね 既存テーブルへのカラム追加で既存プログラムも修正が必要になるのって
データを複製してるような処理しか思いつかない
そういう処理なら並び順もデータとして必要になるよね 今どきアスタリスク指定してるくらいじゃ問題にならんよ
最終目的地までカラムを指定せず全部出力するなら別だけど 今order by指定していないなら、それは「たまたま」id順で出てるだけ
どっちにしてもorder by指定する必要がある
今idでorder byしてるが、それを変えたくないなら、id振りなおすしかないわな
id振りなおすのとカラム追加&プログラム変更とid振り直しとどっちが楽か判断して決めれば良いんじゃね さあ
しかしorder byがなくて
バクるアプリを引き継いだワイにはタイムリーネタやで 都道府県コード使うとしても、北からの並びではないからなあ
並べたい順に自分で番号付けたテーブルを用意しないと無理でしょ >>687
そのIDにエリアの概念を持たせなかったのが失敗なんだよ。 idにidentity以外の意味を持たせるのは愚策。素直に順序列を追加するのが吉。 電話番号や郵便番号のコード体系を考えたこともないのかね。 コード体系が必要なら各意味を別々のカラムで管理してコード自体は導出項目にする
コード体系を作ったこともないのかね。 汎用機世代の人やRDBをよく知らないExcel屋さんは
すぐ暗黙のコードを使おうとするんだよね
昔、東大卒のマーケティング屋さんが
10個以上の意味を埋め込んだオレオレ独自コードを
自信満々のドヤ顔で説明してきた時は困り果てたよ 匿名掲示板で、ID表示なし、コテハンもトリップもナシでどやられてもなあ コード体系の話はプライマリキーが代理キーかナチュラルキーかは関係ないよ
複数の意味を持たせるのがアンチパターン いつもの触っちゃだめなやつ
控えめに言ってガイキチなので気をつけろ >>699
identityではなくidentifier。 >>699が言ってるのは「identifierにidentity以外の意味を持たせるのは愚策」ってことやぞ あるコード(体系)を設計し導出項目となり、それをキーとしたいとなった場合
必然それは代理キーとなるだろう、とは言えるが
導出項目をつねに代理キーにするとか言ってないし
代理キーが主キーに限定されているわけでもないし
そもそもコード体系云々以前に
一つの項目に複数の意味を持たせるなって大原則があるだけ もしかして代理キーをsurrogate keyの意味じゃなくalternate keyの意味で使ってるのか?
もしそうなら誤訳以外のなにものでもないので別の訳語なり用語を選んだほうがいいと思うぞ https://ja.wikipedia.org/wiki/代理キー
代理キー(だいりキー、英: alternate key)
代替キー (サロゲートキー、surrogate key)
これはやべぇw
英語の日本語の意味が完全に逆 >>716
その代替キーはIPAでは代用キーと呼んでいる。
サロゲートキーのことを「代理キー」と呼ぶのは日本の慣習です。
英語の翻訳語は使われ方が反対になることがあるので注意してください。 >>716
wikipediaの記事ができるより前の時期で検索してみたが
surrogate keyは代理キーは、alternate keyは代替キーと正しく訳してるものしか見つからない
オラクル、富士通、ユニシス、@IT、オージス総研などなど
古いDBマガジンを確認しても代理キーはsurrogate keyの意味で使われてるものしかない
歴史修正主義なんかな? alternate keyは二次識別子と言っておけばだいたいOK テーブル設計であえて正規化しないで置くべき理由ってなにがあるでしょうか?
ちょろっとググった感じだと、パフォーマンスが重要な要件だとテーブル結合をなるべく避けたい
とかが見つかりましたが 素人なので断言できませんがパッと思いつくのは
多重管理を避けることができ、それに付随して
・テーブルの意図が明確になる
・データ不整合の発生を防げる
などです >>721
トランザクション処理中心の業務系データベースの場合は基本的に正規化する
更新異常を防いで整合性を維持するため
ただしパフォーマンス最適化のために正規化されたものを非正規化することはある
その場合でも設計時には正規化された場合の構造を明確にした上で非正規化する
そうしないと非正規化したことでどういう更新異常が発生しうるのかや
アプリ側で担保しなくてはいけないデータ整合性が明文化されないから
データウェアハウスのようにデータの追加はあっても更新のない情報系データベースの場合は
全く正規化しないわけではないけど最初から分析しやすい形を念頭に設計する >>724
やはり特殊な用途を除き正規化するのが基本なのですね
ありがとうございます
身近で詳しそうな人に正規化した設計を提出したところ
フラットに作り直すよう指摘され、明確な理由がわからず
もやもやしておりました
開発観点の他に運用・保守観点(項目の追加/削除、データの追跡可能性)
を想像してみても特に正規化を避けるべき理由が思い当たりませんでした なぜ指摘した本人に理由を聞かないのか
そもそもそれほんとにちゃんとした正規化が出来てるのか?
正規化を避けるべき理由はないのか?
そもそも設計を提出ってなんだよ。業務なのか?
だったらなぜ上司ではなく詳しそうな人なんだ もしかしてRDBじゃなくMongoみたいの使う前提なのかな?
まあ指摘した本人に理由を聞くべきなのは間違いない 理由ははぐらかされてしまいました
そっちのほうがいい気がする
というようなことを言っていました
> もしかしてRDBじゃなくMongoみたいの使う前提なのかな?
RDBです 技術的な面じゃなくサーバーが年代物で貧弱とか
開発予算がないから手抜きで作るとか政治的な事だったり 正規化した設計とかフラットにした設計の中身が
もう少し具体的にわからんとなんとも言えないね
フラットにすることで更新異常が発生しうるんなら
メリットデメリット理解して選択するしかない >>725
世の中には自分の理解できないものは使うな
って言う上司とか先輩はいっぱいいる
その人に従わないとダメなら言質を押さえて従うがよろし
単に詳しそうな身近な人と言うだけならもう変更の工数ないからとか言って無視しとけばいい 原則は教科書通りにるすのが一番ですが
場数踏んだ熟練のPGさんとか
製造工数おさえてギリokみたいな
絶妙な作りしてくる人もいる
理由は経験とカンみたいな
気にやまないことだと思います すぐに言語化できなくても直感的にモヤッとする設計ってのはある
必ずしもその直感が妥当というわけではないんだけど
熟練になればなるほど感覚的なものも大事にしたほうがいい 第4や第5とかボイス何たらとかを第3に戻されたとか? 第5はともかくボイスコッドで設計できる人の質問ではない気がする 詳しそうで素人な人もいるぜ
クソ設計なテーブルで、プログラム書かされて死にそうになったことある >>736
ボイスコッドの方が難易上なの?
自分が理解し切れてないのだけど、ボイスコッド正規形は条件満たすだけならまあ簡単だけど実務とか現実世界の関係的に違和感のある設計になるよくわからんもの、みたいなイメージがある…… 実務のボイスコッド正規形は理論のそれと違って
導出属性を使った制約を追加することで第三正規形から関数従属性を失わずに
ある種のビジネスルールをデータモデルに埋め込むことができる
第3や第5よりもBC正規形使った設計ができる人のほうが
DB設計に対して深い理解があると思うよ とりあえずサロゲートキー持たせたいとき(持たせるって表現で良いのか解らないけど)って、
数字のみの連番にする? 何か文字列も付与する? ケースバイケース?
数字のみで良いのかなと思ってたんだけど、文字列付けた方が良い時ってあるんじゃろか サロゲートキーという範疇に入らないかもしれないがUUIDを使ったほうがいいケースは自然と文字列も入る
分散データベース間でも一意に識別したいとかDBにアクセスせずに一意なIDを生成したい場合
でもそういうのはDBのプライマリキーには使わないから
1つのテーブル内の一意性で十分で、数字の連番を使い切る可能性がなければ文字列を入れる理由はないかな
他には人間に読みやすくかつ間違いにくくするために文字を入れるケースもあるけど
その場合は生成した数字とは別のカラムで文字列込みの値を管理する 最初に文字を入れると全部桁数は揃うだろうから見た目は気持ちはいいかもな >>741
なるほど。こういうのもあるのか
> その場合は生成した数字とは別のカラムで文字列込みの値を管理する
これはこれで、それぞれのカラム名どうしようとか悩みます
文字列込みにした方が人間に読みやすいのは確かなんだけど、2つ管理するのも不慣れなせいかしっくりこない
選択肢が増えてますます混乱したw そもそも代理キーに文字を入れたいとか、代理キーになんらかの意味を持たせたいってことだろ
それすでに代理キーじゃなくね >>744
代理キーならあるでしょ
サロゲートキーの話をしてるなら同意するけど 商品に、表示フラグ、新着フラグ、18禁フラグや、表示優先順位などWeb上の表示だけに特化した値を持つ場合、商品マスタに書いてしまっていいのでしょうか?それとも別に持ったほうがいいのでしょうか? 表示フラグと18金wはいるだろうな
他は、コロコロ変わるものだから
別にして良いと思う >>747
商品マスタの構成や商品マスタをどう使う前提なのかによる
一般論で言えば商品IDが決まれば値が確実に決まるような属性なら商品マスタに書く
商品すべてがWeb上で扱う前提ならWebに特化した値も商品マスタに書いてもいい
Webに特化した属性のCRUDのタイミングが商品マスタの基本属性と異なるなら
別テーブルにしたほうがいい可能性が高い
18禁フラグ以外は商品ID+日時の組み合わせで管理できるようにしておいたほうが運用は楽
(商品マスタ自体が商品ID+日時の組み合わせで一意になるようなら更新頻度/更新タイミングなどから別テーブルにするかどうか検討)
あと新着かどうかは販売開始日付みたいなのからアプリで判断するほうが普通 サロゲートキーにulid 使うのは異端?
スレ検索してもulid 出てこないね。 サロゲートキーにUUIDを必要とするユースケース自体がかなり稀だからね ごめん、ちゃんと注意して書けば良かった。
128bitのUUID(Universally Unique Identifier)ではなくて、
同じく128bit(Timestamp 48 bit + Randomness 80 bit)のULID(Universally unique Lexicographically sortable IDentifier)。
日時でソートできるUUID的なヤツなんだけど、あんま使われてないんかな? わかってるよ
UUIDを必要とするユースケース以外でULID使うことないでしょ それサロゲートキー項目に一意性と日時って二つの意味を持たせることになるんじゃね
ありえないな。日時でソートしたいならちゃんと日時の項目もつべき 生成順にソート可能にするための実装として日時を使っているからといって
日時の意味を持たせてるということにはならないよ
ULIDから日時を取り出してデータ作成日時として利用するなら別だが 日時としての意味はなくても、その日時で生成順としての意味をもたせてるじゃないか
シーケンスとか生成順に使うような場合って実際には結構あるけど、本来それも間違ってる
昔のオラクルのマニュアルとか生成順は保証しないようなこと書いてあったんだがなぁ 大小比較可能な値を生成したら「二つの意味を持たせてるからありえない」ってどういう脳みそしてるんだか
オラクルが正だと思ってるようなやつは中途半端な知識で
斜め上の御託を並べ立てるやつが多くて困る 一意保障以外に大小比較って意味をもたせてるんだから二つの意味なんだが
サロゲートキーに一意保障以外の意味を持たせるなって大原則をまず理解しような シーケンスのDB発番はクラスタ化が難しいので元々ありえない。
UUIDは日時でソート出来ない。
ULIDはソート出来るだけでありがてぇ。パーティショニングで役に立ちそう。あ、DB発番しないよ。 だったら素直にUUIDと日付列用意すればいいんじゃね
インデックスの効率落ちそうだ >>759
なんで2つ意味を持たせると良くないのかをまず考えろよ
その理由を理解せずにトンチンカンなことばっかり言ってマウント取ろうとするからいつもバカにされてるんだぞ 上の話どうなった?
自分740の質問した人間なので気になる
きのこたけのこ論争みたいなもんで正解はないやつ? UUIDの代替としてULID使うべきかどうかはケースバイケースだからその点ついての正解はない
ULID使いたければ特徴と限界を理解した上で使えばいい
まだ比較的新しいものだから標準ライブラリ相当で安定した実装が提供されてる言語は少ない
二つの意味を持たせてる云々は少し考えればわかるでしょ ULIDはUUIDのパフォーマンス問題を軽減できるのが一番大きい >>765
インサートが遅くなるアレ?
ulid 解決できるんだ!? UUIDを主キーにするって人は、衝突しないって前提でやってるの? そりゃそのために作られたものなわけだし。使う場合はその前提に乗っかるのが当たり前。 UUID使ってるシステム見たけど
データが無駄にデカイし
インデックスもやたら膨らむしで
主キーに使うのも考えもんだな
気持ちはわからんでもないが >>770
衝突しない前提なら、衝突したときのリトライ処理等は不要だ
つまり衝突したときの対処してるかって質問だろ それはエラーをどう扱うかという話で衝突しない前提ではないよ
ユーザーにリトライを促すような個別の対処はしてなくても集約エラーハンドラで結局対処してる だから、UUIDが衝突したときに個別の対応してるかって質問なんだが
まあ、お前がやってないだろうことは理解した
GUIDが衝突したって話は聞いたことがある
UUID衝突の可能性はゼロではないんだが、まあ起こったときの重要度次第か UUIDやULIDって衝突した事を想定した方がいいの?
だったらオートインクリメントで良い気がする。 トランザクションが失敗したらリカバリなりするだろうが、キーの重複が原因の時だけ特にどうこうってのはないんじゃないかね オートインクリメントのように一箇所で採番できる状況ならUUIDは使わないよ プロシージャー書いて自前で発番すれば良いのではないか UUID/ULIDよりも18禁商品マスタのほうがいかにもDB設計っぽい内容にもかかわらずレス数が桁違いになるのはなぜなんだ? >>747ならどっちが正しいと決まるもんでもないから、追加情報でもない限りそれ以上話が広がらないし
単純に内容がつまらない。 設計スレなのにどっちが正しいか決まるようなものを期待してるのか
理解に苦しむ 質問者はどっちがいいか聞いてるわけだろ?でもどっちでもいいから話はそこでおしまい。 >>779
机上の知識だけでコメントしやすい内容か
設計の経験がないとコメントしにくい内容かの違い
珍しくにぎわってるからいいんじゃないの QiitaのWeekly Trendで4位に入ってたから読んでみたが・・・
https://qiita.com/abe_masanori/items/1a2b9c1f1069c43237f8
扱ってる題材のレベルが低いのは初心者向けだからいいとしても
こんな問題だらけのデータモデルとユースケース書いて平気な顔してる開発者はやばいよな? マイクロサービスとかいって、REST API 呼び出しをループで大量に実行しようとする
これの気持ちだけちょっとわかる
やれoop、やれdddのお作法に合わせて
少ない件数でテストしてできました!
とかやる奴 会員登録しないとまともに機能しないサイトは検索上位から消しほしいよ Googleで検索すると上位に出てきてしまうんだよな
判断力がない奴が読むと、とても危険 サンプルだし目くじら立てるほどか?
グルグルSQLどころか
ぐるぐるコネクションされて
性能調査に回って来た時には吹いたから
気持ちはまあわかる
コードのオブジェクト指向的
美しさ、べき論を説かれたが
俺はプログラマーじゃないから
ようわからんかった ネットショップで画面に商品リストとその詳細仕様を表示する処理があったんだ
前任者はどう作ったかというと、まず商品一覧を取得するSQLを発行した
そのSQLが返してくれる商品一覧に対して、一つずつ詳細取得するSQLを発行した
10件位の時は問題がなかった。多分前任者はこれでOKにしたんだろう
ショップがオープンして、100件、1000件と扱うようになった途端、
メチャクチャに処理に時間が掛かるようになった
で、どう直したかというと、商品一覧を取得する段階で、細かく詳細も取得するようにした
詳細取得が商品種類毎に違っていて、SQLは場合分けが必要で複雑になってしまったが
客は結果を見て喜んでOKを出してくれた
なんでこうなったかと考えて見ると、詳細設計書段階で、
取得する手順の記述があったからのようだ
設計書はとてもシンプルで綺麗な記述になっていた
※この話はフィクションです、実在する人物・企業とは関係ありません 1000件の詳細情報を、一度に取得して表示ねぇ...
まあなんにしても、DB設計の話じゃないな >>785
マイクロサービスに限らず逐次処理と一括処理とでAPIを分けるのが常識なので
テスト以前のAPIのレビュー時に気づくべきことじゃないか? SQLを直接書いてるのにN+1で問題になるようなコード書くような人間は周りにはいないな
ORM経由のN+1は仕組みをよく理解してない人間がやらかすけど
そういうのも本番環境に出る前には確実に修正される
DB側で検知する仕組み入れとくと確実かもね >>784
これはヒドイ
プレミアム会員フラグや商品価格を変更できないw
ぐるぐる以前の問題 商品価格変更されたらどうするんだろうと悩ませておいて、問題文の隅っこに
「価格改定の場合は新規に商品IDを発行する」なんて条件が書いてあったりする
情報処理試験のパターン。 >>798
同じ商品に対して複数のPKを発行できるようにするならモデルが違ってくる 情報処理試験を受けさせてるベンダーほどまともなDB設計できないよね このタイプの派生関係を使う場合は
読み取り用にはViewを用意してやるといい
各SQLで毎回ケアするのは無駄 >>799
>同じ商品に対して複数のPKを発行
意味不明。
「同じ商品に対して複数の商品ID」なら意味が通じなくもないが
その部分は>>784には描かれていない。 >>802
「同じ商品に対して複数の商品ID」を発行するとして
どうやって同じ商品かどうかを判別するの? どうやってもなにも、「同じ商品」を判別できるデータを持たせるしかないわな。 同じ商品かどうかを判別するための識別子が必要だよね
それを一般的には商品IDと呼ぶことが多いから複数の商品IDじゃなく複数のPKと書いたわけ
名前は別にいいんだけど
同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
それをモデルに描かないのはありえない
それにある商品の標準価格を変えようとすると
対応するプレミアム価格も変更が必要になる
なら別テーブルにする意味ない 一つの商品ID、商品テーブル、価格テ―ブルで良くね? >>805
>名前は別にいいんだけど
>同じ商品に対して価格別に複数の商品ID(PK)を発行するのなら
>それをモデルに描かないのはありえない
そりゃ設計書としてならあり得なんだろうが実際>>784には商品とか
商品名とか描いてないじゃん。そこで説明したいポイントには関係ないから
省略したんだろうが。
>同じ商品かどうかを判別するための識別子が必要だよね
>それを一般的には商品IDと呼ぶことが多いから
一般にはそういうことが多いとしても、「商品ID」は絶対そうでなくては
ならないという決まりも無いわけなんで、そこはちゃんと定義を
確認しなきゃならん。
>複数の商品IDじゃなく複数のPKと書いたわけ
PKってのはテーブルの定義なんでそこは明らかに間違い。
「商品に対する商品ID」か「商品テーブルのPK」じゃなきゃ
意味が通じない。 >>798
>「価格改定の場合は新規に商品IDを発行する」
その場合でも注文データに確定した支払い金額を記録するぞ
バッチ処理でユーザーごとの購入金額を集計するのに
マスタから価格持ってくるような設計はやばい 子供の喧嘩じゃないんだから、反論があるなら具体的にな 長いからちゃんと読んでないけどあの記事で言いたいのって
ぐるぐる SQLは性能に問題が出るからやめようねって話なんじゃないの?
テーブル設計はあくまで例であって、そこをここで突っ込んでも… でもレス返してるやつはそれで正しいと思って返してるのでは? >>811
まともなDB設計ならぐるぐるSQLすら発生しないだろ そしたら件の記事は設計変更しないでぐるぐる解消しているから「まともな設計」ってことになるが >>790
コードの美しさとは無関係というか両立できる問題じゃないかなあという気がするんだがどうなんだろう
> ぐるぐるコネクションって、ループの内部で都度接続と切断繰り返してる処理であってる?
>>808
現時点の注文(=買い物かご)と注文履歴は別管理なんじゃねって言う勝手な想像 運用面で破綻しなければそれはそれでよい設計なのでは?
うちの販売システムは発注伝票の内容は全てトランザクションデータとして保存するし
商品マスタは通常もセットも含めて1テーブルだけど >>806
顧客や顧客種別ごとに単価を管理する場合はそうするのが普通
ただプレミアム会員向けの単価が登録されてなければ標準単価を採用するみたいなロジックはアンチパターンだから普通はやらない
単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する >>816
コードの美しさ云々は単なるいいわけでしょ
リモートのAPI呼び出しをローカルに閉じた関数呼び出しと同じように扱おうとする連中と同じ 陽キャ先輩「それDBに任せるともっと良くなるかも!」
俺「一瞬で終わって草ァ!SQLすげぇwwwwwwww」
陰キャ先輩「はぁ…ぐるぐるSQLは止めてください」
俺「あっ すみません気を付けます… ぐるぐるって何でしょうか…」
陰キャ先輩「知らないの?スキーマがこうでアプリのコードがこうだとするでしょ」
俺「あっあっ はい」
陰キャ先輩「ループがねオーバーヘッドがねマイクロサービスとか言ってる奴等なんて」
俺「はい… はい…」 >>807
>そこで説明したいポイントには関係ないから省略したんだろうが。
そもそも、元のやつの設計が複数の商品IDを発行する設計だと思ってるのか?
つかまあ、あれはほんとのシステムの設計としてはあり得んレベルだけどな
あの記事が言いたかったのはそんなことじゃないだろ 一例を出してこういう処理の仕方はやめましょうっていう内容の記事に対して
本番稼働を前提に設計レビューをしてくれる掲示板 >>818
単価を管理してるテーブルを読む段階でどのレコードを読めばいいか指定できるよう設計する
これと、価格テーブルが1個であることとは矛盾しない
価格種別を決定するコンテキストがあれば良い サンプルだからいいってレベルじゃないんだよな
あれを許容できるやつは普段同レベルの設計をしてるとしか思えない 根本原因が稚拙なDB設計にあるにもかかわらず
それを理解せずに場当たり的なSQLの修正しか考えないのは悪手でしかないわな >>827
下請け孫請けでDB設計には口出しできないんだろ 実際問題、後からDB設計間違えたって気づいたらどうする?
運用中のものを停止してでもやり直す?
それとも現状を変えずに追加し続ける? どういう種類の間違いなのかとそれによってどういう問題が発生しているのかによる
放置
ちょろっと修正
次のプロジェクトで合わせて修正
独立した修正プロジェクトで対応
障害として対応 上で例に出てた注文テーブルのような設計なら
良くて修正プロジェクト、悪いと障害対応だろうな 本番リリース後ならちょろっと修正はないわ
問題がなければ基本放置だが、遅いとかいうクレームでたらまあ協議だな ポイントはそれを放置した場合にどういうリスクがあるかだよな。
データや処理の間違いで被害を出す恐れがあるなら早めに対処しなきゃならんだろうが、
それも予想される被害の大きさと発生確率によるリスク算定次第。
運用で逃げられるようなものだったら後回しにしたり。
>>831
障害と言えるような具体的な不具合って挙がってたっけ? >>833
DB設計は単体で障害になるわけじゃないから
アプリの仕様や運用、ビジネス要件との合わせ技 ま、基本的には機能追加が目的だろうな
悪い設計のまま追加するか、それともやり直すか
前者だとコストもリスクも低いが、将来困る
後者だとその逆。
経営判断なら前者になるだろうな 普通の販売管理でこんな設計ないから続ける意味がないと思ってる 無いことはないだろ。国のシステムがしょっちゅう問題になってるじゃん。
似たようなことは日常茶飯事で起きてると思うぞ >会員は1回の注文あたり1種類の商品を複数個注文できる。
注文っていったら1回で複数商品注文とかするだろ?
注文テーブルにそんな考慮もないようなシステムで何をするんだい?w >>838
1注文あたり1種類の商品のみというビジネスモデルも実際に存在するぞ あの元記事書いた人の最大の失敗は、注文とか商品とか言っちゃったことだな
単にテーブルAがテーブルBを参照し、とか言ってればよかったのにな >>839
UIで制限することはあってもそんなビジネスモデル前提で設計しないと思うけどなぁ
まあ要件みたせばあんなDB設計でもいい人もいるんだからいいのか 1注文に複数商品IDを含めることができるようにするならその分構造が複雑になるわけだから
そういう要求がない限りシンプルな構造にしておくという考え方はあると思うが。 1注文あたり1種類の商品しか注文できないとか
価格変更時は必ず新しい商品IDになるとかは実際にあるけど
注文データに金額を記録しないのは伝票としての要件を満たさないからまずありえない >伝票としての要件を満たさない
どんな要件を満たしてない? >>819
特定のDBMSや永続化技術を意識するレイヤーと
ループしながらビジネスルールの判定をするレイヤーを分けたい場合に
ループが途中でブレイクしても確実にコネクションを切断する仕掛けが必要になる
言語やプログラマのスキルによってはその仕掛けが実現できないので
ぐるぐるコネクションになっちゃう ulid をdb側(mysql )で発番したいんだけど、自分で実装するしかない?
一応、日時(例えば20210204125959001)と乱数(80bit分)は作った。
BASE32に変換出来無いから、10進数を36進数(0-9 A-Zの36。CONV関数使用)してみた。
内部だけで使うならアリなんだけど、ユーザーに見えるところはBASE32がいいんだよなぁ。。。 このスレ的には、単一参照テーブル、又の名をOTLT
は結論出てたりする?
https://gihyo.jp/dev/serial/01/sql_academy2/000301
うちの古いシステムは大量にある名称マスタをこの方法で取り扱ってるけど、
やめた方がいいのかなと。 >>851
DB設計の観点からだけいえばEAVと一緒で100%やめたほうがいい
ポリモーフィズムでもなければオブジェクト指向は全く関係ない
RDB以前の汎用機で使われてたやり方
実際にやめるかどうかはシステムの寿命や変更の頻度を考えた場合に
手間をかけるメリットがあるかどうか >>852
流石に動いてるものは触れない。
仮に新しく作り直すとしたら
大量にマスタが作られて、大量にCRUDの画面が作られる問題が出てくる
これ皆どう解決してるんだろう
もう気にせず愚直に作った方が精神的にもシステム的にもいいんだろうか。 >>851
自分だったら単一参照テーブルにするなら内部キー(PK)・識別子・外部キー・内容の様にして
トランザクションには内部キーを保持したい
理由はテーブルの結合の際にトランザクションとマスタを外部キーで結合して
さらに識別子をハードコードするのは抵抗があるから
でもこういう設計をしても結合の際に識別子を条件に付ける人がいそうなので困る >>854
複合キーじゃなくサロゲートキーを導入するという話なんだろうけど
識別子や外部キーって用語の使い方を間違えてるから全然伝わらないぞ
識別子は基本的にそれによって行を特定できるキーのこと
外部キーはForeign Keyのこと
商品IDとJANコードのようなのは内部ID/外部IDとは言うけど外部キーとは言わない >>853
マスタメンテ画面が必要ないものもたくさんあると思うんだけど
必要なら汎用的なマスタメンテ画面を作ればいいんじゃない >>856
いっぱいお客さんいると男女ですら変更したいという要件もある…
さらにやっぱり英語名も持ちたいとか色々要件増えて管理する項目も微妙に変わってくんだよな…
で、それを汎用項目みたいな持たせ方してるんだよ…
恥ずかしながらこの記事の作者同様、若い頃は便利だなあと思ってた。
よし、一念発起してSexMaster作るか ここまで、>>851がダメな理由を明確に説明できる奴皆無 >>858
メンテが必要でSQLで手動更新しないなら画面用意する他ないな
Railsのようなのでscaffoldでサクサク作るか
metadata用のAPI使ってOTLTと同じような共通汎用メンテ画面を作るか >>861
そういうスレだしな。
でも根拠なしにテキトーなこと言ってるだけの奴は「ググれ」「自分で考えろ」とかいってごまかす。 >>862
記事に欠点が列挙されてるんだがそれは読んだのか? メリットデメリット併記されていて、少なくとも「100%やめたほうがいい」なんて断言はしてないと思うが それはミック氏の考え方だからな
SQLには詳しいけどDB設計に詳しい人ではないから 一番大きな欠点は参照整合性を担保できなくなる点
記事にメリットとしてあげられてる点も鵜呑みにせず本当かどうか考えたほうがいい じゃあ皆さんの設計する社員マスタはセックスマスターを参照しているんですか? >>866
正確に言うと、件のマスターの主キーが複合主キーになるから参照整合性制約をかけようとするなら
面倒くさい&無駄ってことだね。
それを必要としない用途で使う分には問題ないかもしれない。 >>868
そう
担保するためには複合主キー+チェック制約がいるので
OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
参照する側が取りうる値の範囲を参照制約以外で担保する前提で
異なるコード体系じゃなく統一されたコード体系のテーブルなら
DB設計的にも有りだけどそれはもうOTLTじゃない それOTLTとか関係なく複合主キーの問題なんじゃね そもそも
> OTLTを1つ参照するたびに2カラム必要になってヒドイことになる
とか感覚で語ってる奴の相手しなくていいかと これだけ解説してもらってもわからないってどういうことよ >>869
1:男←性別
2:女
3:北海道←ここから都道府県
4:青森
...
80:赤←ここから色
81:青
みたいに管理するってこと? そもそもOTLTを検討するようなデータは制約をつけるようなデータは管理しないのでは
自分が設計したDBは可変特にユーザーが何か設定するようなデータは必ずマスタとして登録してたわ
何でもかんでも使うのは乱暴だけど純粋にシステムとして値と内容だけで完結するようなデータであればありだと思う >>874
よくわからん
必ずマスタとして登録って、つまりOTLT的なマスタのこと? みんなあーだこーだ言うだけで
セックスマスター持ってるかどうかまでは言及しないな >>873
それは統一されたコード体系で扱えるデータじゃないからすぐ破綻すると思うが
データ構造だけで言えば下のように管理して特定の値はIDのみで引けるようにしておくイメージ
表示の多言語対応なんかで使う
ID:カテゴリ:表示名
1:性別:男
2:性別:女
3:都道府県:北海道
4:都道府県:青森
...
80:色:赤
81:色:青 性別はわざわざ参照テーブルを用意するほどじゃないことが多い
作る場合はgenderテーブル 性別には、「未回答」、「回答拒否」って場合もあるんだろうか >>881
うちは男性、女性、不明で管理してるけど
この手の区分は全てドキュメントの辞書管理してるだけでわざわざテーブルに登録してない 100万件の会員データcsvで出力してください
性別は名称付きでってなったらどうするの? >>883
case で名前に変換すりゃいいだけじゃね むむ、じゃあ今日だけ、男じゃなくて雄でだしてほしいんだよな〜って言われたらどうするの データがあればいくらでも出力できるだろ
生年月日は和暦でお願いといっしょでここでする話じゃない >>885
今日だけSQL書き換えればいいだけでしょ
アドホックな要求ならそれで充分 >>888
保守性が低い
あなたの会社は毎回sql書き換えてリリースされるのですか アドホックに表示名を変更するためだけに
マスタを変更するほうが保守性が低い 性別はともかくどこまでマスタ管理するかだよなあ
令和のために元々管理していなかった元号をマスタ管理するようになったところは多いと思う 保険会社みたいに性別が重要な情報で
それを含む会員データをいろんな用途で使うなら間違いなく性別マスターを作る
でも今回発送するDMに限っては”男性”じゃなく”♂”で表示したいとなっても
性別マスターを更新して対応したりはしない
アドホックに表示をカスタマイズしたいという要望が
恒常的に発生してシステム化が必要な場合は
カノニカルな表記とは別にマッピング機能を追加する >>890
アドホックの意味わかる?
まあ100万件超えないならExcelにエクスポートして置換でもいいかもな >>891
保守性と言うかどこで使われてるかわからんマスタの変更なんて簡単にできないよね
本当にいろいろな表示の仕方が恒常的に要求されるならマスタに表示用の列を複数持つわ
id|表示名1|表示名2|表示名3|…
1|男|♂|雄|…
2|女|♀|雌|… アドホック(ad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句である。
ラテン語はわからないです… >>896
「今日だけ絵文字で表示したいんですけど〜」
「じゃ、お列追加しときますね〜」 >>899
日本語理解できないのか?
> "恒常的" に要求されるならマスタに表示用の列を複数持つ
今日だけの話ならcaseでも専用の表示マスタでも好きにやってくれ 恒常的に要求されてもこのケースは列持ちすべきじゃない DB設計もしたことない奴が書き込んでるだから無視したほうがいいぞ
俺の中では851なんて全体で合意をとればいい話でどっちだってかまわないと思ってる話題
ただ値(ID、コード)にAは数値、Bは文字と意味を持たせたいなら別管理したほうがストレスはないと思う >>903
id|表示名1|表示名2|表示名3|表示名4|表示名5|表示名6|表示名7|表示名8|…
↑こういう設計見たらどうするの? 扱うシステムの規模にもよるだろうが、大量に名称マスタが必要なシステムだと方向性間違えると辛いことになる
マスタを全て分けると必要最低限の管理画面が必要。その開発工数がバカにならない。
上でも挙がっているが
Rubyのスキャフォールドは便利だが、大規模システムで動的型付け言語は別の点でやばくなる。
asp.net mvcのスキャフォールドはrubyのパクリだが静的型付けなのでまだマシ。
これらに限らず最近のフレームワークは似たような構築機能があるだろう。
加えてシステムの変更に強い。
この名称マスタだけカラムを追加したいみたいなことに対応しやすい。
小規模で変更がないシステムであれば…名称マスタも少ないだろからやっぱりちゃんとマスタ作ったほうがいいんじゃない? >>904
いいんじゃないの?
表示名nみたいな名前はどうかと思うけど
で、>>903の回答は? セックスマスター作る派のやつは、セックスマスターメンテナンス画面もつくるのか? "ぼくのかんがえた最強のセックスマスター"が瞬殺されて涙目の素人さんwww >>909
そういうゴタクはよりマシなセックスマスター提示してから言わないと恥ずかしいだけやでww セックスマスター作らない人は
TO_DOU_FU_KEN_MASTERも作らないの? >>905
マスタを分けてもテーブルの構造に応じて
メンテ画面の内容が変わるようなのを1つ作っとけばいいだけでしょ
異なるコード体系を1カラムに詰め込むのはC#でdynamic typeを使うようなもの >>907
都道府県マスターと同じでメンテ画面は必要ないことのほうが多い >>914
異なるコード体系を1カラムに突っ込むなんて書いてないつもりなんだが。
んで、そういう動的に画面生成されるようなやつってどうなんだろ
動的にsql組み立てることになって結局メンテナンスしづらくなると思う。 表示を日本語でするか英語でするかを、
使用するユーザーが決める
それと同じように作ればいい >>916
>加えてシステムの変更に強い。
>この名称マスタだけカラムを追加したいみたいなことに対応しやすい。
じゃ”この名称マスタ”ってどういう構造を想定して言ってるの? >>917
それをRDBでやる方法がよくわからないからOTLTみたいなものになってるんだろうね わかってるやつは話題にはいってこない内容だし
バカが話を脱線させるから851みたいな話はおわらないw >>918
おれはOTLTじゃなくて
性別マスタ、都道府県マスタで別に管理しましょう派だよ?
たとえば都道府県マスタに名産物列を追加しましょう。
メンテナンス画面はめんどくさいけどちまちま直しましょう。
ってこと。 コードと名称以外の属性持つ前提ならOTLTなんて考えないのでは
OTLTを前提にするならコードと名称以外の属性はもたないでしょ >>922
そんな前提はすぐ崩れる
ソフトウェアには変更がつきもの >>923
もともとの要件にない話なら問題外
開発中の変更であれば別テーブルに変更すればいいだけ
そもそもコードと名称しか管理しない前提の都道府県情報に
名産物なんて項目を増やすようなシステムなら最初から別テーブルになるし
そんなこと言い出したらOTLT禁止の前提でシステム(DB)設計してると思うわ
こういう話はごねたいだけの話題にしかならんね >>916
>動的にsql組み立てることになって結局メンテナンスしづらくなると思う。
動的sql的なものは使わざるをえないけどORM使えば全然大変じゃない >>925
だから禁止っつうかOTLT使うなって言ってるつーの >>926
そんなORMあるか…?
そのobjectの型定義はどうなってるんだ?
AcriveRecord? >>927
0なし
1あり
しか持たない〇〇テーブルたくさん持つの? >>929
他の人も書いてるように、メンテナンスが発生しない&コードが少ないのであれば
メモリ内に持つ
意外とOTLT派が多いね
自分も大昔使っていたが、害の方が多いという印象。 >意外とOTLT派が多いね
「OTLT派」ってほど積極的に肯定している人はいないんじゃないかな。
ダメな理由がないなら使ってもいいじゃん、程度だと思うけどね。
>自分も大昔使っていたが、害の方が多いという印象。
その「害」を具体的に挙げたら建設的な議論になると思う。
ひとつは上で参照制約の話が挙げられていたが。 こんな害
レコードが増えすぎると性能に影響が出る。そんな大量に突っ込むなよってはなしだが、使い所を分かってない人間はなんでも入れてくる。
変更に強いようで弱い。汎用性を意識して予備カラムみたいなのを用意するが結局足りなかったり、数値型と言ってもintとnumber、日付も時間まで持つかどうかで変わる。
型は厳密に。null非許容にできないのも痛い。
汎用性を重視するあまりカラム名が曖昧になる(なんとか1,2,3)
名前が適当だと後でわからなくなる。
それぞれにViewを定義したりして誤魔化してきたけど、使い所を誤る人がどうしても出てくるのだ。 ありがとう。
そうやって具体的に挙げてもらえたら、あとは自分の案件にとってそれが
「害」になるのかどうか判断すりゃいいだけだね。 >>928
ActiveRecordにしろEFにしろORM経由でテーブルを扱うタイミングでは
ORMがテーブルの型を認識できてる必要はあるよ
Rubyなら動的に型定義可能なので
実行時に汎用メンテ画面で扱うテーブル一覧をDBから読み込んで
それ用のclassを定義したらActiveRecordで扱える
C#でも動的に型定義できるけどちょっと面倒くさいので
テーブルを新規に追加した時はスキャフォールドして型定義をプログラムに追加しとけばいい
テーブル名を変数で渡されたらリフレクションで型にすればあとは普通に使える >>934
スキャフォールドって
モデルからViewとコントローラーのコードが生成されるけど
それぞれモデル名が頭につくから
SexControllerみたいになるよね
それにテーブル名渡すの?
urlがapi/v1/Sex/Index?table=sexみたいになるのかな?
で、EFは使わず、動的にsqlを組み立てるってこと?
なかなか強引だな。 >>932
これ書いといてなんだけど、同じデータベースの構成でいろんなお客さんにシステム導入しようとするとEAVの問題が出てくるんだよな
で、xmlやjsonを列に突っ込んでる
型を厳密にと言っときながら厳密でない型の列を定義してる俺を罵ってくれ 別に同業他社の人に評価してもらうのではなく使ってもらうユーザーに評価してもらってOKならそれでよくね?
誰が見ても使っても満点の設計なんてできない以上それでかまわないと思うけど >>935
ビューやコントローラを生成する必要はないから
モデルファーストでテーブルを追加/更新するならそのモデル定義をプログラムに追加するだけ
スキャフォールドって言ったのはデータベースの定義を読んでEFで扱えるようにするための話
> dotnet ef dbcontext scaffold --table Hoge >>939
ViewContoroller使わないのは納得した。
渡したテーブル名はどこで使うの?
pocoで定義されたクラスに値入れて、addしてsavechanges
てのがEFの普通の流れだけど
そのクラス名はhogeだよね
そのクラス名が動的に変わる? >>921
この手のほぼ更新のないマスタテーブルはDB管理者がsqlでメンテだな >>940
リフレクション使うんだよ
カラム名やデータ型を共通化できるなら
リフレクションじゃなくジェネリックでも対応可 >>1000
日本人はカス民族。世界で尊敬される日本人は大嘘。
日本人は正体がバレないのを良い事にネット上で好き放題書く卑怯な民族。
日本人の職場はパワハラやセクハラ大好き。 学校はイジメが大好き。
日本人は同じ日本人やアジア人には厳しく白人には甘い情け無い民族。
日本人は中国人や朝鮮人に対する差別を正当化する。差別を正義だと思ってる。
日本人は絶対的な正義で弱者や個人を叩く。日本人は集団イジメも正当化する。
日本の芸能人は人の悪口で笑いを取る。視聴者もそれで笑う民族性。
日本人はコロナ感染者を一方的に差別し叩く。感染する奴が悪い主義の民族。
日本人は犯罪者の死刑拷問大好き。でもネットに書くだけで実行は他人任せ前提。
日本人は己の手は汚さない。
日本人は鯨やイルカを殺戮して何が悪いと開き直るが猫や犬には虐待する事すら許さない動物差別主義的民族。
日本人は「外国も同じだ」と言い訳するが文化依存症候群の日本人限定の対人恐怖症が有るので日本人だけカスな民族性なのは明らか。
世界中で日本語表記のHikikomori(引きこもり)Karoshi(過労死)Taijin kyofushoは日本人による陰湿な日本社会ならでは。
世界で日本人だけ異様に海外の反応が大好き。人の顔色を伺う媚びへつらう民族性。
世界幸福度ランキング先進国の中で日本だけダントツ最下位。欧米は上位。
もう一度言う「外国も一緒」は通用しない。日本人だけがカス。カス民族なのは日本人だけ.
陰湿な同級生、陰湿な身内、陰湿な同僚、陰湿なネットユーザー、他者を見下すのが生き甲斐の国民達。
こんなカス民族によるカス国家滅びたってどうでも良いし愛国心を持つ価値も無い。 カス民族日本でも世界の上位にいるんだよね
カスの日本人より なんでこんなに
いろんな仕組みが発達したのに
いまだにDBのデッドロックの回避チェックを
人間が人力でやらんといかんのだ SQLだけ抽出すれば簡単だろうけど
呼び出し側のコードも含めて解析するとなると面倒くさいわな
普通に設計すればデッドロックで困ることなんてないからニーズもない ある一つの商品(例えば動画とか)に現物の商品とDL商品と言うように、種類が二つないし複数ある場合
products
- id
- name
- description
product_classes
- id
- product_id
- type
- price
こんな設計でよろしいのでしょうか?
今まで1商品1レコードの単純なものしか扱った事がなかったので、こう言った場合のセオリーがわかりません
よろしければご教授下さい なんとなく想像はつくけど、設計を語るのであれば最低限ユニークキー、外部キーとかは示した方がいい。 >>948
種類の軸が1つだけで固定的なら基本的にはそれでいいと思う
2つのテーブルの関係は1対多の親子関係(親が存在しないと子も存在しない)なので
product_id + typeの複合主キーにするか
id付与してproduct+id + typeはユニークかつNOT NULLにするか
あとは
商品単位で管理する項目
派生商品単位で管理する項目
現物のみ・DLのみで管理する項目
を精査してモデルを調整する
種類の軸が複数ある(複数になる確率が高そう)なら
それをモデルに取り込んでいく必要がある
classはカテゴリに近い概念に使われるのでやめたほうがいい
英語ならproduct, product_variantが定番 >>950
質問する前に調べていた所 EC-CUBEが、dtb_product, dtb_product_class と言う関係のようだったので、product_classes としましたが、正直自分も違和感があったので、product_variant採用させていただきます
主キーやユニークなども適宜設定していきたいと思います
丁寧な回答ありがとう御座いました 初歩的な質問なのですが、テーブルを作成する際は以下のdata列のように数字と文字のように見た時に意味合いが違うデータは同じカラムにするべきではないでしょうか?(id=int型、data=string型)
文字列扱いの列とはいえ、センサONを1,0で表して数値型の列として扱ったほうが適切なのでしょうか?
Id | data |
--------------
1 | 120 |
--------------
2 | 55 |
--------------
3 | センサON | >>952
そのテーブルやdata列の意図・目的と
CREATE/UPDATE側・READ側でそれぞれどういう風に使うのかによる
アプリケーション全体の設定値を1テーブルに格納するようなケースで
型を揃えられないような場合は文字列で保存して読み取り側で変換する方法はそれなりに使われてる
(設定ファイルと同じ) 知ってて基本は信用できないんだよなあ
Q「DB使えますか?」
できる人「(論理設計やSQLなどの基本的なレベルでは)扱えます」
できない人「(接続先情報指定したら他のことは大体やってくれるORマッパーライブラリがやってくれるから)扱えます」
これを客観的に揃えてくれるのが資格。
凄い人だなとは見られないけど、しょうもない人ではないと安心してもらえる要素として有用
経歴の説明だけで嘘八百じゃないと信じてもらえるコミュ力の人にとっては無用かもしれない >>954
>Q「DB使えますか?」
質問がアホなので回答もアホになる
できる人は「使えますか?」の意図や定義を確認しようとする質問で返すか
自分でそれを補完して共通認識を明確しやすい回答をする
質問の意図を確認する質問をする人は
盲目的に回答する人に比べてできる人材である確率が飛躍的に高い とある開発チームはメンバー全員がオラクルのシルバーかゴールド持ってたけど論理設計ができる人は一人もいなかった
Javaのシルバーかゴールドも全員持ってたけどオブジェクト指向的な設計がまともにできる人も一人もいなかった
一般的な資格はできる・できないの指標ではなく最低限の表面的な座学知識を持ってるかどうかの指標 このスレでまともに論理設計できそうなやつ見たことない そもそもオラクルマスターの試験科目に論理設計なんてあるのか? Oracleに必要なのは論理設計よりインフラ側の知識じゃないのかね
広い知識は必要なことが多いけどDB屋は何でも屋じゃないからな 適当な知識ででたらめ言ってるだけだろ
かわいそうなやつ 使える、扱える、試験科目、インフラ側
用語の定義を軽視する人は論理設計に向かない DBの論理設計に限らず設計能力を測れるような資格は聞いたことがないな
もしあるならぜひ知りたい 仕事場では姑のようにうるさい職なのに
不必要なところまで偏狭な思想を持ち込むと煙たがられるぞ 要求/要件を正しく設計に落とし込む能力ならとりあえずテクニカルエンジニア(DB)でいいんじゃね? データベーススペシャリスト試験で設計能力は全く測れないよ
高度試験合格してると「お勉強よく頑張ったんですね」って評価はできる そもそも、そこで言っている「設計能力」ってどういうものを指しているんだろう。
まさかER図を奇麗に描く能力とかじゃないだろうが。 >>970
設計に必要な最低限の知識を持っていることくらいはわかるだろう。
少なくともリレーションの正規化も知らないような箸にも棒にもかからないような奴は弾ける。
>>956のような面接での数回の質問よりはあてにできるんじゃないかねぇ。 〇〇が測れないから資格なんて無駄!
って資格も取れない奴の捨てゼリフだろw
資格なんて>>973が言うように最低限の読み書きレベルの保証でしかない ■■■ ほしのあすかちゃん 無茶苦茶可愛い!!! ■■■
■■■ 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 ■■■
いやぁ、ブルマ姿の女の子って、すごくいいもんですね。
お尻に砂がついてても気にせずにはしゃぎまわる子、
ブルマから下着がはみ出ていても気づかずに元気よく走り回る子、
ブルマに下着のラインが浮き出ていても元気よく動き回る子など、
魅力的な女の子たちの画像が満載となっています。
画像の中には既出や重複がある場合があることをご了承ください。
今夜はブルマ姿の女の子たちを遅くまでごゆっくりとご鑑賞ください。
では、また! この中のどれくらいの人がIPAのデータベーススペシャリスト合格者なのかね。 データベーススペシャリストでも実体験がはるかに多くないと変な設計になる。 ちゃんとした知識を身に着けないで見よう見まねで実務経験を積んできたようなのの方が
考え方が偏った変な設計になっている気がする。 それは偏見。いろんな設計を見ていきてないやつだと確かにそうなるが。 だからそのいろんな設計に対応できる知識や能力を問うのが試験であって、そのための勉強をするわけだが。
実務でたまたま出会える設計なんて限られたものだろう。 合否は別として、レスを拝見するに真っ当な見識をお持ちの方が多そう。 エンジニアでは無いながら、この度スペシャリスト試験受けることになり、勉強する内にデータベースの魅力に気付いてしまった。そして、とうとうプロの巣窟であるこのスレに辿り着いたというわけさ。 >>981
>いろんな設計に対応できる知識や能力を問うのが試験
なんてものが存在すればいいんだけどね
少なくともデータベーススペシャリストの試験ではそんなものは問われない >>986
そこに書いてる内容が全て試験で問われるわけじゃないんだよ
実務を知らないのかそれとも試験内容を知らないのか 正規化が設計だと思ってるやついるからな
設計能力を問う試験 == 「これは第何正規形か?」 実務では制約をガチガチに付けてデータが入らないようにして、それは私の仕事ではありませんと言い、自分の仕事を減らすクソがいるからな。
データベーススペシャリストやオラクルマスターの一部はこうなりやすい。 >データベーススペシャリストやオラクルマスターの一部はこうなりやすい。
相当なルサンチマンがあるようでw 物理設計は実務やってないと感覚的に理解するの難しいのだろうか。。 >>990
データベース板でそう主張するやつがいるんだよ! >>991
物理設計はベンダー資格はある程度役に立つ
論理設計は資格試験は全くといっていいほど役に立たない >>995
なるほど。。当方は非エンジニアなんだけども今後、データベース領域の人達と交じるにあたり、データベーススペシャリスト受けようと思ってるのよね。上で誰かも言っていたし、他の多くの試験と同様、最低限の共通言語を持っていると捉えてくれるだろうと期待して。 相手の知識量を見積もりながら会話するの非効率だろうから。。 試験通ってデータベーススペシャルになるんや!(´・ω・`) このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 1559日 18時間 58分 6秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。