前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/
探検
DB設計を語るスレ 10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
前スレ
DB設計を語るスレ 9
http://echo.2ch.net/test/read.cgi/db/1444733172/
Trに振りまら混ぜたりたいへんだから違うのはわかりますが
相当まーじとか冗談言っていた時代が懐かしいｗ
これを借方テーブル、貸方テーブルの二つに分けるのはどうだろうか？
デメリットとして処理が複雑になるけど、貸方だけの検索とかがデータが半分になる分だけ速くなりそうだけど。
インデックスを適切に設定してたらデータ量の倍半分とかではたいした差はでないよ
貸方か借方で違うテーブルに入るのはどうなのかな
そこを参照したほうが処理が軽いかと思ったけど、DBが同じサーバー
にある場合はあまり変わらないのかな？
0253NAME IS NULL
2018/04/25(水) 17:25:06.73ID:0kFJEAdZコンピュータの仕組みを勉強してください。
未だに末尾の長音符を省略してしまうおじいちゃんは黙っててね
問題起きたことないんか？
おじいちゃんなの？
そもそも問題ってなに？
今は2018年ですよ
こう？
もし取引先が慣用を知らなかったらどんな奴らが仕事してんのか不安になるよな
http://www.mext.go.jp/b_menu/hakusho/nc/k19910628002/k19910628002.html
http://www.atmarkit.co.jp/news/200807/25/microsoft.html
これと個々のIT企業との関連は？
関係ないと思う
って言うような取引先なんて余計に不安になるだろ
なぜ？
みんなが知ってる常識レベルの事知らないで、
さも、それが当たり前の様に振る舞ってる奴とかいるじゃん。
そういう奴に正しい事を教えてくれと請われるならともかく、
わざわざ教える事無いって。
常識知らずに正しい事教えても常識を真似するだけで理解してないし、
表面的に真似されると常識知らずを判別出来なくなる。
馬鹿は馬鹿のままでいてもらった方が関わりを避けれる。
無駄に教えちゃいかんと思う。
0267NAME IS NULL
2018/04/28(土) 14:32:49.38ID:D5cEBG7Q常識はそれぞれの主観に基づく上に
そんなことしても見栄の張り合いで専門板なんて成り立たないぢゃん。。
このスレに限って見てもまともに進行したのは初心者の質問に自称上級者が答えるときだけよ
あとは不毛な罵り合い非建設的なやり取りだけ
ある種のクッションを設けるために多様な人が必要ですわよ
つける派にもつけない派にも妙なこだわりがある人が混じってる
文化庁のやつにも慣例に応じて省略可能とちゃんと書いてある
https://ging.co.jp/tips/57001/
http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/gairai/honbun06.html
おおっっっそれは知らなかった！
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してるんだが、そもそも他人が作ったデータを跡形もなく消せて、その消した証拠すら残さないとかシステムとして間違ってる。
0275NAME IS NULL
2018/05/25(金) 21:21:20.27ID:Jccz1Fx20277NAME IS NULL
2018/05/25(金) 21:26:30.82ID:Z93MyXqjおまえ一人で共有しとけ
必要ないからdeleteしてるんでしょ？
0279NAME IS NULL
2018/05/25(金) 21:54:12.06ID:Jccz1Fx2それが必要だったから大トラブル
0280NAME IS NULL
2018/05/25(金) 22:01:35.26ID:Z93MyXqjというおはなしやな
少々笑えた
0282NAME IS NULL
2018/05/25(金) 23:17:56.83ID:TatbyLnb同じテーブルに残す方がわかりにくい。
0283NAME IS NULL
2018/05/25(金) 23:20:27.43ID:TatbyLnb実際はどのRDBMSでもそんな簡単な使い方をしていないから、それをやることはほぼない。
例えば商品マスターだと、在庫切れやメーカー廃番でも削除する事はしていない
会員情報の場合だと、会員登録申請、会員情報更新、退会をそのまま反映している
退会の場合は、一定期間保留しその後物理削除している
商品販売時は、販売後にサポートが必要だったりするため、
退会とはリンクせずそのまま販売履歴として残している
0285NAME IS NULL
2018/05/25(金) 23:47:38.82ID:TatbyLnb言いたいことは理解できるが、データ量と更新・参照頻度を書かずにものを言っても意味がない。
単にリレーショナルデータベースの知識、SQLの理解が足らないことで論理削除状態にしていることがある。
0286NAME IS NULL
2018/05/26(土) 00:50:49.12ID:bRsNkwI2制御が不十分で、仕掛中のデータが削除できてしまいデータ不整合となった。
どこから発生したか出元の不明なデータだけが存在する状況で、大混乱。
結局前日のバックアップから発生元のデータをサルベージしたって話・・
いやそれ削除フラグ云々以前のレベルやろ...
0288NAME IS NULL
2018/05/26(土) 07:04:47.67ID:n2n4g8U40289NAME IS NULL
2018/05/26(土) 08:11:25.72ID:bRsNkwI2削除フラグはともかく、物理削除はダメだろって話。
消しちゃいけない理由は、後付けで増えていくことが多いから、考慮漏れがあると死ねる
削除フラグを見落として処理するコードが混入していて大混乱、とかね。
0292NAME IS NULL
2018/05/26(土) 09:43:20.38ID:bRsNkwI2それでも跡形もなく消えるよりマシ
少なくとも原因はすぐわかる。
0294NAME IS NULL
2018/05/26(土) 19:39:28.98ID:Pmk3UmpV同じテーブルにためたがるのは、古めかしいデータそのものがどういう状態かを自ら示すという発想から来ているもの。
ソース
0296NAME IS NULL
2018/05/26(土) 21:55:41.58ID:Pmk3UmpV集合演算子を知らない。
何言ってんのこいつｗｗｗ
そして削除フラグは、データの削除ではなく単なる状態変更の場合があるって話
これが理解できない奴が削除フラグの話をかきまわしてるだけ
0302NAME IS NULL
2018/05/27(日) 10:57:41.83ID:0Fr+f65wおまえの事やぞw
本人降臨乙w
0304NAME IS NULL
2018/05/27(日) 15:55:32.12ID:8hLmukSLステータスならフラグという持ち方は変。
0305NAME IS NULL
2018/05/27(日) 15:57:15.03ID:8hLmukSL状態がオン／オフしかないようなものならフラグでおかしくない
>>305
フラグたくさん持ってるとか条件が複雑とか、それが要件なら仕方ない
むしろ全然関係ないフラグをビットフィールドにまとめるほうが迷惑
0307NAME IS NULL
2018/05/27(日) 21:18:51.26ID:8hLmukSL>>298 は削除フラグが状態変更と言っている。単に論理削除ではないと言っている。それをただ「削除フラグ」と呼んだら普通は意味がわからない。
0308NAME IS NULL
2018/05/27(日) 21:20:22.92ID:8hLmukSLおまえ、ジジイだろ？
そんなわかりにくいデータの持ち方は、リレーショナルデータベースの考え方ではない。
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がこちら都合のキャンセル。
嫌になった。
毎日の価格はどういうテーブルにしたらいいですか？
itemテーブルはそんなものだろうと思う。
毎日の価格を登録するテーブルというのが、
実際の販売時の価格を取引単位で記録して行くのか、
それとも一定時間での平均価格等を記録して行くのか
もう少し具体的な要件を出してもらう方が良いかと思う
価格というのは市場で取引された価格の高値と安値で1日2つの価格に決まります。
それとも、一日の最後に取得するものなのか
前者の場合は、そういう記録もとっておき、更新しないとならなくなるよね
記録したい項目をテーブルに用意して終わりでしょう
item_id
high_price
low_price
date
他に必要な項目があれば追加
プライマリキーは要らないんですか？
あとテーブル名ってどんな感じに付けますか？
どうしてもキーを付けるなら、
一意になりそうな日付かな？
テーブル名はお好きにどうぞ
チェック(取引年月日 = 時間切捨(取引年月日))
チェック(取引価格 >= 0)
インデックス(果物ID, 取引年月日)
select 果物ID, 取引年月日, max(取引価格) 最高値, min(取引価格) 最安値
from 果物取引実績
group by 果物ID, 取引年月日
そうだね、一意にするためには日付だけではなく
itemIDとセットにしないといけなかった
同じ果物が何度も売れてもいい
要件そのまま聞くとまあ後でおかしくなるよ
この場合だと、その日の最後に入力するので取引実績をメモしておかないといけないんだけどめんどくさい、だとか
最大最小を計算するのめんどくさいからどうにかして、といった具合
0331NAME IS NULL
2018/06/02(土) 00:24:27.89ID:gAkF9Xc4insert into 果物取引実績 values
('id1', 'banana', 年月日, 最高値),
('id2', 'banana', 年月日, 最安値)
といった形にすればよろしい
最初からテーブル構造が壊れてると想定外の事態に回避策とりにくい(メモめんどくさいとか手集計めんどくさいとかね)
テーブル構造がまっとうなら回避策も容易に見つかる
それだと、レコード一つだけ見たときにそｒが最高値か最安値か分からないだろう
どうやったらこんなアホな発想に至るんだろう...
>>323
どう見てもidがキーとわかる
果物idと日付をキーにする派閥もあるが
後で見た人は同じ日に同じものが売れたらどうなるんだ？と疑問を感じざるをえない
せめて反論の形にしないと敗北宣言と同じだよ？
基本中の基本
最大値や最小値を1行に保存するということはこれに反する
統計値とは複数の事実から導き出されるものだからだ
え゛っ、マジで言ってるの？
値を参照するだけで>>323相当のSQL要るし、既に>>320みたいなまっとうな例もでてるのに w
基地害ｷﾀ━(ﾟ∀ﾟ)━!
統計値を参照するのに集計クエリが要るのは正常
>>320はまっとうじゃないよ
手作業で出した集計値を保存するという暗黙の手続きの上にかろうじて成立しているだけ
それと試しにこのテーブルにまっとうな名前をつけてみなさい
>>338
彼らは形式しかみないから>>320のような歪なテーブルを受け入れてしまうがそれはダメだ
意味的にも正しく正規化すべきだ
はっきりさせるべきだな。
「正規化」って用語を「正しいテーブル設計」の代名詞みたいに使う人は相変わらずいるねぇ。
意味的に正しい正規化ってなんだろう。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【ドジャース】大谷翔平、2戦連発6号ソロでリード広げる 敵地大歓声24球場目弾 今季最長タイ8戦連続安打 [フォーエバー★]
- 電車内で「前リュック」はマナー違反なのか 鉄道会社も配慮する“リュックは前に抱えるな派”の言い分 (大谷百合絵氏) [少考さん★]
- 【漫画】人気マンガの「汎用性高すぎ」な名言4選「こういうのでいいんだよ」「判断が遅い」「だがそれがいい」 [ネギうどん★]
- 日本の焼肉店でぼったくり！？納得いかない台湾人客が警察に通報したら…―台湾メディア [バイト歴50年★]
- キムタクを縛り続ける《公称176cm》のデータ…番宣行脚でも視聴者の関心は共演者との身長比較 [ネギうどん★]
- 【イギリス】不法入国者をルワンダに強制移送 法案が議会で可決 [PARADISE★]
- LAD @ WSH ★2
- LAD @ WSH ★3
- 【SPOTV/U-NEXT/ABEMA】プレミアリーグ総合 ★132
- 巨専】
- とらせん
- 【NJPW】新日本プロレスワールド part.1963
- 福島第一原発、電源停止ｷﾀ―――(ﾟ∀ﾟ)―――― !! [252835186]
- 【悲報】氷河期、徴兵OKに [115996789]
- 俺のあなる結構きれいじゃね？
- お前らサッカー見ろよ [782460143]
- 仕事終わったらラーメン屋さん行くw
- 【悲報】洋画ファン「幼稚なアニメ映画ばかりヒットしてる日本の映画館は自分の行くべき場所ではないと感じる」→オタクブチギレwwwwww [426633456]