笑った 0311NAME IS NULL2023/07/23(日) 21:48:47.24ID:lgEmBl7h 個人番号を自分たちで作っているなら主キーになるものがあってもいい 0312NAME IS NULL2023/07/23(日) 21:50:06.71ID:??? >マイナンバーに紐付くべき情報を保持するテーブルでマイナンバーをキーにするのは何もおかしなことはない。
漏洩したマイナンバーをハッカーがRDBで管理するのに マイナンバーをプライマリキーにするみたいな非合法な用途なら何もおかしくないんだが 合法な用途だとマイナンバーをプライマリキーにしたいテーブル自体がまず存在しない 一番近いのは失効リストだけどそれもマイナンバーをプライマリキーにはしない 0313NAME IS NULL2023/07/23(日) 21:56:41.72ID:??? 同姓同名の人がいるような住所録で、マイナンバーをキーにして区別する何て使い方はないんだろうか (ふと思いつきw) 0314NAME IS NULL2023/07/23(日) 22:16:01.72ID:???>>308 プライマリキーと候補キーに本質的な違いはないからね。 0315NAME IS NULL2023/07/23(日) 22:21:59.13ID:???>>312 >合法な用途だとマイナンバーをプライマリキーにしたいテーブル自体がまず存在しない
存在しないと言い切る理由がわからんな。 例えば、マイナンバーを発行した日付を記録する必要があったとしたらそのテーブルのキーは何にする? 0316NAME IS NULL2023/07/23(日) 22:40:55.09ID:???>>315 >例えば、マイナンバーを発行した日付を記録する必要があったとしたらそのテーブルのキーは何にする? マイナンバーを発行した日付を記録する必要があるのはマイナンバーを発行する機構だけなので 発行日付を記録するテーブルのキーはマイナンバー発行処理のID (発行処理のIDが発行依頼のIDから派生する可能性はある)
あと前提知識がわからないから書いておくけど マイナンバーの発行は市町村からの依頼を受けて地方公共団体情報システム機構が行うもので 現状の個人用マイナンバーはハッシュ関数に住民票コード11桁とソルト的なものを渡して生成した11桁と1桁のチェックディジットを足したもの マイナンバー変更時は同じ住民票コードからソルト的なものを変更して別のマイナンバーを生成する (住民票コードを変更してもマイナンバーは変更されないので番号間の紐付けはDB内のマッピングのみ) 0317NAME IS NULL2023/07/23(日) 22:51:44.11ID:??? >発行日付を記録するテーブルのキーはマイナンバー発行処理のID
マイナンバーからマイナンバー発行処理のIDを求めるのはどうするんだろう 0318NAME IS NULL2023/07/23(日) 23:07:44.19ID:???>>317 (発行処理ID, …, マイナンバー, …, 発行日付)
SELECT 発行処理ID FROM table WHERE マイナンバー = my_number 0319NAME IS NULL2023/07/23(日) 23:08:36.59ID:??? マイナンバー特有のシステム的な事情はともかくとして チェックディジットを含むような外部生成コードをPKにして許されるのはものすごく特殊な状況 値の更新やフォーマット変更時の影響範囲が大きくなりすぎるから
よく言われるISBNやJANコードをプライマリキーにする是非と同じ話 ものすごく短期間だけ使うDBだったり個人が趣味で使うDBだったり 一般的な業務システムに求められる信頼性や保守性が明らかに不要であれば別に構わない 0320NAME IS NULL2023/07/23(日) 23:20:17.23ID:???>>318 マイナンバーに対する発行処理IDを一意に保証するには結局マイナンバーを一意キーにするしかないが。 UNIQUE NOT NULL じゃなくてただの UNIQUE はプライマリキーと違うとか言っちゃう? 0321NAME IS NULL2023/07/23(日) 23:32:26.06ID:??? 普通に考えたらマイナンバーを主キーにしたら駄目だろう.. 外部IFする場面ではあると思うけどね 0322NAME IS NULL2023/07/23(日) 23:59:56.44ID:???>>320 関数従属性の方向が違う
んでUNIQUE NOT NULLでもプライマリキーとは違う 例えばマイナンバーの桁数が15桁に変更になって14桁部分での一意性を担保する仕様に変わった場合 マイナンバーがプライマリキーならテーブル全部作り直しで 外部キーとして参照してるテーブルもすべてデータ更新が必要 UNIQUE NOT NULLなカラムなら1テーブルだけ変更すればいい
UNIQUE NOT NULLなカラムを外部キーで使ってたら駄目だけど マイナンバーみたいなのではまずやらない 0323NAME IS NULL2023/07/24(月) 00:03:11.03ID:??? あと UNIQUE NOT NULLは更新可能 プライマリキーは更新不可(少なくともSQL標準では) 0324NAME IS NULL2023/07/24(月) 00:18:34.25ID:???>>313 法令で定められた事務以外でマイナンバーを利用するのは法律違反 マイナンバーを利用する事務に従事する人が勝手に目的外で利用してたら刑事罰 0325NAME IS NULL2023/07/24(月) 08:11:00.20ID:???>>322 >関数従属性の方向が違う
指定された期間の使われ方によってはもっと違うバリエーションがあるので これも結論はユースケース次第 0377NAME IS NULL2023/07/31(月) 02:21:45.92ID:???>>372 >「検索」や「整理」というのはキーとして用いることを想定しているように思えるが んなわけあるかw 0378NAME IS NULL2023/07/31(月) 07:23:47.10ID:???>>371 そこに期限がないことを示すならNULLが素直だが検索がやや面倒になるので 他に問題が起こらないならば開始日0000終了日9999という手もある。 0379NAME IS NULL2023/07/31(月) 08:08:15.76ID:???>>377 そんな断言できるものなのか? 0380NAME IS NULL2023/07/31(月) 10:36:33.09ID:???>>379 お前のキーの定義ゆるゆる過ぎるやろ そら議論にならんわ 03813712023/07/31(月) 15:18:31.82ID:??? みなさんアドバイスありがとうございます 範囲検索で必ずヒットさせたいので、 開始日(1000-01-01)、終了日(9999-12-31)のようにします そして表示上は「期間指定なし」とします こうすれば余計なカラムを追加せずに目的が実現できそうですね 0382NAME IS NULL2023/07/31(月) 15:32:40.41ID:??? 終了日に9999は使わない方が良いと思う 0383NAME IS NULL2023/07/31(月) 15:38:26.72ID:??? 終了日を指定しなければinfinite future扱いとするのはよくある話だけど 開始日を指定しなければinfinite past扱いとするのは聞いてことがないな 過去に遡らせる必要があることがないから 03843712023/07/31(月) 15:53:50.88ID:??? それではこういうのどうでしょう?(MySQLです)
SELECT *, IF (date_s IS NULL AND date_e IS NULL, 1, 2) AS is_unlimited FROM `posts` HAVING (date_s <= '2023-07-01' AND date_e >= '2023-07-31') OR is_unlimited=1
date_s(開始日)、date_e(終了日)がともにNULLならis_unlimited(無制限)が1にし、 そうでない場合は2にしてから、HAVINGの条件に加えるとか 0385NAME IS NULL2023/07/31(月) 15:59:51.42ID:MTLXqlZG>>381 文字データ型を想定しているなら、開始日は意味のある業務日付にして、設計書に明記しろ。 開始日の西暦1000年は、データを見ても誰も意図がわからない。こういうのは登録ミスなんじゃないのかと、未来、必ず言われる。 03863712023/07/31(月) 16:03:56.83ID:???>>385 なるほど。そこまで考えていませんでした。 じゃ、適当な数値よりもNULLの方がマシですかね。 で、「date_sとdate_eがともにNULLなら期間指定なしとする」」 と設計書に明記すれば迷わない気がします。 0387NAME IS NULL2023/07/31(月) 16:05:18.32ID:MTLXqlZG>>384 開始日と終了日が必要なデータとそうでないデータがあるなら、複数データを同じ入れ物に入れようとしているアンチ正規化のちょっとよろしくない設計なんだが? 03883712023/07/31(月) 16:08:46.81ID:???>>387 ということは、>>371で書いたA案が正しいのですかね? B案という意見も多いので、どっちが良いのかわからなくなります 0389NAME IS NULL2023/07/31(月) 16:39:20.99ID:??? どの程度の件数が格納されるか不明だけど検索項目になるなら自分ならNULLは許可しない DB上の期間指定なしと入力可能な期間指定を明確に決めて設計するかな DB上開始指定なしは0000-01-01、終了指定なしは9999-12-31、入力可能な期間指定は開始は2000-01-01、終了は2999-12-31など 0390NAME IS NULL2023/07/31(月) 16:53:35.14ID:??? 開始指定なしはビジネスロジック上不明またはメンテ期間以前ってことだろ 前者ならNULLでもいいんじゃないか 3値論理の理想としてる設計だろ 0391NAME IS NULL2023/07/31(月) 16:55:12.55ID:??? 検索項目にする場合、NULLだと都合が悪いのかな 0392NAME IS NULL2023/07/31(月) 17:05:41.13ID:??? 開始終了の日付指定無し=両方NULLを設定する 片方だけNULLは都合が悪い=入力時にチェックするで対応 日付範囲指定で抽出=範囲指定で、NULLデータは検索から排除されてる
これで上手く動くと思うけど、ダメなのかな? 0393NAME IS NULL2023/07/31(月) 18:32:11.87ID:???>>392 テーブル上のケースは A 開始:終了 開始~終了 B 開始:NULL 開始~ C NULL:終了 ~終了 D NULL:NULL 期間なし 例えば日付範囲検索で 開始日以降の条件が発生した場合、開始≦条件の開始日 OR 開始 IS NULL 終了日以前の条件が発生した場合、終了≧条件の終了日 OR 終了 IS NULL とそれぞれNULLの考慮が必要になるからNULLを持たないほうがいいんじゃない? というのが自分の考えだわ 後は例えば開始が2023-01-01、終了が2023-12-31となっているデータがある場合に 2022-12-01~2023-03-31って検索した場合、上のデータが対象になるとNULLが混在するデータの場合に 条件も複雑にならないかね? 0394NAME IS NULL2023/07/31(月) 18:34:05.22ID:??? 質問した人が果たしてそこまで要求してたかどうかは、あやしい 0395NAME IS NULL2023/07/31(月) 21:00:40.56ID:??? そういう意味でテーブルに開始・終了日付を持ち、検索時も開始・終了日付を持つ場合を考慮してNULLはないほうがいいと思ってる 0396NAME IS NULL2023/07/31(月) 21:33:37.76ID:??? DBにもよるけど検索時のIndexも効かないし 俺ならNULL使わないかな 3000万件から無期限のデータだけ取り出したい場合とかINDEX効かせないと辛いやろ 0397NAME IS NULL2023/07/31(月) 21:38:44.77ID:??? 3000万件ですか?すごい大規模な案件ですね そういうのを担当する人が果たしてここで質問するか、 大変興味があります 0398NAME IS NULL2023/07/31(月) 21:52:32.04ID:??? ・NULLは駄目 ・1000-01-01〜9999-12-31のような最小、最大値を入れるのも駄目 ・フラグ用のカラムを入れるのも駄目
ならどう設計するのが適切なの? 0399NAME IS NULL2023/07/31(月) 22:06:34.28ID:??? 絶対にどれがダメなんてことはなくてそれぞれメリットデメリットあるからそれを踏まえて判断すればいい。 条件に関わらず「××は絶対ダメ」という奴がいるかもしれないがそういうのはバカだから無視していい。 0400NAME IS NULL2023/07/31(月) 22:08:57.28ID:???>>396 >3000万件から無期限のデータだけ取り出したい場合 なんでそんなことしたいの? 3000万件から他のインデックス使わずに無期限のデータだけ取り出したい場合があるなら 無期限のデータと有期限のデータは根本的に種類が違うんじゃないの? 0401NAME IS NULL2023/07/31(月) 22:19:05.56ID:???>>396 期限有り無しの二値だとインデックスも効きにくいだろ。よっぽど分布が偏ってない限り。 ビットマップインデックスもこの場合はちょっと違うしなあ。 0402NAME IS NULL2023/07/31(月) 22:33:24.14ID:??? 二値しかないんだから、アクセス時間の方がかかる インデックスあまり意味がない 0403NAME IS NULL2023/07/31(月) 22:40:21.82ID:???>>401 インデックスをどうするか以前に 期限の有無が業務上持つ意味をDB設計に反映できてない可能性があるのではという話
よくあるのは通常の単価とキャンペーン単価の管理の違い 前者は開始日(=切替日)しかないが後者は開始日と終了日がある 0404NAME IS NULL2023/07/31(月) 22:56:02.47ID:??? 本人がいないところで仕様を膨らますのは止めよう 0405NAME IS NULL2023/07/31(月) 23:07:24.63ID:???>>396 >DBにもよるけど検索時のIndexも効かないし オラクルだけじゃなくて? 0406NAME IS NULL2023/07/31(月) 23:14:10.03ID:??? オラクルでも今はNULLをIndexされるようにできるみたいね 0407NAME IS NULL2023/07/31(月) 23:16:19.49ID:??? SQLiteは知らないけど SQL Server, MySQL, PostgresはどれもNULLがIndexingされるので Oracleも大丈夫なら検索性能という意味ではあまり困らないような気がする 0408NAME IS NULL2023/08/01(火) 00:07:30.45ID:??? 最近はOracleでもインデックスに含まれるのか知らなかったww勉強不足で申し訳ない
ただBTREE INDEXは魔法じゃないから データ分布とか検索条件次第ですかね 0409NAME IS NULL2023/08/01(火) 08:13:04.34ID:???>>403 そういうキャンペーン単価を管理するときって、別テーブルにするの?
▽商品テーブル ID|商品名|価格|登録日|更新日
▽キャンペーンテーブル ID|商品ID|キャンペーン価格|開始日|終了日
こんな感じ? でもこれだと商品にキャンペーンがあるかわからないような気が 0410NAME IS NULL2023/08/01(火) 09:06:38.95ID:??? 単価関連は標準単価とは別にキャンペーン用の単価を登録するテーブルを用意したりするんじゃない 0411NAME IS NULL2023/08/01(火) 09:39:35.55ID:??? キャンペーンの設計でいつも迷うのが履歴なんだよな キャンペーン終了したからって削除すると、購入履歴がおかしくなるし 0412NAME IS NULL2023/08/01(火) 10:55:49.31ID:??? 削除前提の設計なら履歴に削除するマスタの情報を付与しておけばいいんじゃない でも普通というか使用されたマスタは削除なんてしないのでは 0413NAME IS NULL2023/08/01(火) 11:07:21.76ID:??? 購入履歴は購入した各ユーザーの履歴として保存すれば良い 0414NAME IS NULL2023/08/01(火) 17:37:59.06ID:??? その履歴が何の履歴でどういう目的で残すものなのかを明らかにすれば設計はおのずと決まると思うが。 0415NAME IS NULL2023/08/01(火) 22:27:22.34ID:???>>409 扱う商品や業種にもよるとおもうけど販売単価は頻繁に変更される場合は 商品名とかを管理する商品マスターには実際の販売単価は入れずに別にテーブルを作る さらにそれとは別にキャンペーン用の単価を管理するテーブルを作る (標準販売単価のような商品IDが決まれば一意に決まるような情報なら商品マスター)
適用される単価を割り出すのに2つ以上のテーブルを確認するというのはアプリロジック
>▽商品テーブル >ID|商品名|価格|登録日|更新日 この設計だと価格を変更したい場合に価格を直接上書きするか商品IDを新しくするかしかなくて普通は困ると思う 0416NAME IS NULL2023/08/01(火) 23:26:21.41ID:??? 開始日・終了日の件は SQL標準に組み込まれたtemporal機能のsystem time periodsの実装方法を見ると 終了日だけオープンにしてdatetime型の最大値をセンティネルとして使ってるDBMSが大半のようなので RDBMS固有の特別事情がなければそれがファーストチョイスでいい気がする 0417NAME IS NULL2023/08/02(水) 00:55:16.14ID:???>>415 >>ID|商品名|価格|登録日|更新日 >この設計だと価格を変更したい場合に価格を直接上書きするか商品IDを新しくするかしかなくて普通は困ると思う キャンペーンテーブルのほうに引きずられたけどよく考えたら ID+更新日の複合主キーかそのサロゲートを使えば要件次第では困らないかもね 0418NAME IS NULL2023/08/02(水) 13:16:59.94ID:??? 価格は適用日に応じた世代を持たせたテーブル作ると楽 0419NAME IS NULL2023/08/02(水) 13:32:20.34ID:??? 適用日に応じた世代とかイミフw 0420NAME IS NULL2023/08/02(水) 13:38:56.67ID:??? 実務やってれば分かることなのに 0421NAME IS NULL2023/08/02(水) 14:57:10.42ID:???>>418 それはみんなわかってて 具体的にどういうやり方がいいのかという話だろ 0422NAME IS NULL2023/08/02(水) 16:07:55.30ID:??? 販売管理の実務やってる奴なんて実際いないんだろ いるなら具体例出すだろうしでないのが何よりの証拠 0423NAME IS NULL2023/08/02(水) 16:15:58.25ID:??? 適用日があるなら世代はいらないんじゃねって話かね? 0424NAME IS NULL2023/08/03(木) 09:58:26.73ID:??? そもそも適用時に応じて世代ってなんぞ? 0425NAME IS NULL2023/08/03(木) 10:00:46.36ID:??? ごめん、思い切りミスった 「適用日に応じた世代ってなんぞ?」だったw
価格が変わる毎にテーブル作るのは非効率に感じるし、 SELECTのSQLがどうなるかわからん 0426NAME IS NULL2023/08/03(木) 10:26:49.29ID:??? 世代番号列を作るってことじゃないの? 必要になるシーンが浮かばないけど 0427NAME IS NULL2023/08/03(木) 11:34:09.40ID:??? ある商品Aがある。通常の単価は100円 10/5は特売日なので80円、それとは別に10/11~15は90円 みたいなケースだと 10/1~4 100円 10/5 80円 10/6~10 100円 10/11~15 90円 10/16~ 100円 みたいになるけどそれぞれの期間を世代とかいってるのか100円でないものだけ世代とか言ってるか意味不明なんだよな 単純に適用日で管理といえばいいと思ってる 0428NAME IS NULL2023/08/03(木) 11:50:48.91ID:??? 後者を世代と言ってるなら要件定義ミスの原因になりかねないほど日本語が不自由だし、前者でも後者でもやはりいらない。 0429NAME IS NULL2023/08/03(木) 13:16:26.10ID:??? 価格テーブル作って ID、価格、開始日、終了日 にしたら世代管理にならないか?って思ったら、>>409に書かれてたw
ほんと言うだけ言って具体例出さないよな 0430NAME IS NULL2023/08/03(木) 15:29:58.52ID:dzanpAeV NULLのカラムを検索結果から除外するSQLなら、そもそもインデックススキャンになるSQLならインデックススキャンになるだろw 0431NAME IS NULL2023/08/03(木) 15:33:17.05ID:dzanpAeV だいたい日付の開始日が設定されていないような状態なら、他のステータス項目で判断できるようなデータモデルじゃないと、クソみたいなSQLだらけになる。 0432NAME IS NULL2023/08/03(木) 15:41:34.40ID:???>>428 それ俺の知ってる言葉の意味と違うから要件定義ミスになっちゃうという話にしか聞こえないぞ 一般的な意味とは違っても現場現場で定着してる語義ってあるからな 自分の知ってる意味と違うならそれを明確化させればいいだけ 0433NAME IS NULL2023/08/03(木) 15:43:58.47ID:???>>429 そういうのを「世代」や「世代管理」とは呼ばないというのが >>427-428の言いたいことなんじゃないかな 0434NAME IS NULL2023/08/03(木) 19:07:02.41ID:??? じゃ、その言いたいことを説明すればいいだけじゃん 他の人は例を出してるのになぜ出さない? 0435NAME IS NULL2023/08/03(木) 19:16:30.28ID:??? 言葉の問題とかどうでもいいから今回の価格の話だけすればいいと思うんだよな 0436NAME IS NULL2023/08/03(木) 21:23:42.18ID:???>>418がしょうもないこと言うから脱線したけど、元々の相談者の悩みは解決したんじゃないか 0437NAME IS NULL2023/08/03(木) 21:47:21.74ID:??? 夏休みだとこの程度なんだろうな 0438NAME IS NULL2023/08/03(木) 22:01:59.09ID:??? データベーススペシャリスト試験は国語力が試されるからそんなもんだろう。 問題文に書いてあることを読み落としたり逆に書いてない行間を読んだりしたら解けない。 0439NAME IS NULL2023/08/03(木) 22:12:43.51ID:??? 急にこういう訳わからん事言うのも夏休みだからかなw 0440NAME IS NULL2023/08/03(木) 22:25:05.03ID:??? 実務やってれば分かるって人は理論とか嫌いだしね 0441NAME IS NULL2023/08/03(木) 22:29:26.60ID:??? DBスペシャリストは実践的なDB設計には役立たないんだよ この1週間の一連の流れだけ見てもわかるよね 0442NAME IS NULL2023/08/03(木) 22:37:38.54ID:??? >この1週間の一連の流れだけ見てもわかるよね
KDD爺の「俺が正しい。根拠は言えないけど。」が多かったね。 実務やってりゃ分かる「世代」って結局何だったのか。 0443NAME IS NULL2023/08/03(木) 22:42:51.15ID:???>>440 リレーショナルセオリーだけじゃ主キーさえ選べない 0444NAME IS NULL2023/08/03(木) 22:49:53.56ID:???>>443 そりゃセオリーだけじゃどんなデータを格納するかすら決められないがそういうのとは違う話? 0445NAME IS NULL2023/08/03(木) 23:22:21.06ID:???>>441 >DBスペシャリストは実践的なDB設計には役立たないんだよ
試験受かった人が自分の設計力のなさを自虐しているのならわかるがそうでないならかなり恥ずかしいな。 0446NAME IS NULL2023/08/03(木) 23:25:47.44ID:gShiht3b NULLに何かしらの意味を定義するやつは永久に消えないんだろうな。
こんな経験豊富で含蓄のある開発者は中々ここに来てくれないし 0593NAME IS NULL2023/08/14(月) 19:58:39.76ID:???>>592 もう一回書くけど>>574の解釈じゃ納得いかないの?何を求めているのかよくわからんのだが。 0594NAME IS NULL2023/08/14(月) 20:10:32.70ID:???>>551の本人に聞きたいんですよ
小売業にも精通している人がどういう設計するのかにとっても興味があります どうやって履歴を辿るのとかどういう分析をするのとか、皆さんも興味あるでしょう 0595NAME IS NULL2023/08/14(月) 20:21:58.87ID:???>>594 >>574じゃだめなの?なんで本人じゃないとだめなの?そもそも何を疑問に思っているわけ? 0596NAME IS NULL2023/08/14(月) 20:23:27.26ID:??? で、>>554はいまだに意味が分からんからこっちはよろしく。
>3年毎にマスターのテーブル設計が変わる 0597NAME IS NULL2023/08/14(月) 21:07:09.32ID:??? つまんないなあ なんで本人出てこないの? と言うか、隠れてるの? 0598NAME IS NULL2023/08/14(月) 21:08:12.27ID:??? 最初の>>551が意味不明だから 判らないんじゃないかと思いますよ 0599NAME IS NULL2023/08/14(月) 21:10:38.93ID:??? >一般的にはずっとは保持しない >決められた保持期間をすぎれば古いものは整理する >店や商品によるけど一般的な小売ならだいたい3年は保持してる >改定後でも履歴の参照や分析用途に使う
こんな経験豊富で含蓄のある開発者は中々ここに来てくれないし 雑魚じゃ説明も無理 0600NAME IS NULL2023/08/14(月) 21:44:50.14ID:???>>565で突っ込まれた>>554が必死に話を逸らせようとしているように見えるが。
もう一度聞くがなんで>>551本人の回答じゃないと納得できないの? 興味があるだけなら>>574じゃ納得できない? >>574に反論があるなら俺が答えるよ。 0601NAME IS NULL2023/08/14(月) 21:52:10.43ID:??? 伸びてると思ったら一人で暴れてるだけだったw 0602NAME IS NULL2023/08/14(月) 21:52:42.58ID:??? 元元の話は、なんだったっけ? 0603NAME IS NULL2023/08/14(月) 21:53:13.72ID:??? >一般的にはずっとは保持しない >決められた保持期間をすぎれば古いものは整理する >店や商品によるけど一般的な小売ならだいたい3年は保持してる >改定後でも履歴の参照や分析用途に使う
こんな経験豊富で含蓄のある開発者は中々ここに来てくれないし 0604NAME IS NULL2023/08/14(月) 21:53:53.84ID:??? この話からそらしたい人がいるってだけでしょ 0605NAME IS NULL2023/08/14(月) 21:54:18.72ID:??? とりあえずこれがどういう設計を想定していたのか。
>3年毎にマスターのテーブル設計が変わる 0606NAME IS NULL2023/08/14(月) 21:54:39.52ID:??? こんな経験豊かな人の話なんて滅多に聞けないよ 0607NAME IS NULL2023/08/14(月) 21:55:34.95ID:??? まず言った本人の設計を聞かせてほしいね すごく経験豊かな人だよ 聞いても無駄じゃないと思うよ 0608NAME IS NULL2023/08/14(月) 21:57:21.48ID:???>>603 だから疑問があるならそれをちゃんとした質問にしてみなよ。 おれは>>574で問題ないと思うんだが何が疑問なのかわからん。 0609NAME IS NULL2023/08/14(月) 21:58:27.37ID:??? 私のような雑魚を問い詰めるより、
>>551 のような経験豊かな人の話の方がためになるよ 0610NAME IS NULL2023/08/14(月) 21:59:39.38ID:??? 経験豊かな本人の口から聞きたいです
何故本人に聞こうとしないのか、不思議 0611NAME IS NULL2023/08/14(月) 22:01:22.54ID:??? >一般的にはずっとは保持しない >決められた保持期間をすぎれば古いものは整理する
これどうやるか、他の人が説明できるんですか? 0612NAME IS NULL2023/08/14(月) 22:03:52.75ID:??? >経験豊かな本人の口から聞きたいです
もう駄々っ子だな。 じゃあ俺も自称経験豊かだから>>574と答えておくわ。それで満足か? 0613NAME IS NULL2023/08/14(月) 22:05:25.09ID:???>>611 保持期間を判断する方法さえあればそれ以上テーブル設計に影響する話じゃないと思うが。 0614NAME IS NULL2023/08/14(月) 22:07:18.46ID:??? どういう風な整理をするのか設計上重要だと思うんですけど 0615NAME IS NULL2023/08/14(月) 22:10:07.01ID:??? >店や商品によるけど一般的な小売ならだいたい3年は保持してる
実務上重要だという見解ですよ 3年という期間がどうして導かれたのかは分かりませんが 豊かな経験からでてきた言葉なんでしょう、きっと 0616NAME IS NULL2023/08/14(月) 22:10:55.61ID:???>>614 保持期限を過ぎたレコードを削除する、というのは思いつくが 懸念しているのはどういう問題? 0617NAME IS NULL2023/08/14(月) 22:13:30.68ID:???>>615 それが3年だろうと10年だろうと設計の上では大した違いはないと思うが そこにこだわる理由は? 0618NAME IS NULL2023/08/14(月) 22:13:57.63ID:??? だから、本人が説明してくれれば済むと思うんですが 0619NAME IS NULL2023/08/14(月) 22:14:46.26ID:??? 拘るというか、本人がそのようにおっしゃってますので 0620NAME IS NULL2023/08/14(月) 22:15:55.39ID:??? なんで本人の回答にこだわるの? 設計議論に俗人性は要らんだろう。ましてや匿名掲示板で。 0621NAME IS NULL2023/08/14(月) 22:18:00.09ID:??? しかも、3年で削除して良いわけではなく、 何かしらの判断を必要としている見たいですよ 「整理する」と言う以上、誰かが判断しているみたいですよね? 0622NAME IS NULL2023/08/14(月) 22:18:47.26ID:??? あのような発言をしたのだから、説明聞いても良いでしょう? 0623NAME IS NULL2023/08/14(月) 22:20:04.53ID:???>>619 3年の場合と10年の場合とで別の設計になるわけじゃないだろ。関係ないじゃん。 その数字が重要だと言っているのはあんた自身。それがなんで重要なのか本人のあんたが説明できる? 0624NAME IS NULL2023/08/14(月) 22:20:30.44ID:??? なんで聞いてはいけないのか、その説明をしてくれても良いですよ 専門技術板なんて、ほぼ特定の人物しか書いていないんだし 書いた本人が、今この場にいないとは思いませんけどね 0625NAME IS NULL2023/08/14(月) 22:21:48.01ID:??? >一般的な小売ならだいたい3年は保持してる
この発言見るだけで、実務経験が豊富なんだと判断できるでしょう 0626NAME IS NULL2023/08/14(月) 22:22:09.71ID:??? やっぱりこれ書いた本人がごまかそうとしているんだろうな。のらりくらりと。
>3年毎にマスターのテーブル設計が変わる 0627NAME IS NULL2023/08/14(月) 22:24:23.10ID:??? 整理するという中味が判らないと、それはなんとも言えませんよ 料金改定の度にマスターの項目は増えていくんでしょ? 違うの? 0628NAME IS NULL2023/08/14(月) 22:25:06.39ID:???>>624 >>551 本人がいつ戻ってくるかは知らんがまずは今ここにいる俺の質問>>623に答えてくれよ。 0629NAME IS NULL2023/08/14(月) 22:25:43.98ID:??? 本人の説明を受けてから、続けましょう 0630NAME IS NULL2023/08/14(月) 22:26:00.15ID:???>>627 そうそう、これ。 どういう設計を想定してるの? 0631NAME IS NULL2023/08/14(月) 22:26:18.29ID:??? この板は、大勢いるわけではないので、本人は今いると思いますよ 0632NAME IS NULL2023/08/14(月) 22:27:25.87ID:??? どういう設計しているのか、気になるので、是非本人から説明していただきましょう
>一般的にはずっとは保持しない >決められた保持期間をすぎれば古いものは整理する >店や商品によるけど一般的な小売ならだいたい3年は保持してる >改定後でも履歴の参照や分析用途に使う 0633NAME IS NULL2023/08/14(月) 22:28:26.36ID:??? 2,3人しかいないでしょ、いつも 0634NAME IS NULL2023/08/14(月) 22:28:50.70ID:???>>629 >>615本人がいるならその3年という数字が重要だと考える理由は答えられるわけじゃん。 0635NAME IS NULL2023/08/14(月) 22:30:05.41ID:??? それは、本人に聞いて下さい 豊富な経験から導き出した数字なんでしょ そういう書き方してますから 0636NAME IS NULL2023/08/14(月) 22:30:25.50ID:???>>632 その記述のどこから
>料金改定の度にマスターの項目は増えていくんでしょ?
という解釈になったんだか。 0637NAME IS NULL2023/08/14(月) 22:32:01.79ID:??? 雑魚の解釈なんです、どうでも良いことには拘らなくて良いですよ
経験豊富な本人の発言について、説明を求めています 0638NAME IS NULL2023/08/14(月) 22:38:17.21ID:??? 俺は経験豊富な本人の回答でなくてもかまわないから>>565や>636に答えてみてよ。 0639NAME IS NULL2023/08/14(月) 22:40:38.37ID:??? いやあ、遠慮します 経験豊かな人の話の邪魔はしません
>>551 この人に聞いて下さい。 隠れてないで出てきてよ 0687NAME IS NULL2023/08/15(火) 15:40:31.05ID:??? 3年は、この人が言い出した数字 古いものから整理するも、この人が言い出していること 参照も、この人が言い出したこと
全部この人が起源 色々根拠聞きたいなら、>>551 この人に聞いて下さい 0688NAME IS NULL2023/08/15(火) 15:42:31.65ID:??? 私は、この場ではぐらかしをしている人が、本人だと思ってる 0689NAME IS NULL2023/08/15(火) 15:43:20.43ID:??? 聞くべき相手は、>>551 なのに、それをしようとしていない 0690NAME IS NULL2023/08/15(火) 16:03:34.15ID:???>>687 仮に>>685の仮定を追加したとしても、そこに書いたように商品マスタ履歴も必要な期間保持すればいい話。 購入履歴は10年だとか客の問い合わせは期限がないとか後付けで言いだしたのはあんただろ。 それで3年で足りないというなら期限を延ばせばいいだけ。設計には何の影響もない。 0691NAME IS NULL2023/08/15(火) 16:08:41.68ID:??? というかもともと気になってたのはこっちなんだよな。 必死にはぐらかそうとしているようだけど。
>3年毎にマスターのテーブル設計が変わる
>残す料金のカラムは消せないんだから、料金改定の度に増えるんだろう
いったいどんな設計を想定していたんだか。 0692NAME IS NULL2023/08/15(火) 16:17:03.83ID:???>>551に教えてほしくて仕方がないやつww 0693NAME IS NULL2023/08/15(火) 17:11:24.85ID:???>>551はベテランの経験豊富な設計者だぞ 蘊蓄聞いても損はないだろう
>店や商品によるけど一般的な小売ならだいたい3年は保持してる
何百件案件片付けたんだろう 0694NAME IS NULL2023/08/15(火) 17:13:46.94ID:??? 客が過去の買い物について問い合わせてきたら 消したデータを復元して対応するんだろうな 3年より前はふつう消すんだそうだ 設計には影響ないそうだ 0695NAME IS NULL2023/08/15(火) 17:33:19.32ID:??? で、DB設計には関係ないってのは理解できたか?それともまだ理解できないか? 0696NAME IS NULL2023/08/15(火) 17:45:31.61ID:??? 3年保持するは単なる要件の一つで じゃあ3年たったら削除するような管理するDBの設計はどうするのかってだけなのに 3年3年バカの一つ覚えでいってるやつはほんとに設計したことないのがよくわかる 恥の上塗りに上塗りを重ねて何をしたいのかもわからなくなってるんじゃね 明日か明後日から仕事だろもうおとなしくしてロw 0697NAME IS NULL2023/08/15(火) 17:48:58.75ID:??? >決められた保持期間をすぎれば古いものは整理する >店や商品によるけど一般的な小売ならだいたい3年は保持してる
単なる要件じゃなく、このベテラン開発者の経験値なんだそうですが 0698NAME IS NULL2023/08/15(火) 17:57:36.97ID:??? 3年って言いだしたの、>>551 ですよ この人は設計したことあるんでしょう? 0699NAME IS NULL2023/08/15(火) 17:58:49.16ID:??? しかも、削除はとても複雑になりそうだし なんでこんな設計するんだろうって興味が湧きます 0700NAME IS NULL2023/08/15(火) 18:09:41.29ID:??? >しかも、削除はとても複雑になりそうだし >なんでこんな設計するんだろうって興味が湧きます
またw いったいどういう設計を想像したのか非常に気になる 0701NAME IS NULL2023/08/15(火) 18:12:54.40ID:??? 期日が来たからって削除できない事は理解できますか? この料金値を使ってないことを確認しないとだ駆除できません 0702NAME IS NULL2023/08/15(火) 18:25:37.02ID:??? >期日が来たからって削除できない事は理解できますか?
まったく理解できないが、それは上で言っていた購入履歴の保持期間の方が長いからという話?
>この料金値を使ってないことを確認しないとだ駆除できません
ふつう、販売価格マスタの有効期限を過ぎて購入履歴が発生することは考えにくいが どういう前提を想定しているんだろう? 仮にそういうものがあったとしても、どっちにしろ購入履歴側で販売価格情報のキーを参照しているなら 簡単に判断できる話だな。それともこれが「とても複雑になりそうだし」ってことなのかね。 0703NAME IS NULL2023/08/15(火) 18:27:20.98ID:??? 3年経ったら消してしまうから、 4年目にクレーム来るとパニックですね 0704NAME IS NULL2023/08/15(火) 18:30:28.32ID:??? ログインしてユーザーが購入履歴を見るページ作ってたら、 4年以前には何も買ってないことにされます 分析用途に使うのも諦めないとね 0705NAME IS NULL2023/08/15(火) 18:33:58.53ID:??? ネット通販業務に関われば判るけど お客の購入履歴なんてそれこそ宝物ですよ 販促にも使えます ふつう消さないと思う 0706NAME IS NULL2023/08/15(火) 18:43:56.34ID:??? 既に>>685で書いたことなんだが、やっぱり抽象的な書き方だと理解できない頭なのかね? 購入履歴から参照するから保持しなければならないというなら必要な期間保持するか、 あるいはその問い合わせへの回答に必要な情報だけ持たせるなりすればいいだけの話。 0707NAME IS NULL2023/08/15(火) 18:54:39.93ID:??? そもそも削除する必要が無いです 0708NAME IS NULL2023/08/15(火) 19:30:48.93ID:??? 自分の案件と他所の案件の区別ができてない。 https://www.adhd-coach.org/adhd0709NAME IS NULL2023/08/15(火) 20:17:59.92ID:???>>707 削除しないとDB肥大化するからそれを見越した設計にしないときつくね?
普段構ってもらえなくて今回みんなに構ってもらえてうれしいのかしらんけど バカにされてるってわかってないのが悲しいよな 0710NAME IS NULL2023/08/15(火) 20:22:29.77ID:??? とうとう本人が名乗り出ることがなかった さすがに恥ずかしいと思うんでしょう
勝負付いちゃいましたね 0711NAME IS NULL2023/08/15(火) 21:08:24.33ID:??? 削除してはいけないって要件を前提にしてるひとが一人いて 削除する話に削除してはいけないって噛みついてただけ 0712NAME IS NULL2023/08/15(火) 21:11:28.69ID:??? 日本語が変 0713NAME IS NULL2023/08/15(火) 21:18:16.10ID:??? めっちゃ盛り上がってるやんw 0714NAME IS NULL2023/08/15(火) 21:45:55.77ID:??? とうとう勝利宣言出ちゃったね。これも藪の中か。
>3年毎にマスターのテーブル設計が変わる
>残す料金のカラムは消せないんだから、料金改定の度に増えるんだろう
>しかも、削除はとても複雑になりそうだし >なんでこんな設計するんだろうって興味が湧きます 0715NAME IS NULL2023/08/15(火) 22:23:58.96ID:??? 勝利宣言w出たから駆逐してやろう