-
データベース
-
DB設計を語るスレ 11
- コメントを投稿する
-
SQL楽しい。
-
10月10日の試験、合格できるだろうか。。
-
4年ぶりの新スレ。
-
どこまで保守すれば良いかわからぬ
-
誰か教えてくれ
-
ミックの本読んで勉強中
-
一応、10までやるわ
-
having句と自己結合使ってメジアン求める式が難解
-
辛いのう
-
乙。
-
保守とかもうやらなくてもよくなったんじゃ?
-
保守要らんのか。。
-
データベース板は十数年前のスレッドが生きているくらいだからな。
ギャンブル系の板はすぐにスレッドが消える。 -
いまちょっとだけ確認したら、18年前に立てられた過疎スレがあった。
-
本当だ、2003か。俺が大学2年の時だわ。時が経つのは早いなぁ
-
ちょっと見ただけだけどここが一番古かった
もう数ヶ月で20年、歴史を感じるわ
1 MASM 01/12/16 01:40
XOR AX, AX
8086アセンブラで会話しよう。
https://matsuri.5ch....gi/i4004/1008434418/ -
スレのライフタイムが1559日とか感慨深いわ。部署異動したばかりの頃だったな。あの時は若かった
-
>>17
20年前とか、別人だよな。いまや、太って髪が薄くなったオッサン。 -
過疎過ぎだな。
-
データベーススペシャリスト試験前なので、先輩方有益な知識くらさい。。
-
>>21
デブ女を抱くと合格します。 -
ソ連の核は綺麗な核
ポル・ポトはアジア的優しさ
北朝鮮は地上の楽園
珊瑚自作自演事件
南京・慰安婦捏造
教科書書き換え「誤報」事件
朝日・武富士裏献金事件
拉致問題切り捨て
サイレント魔女リティ
風の息遣い
五味ボマー
変態新聞
村木局長犯人扱い
その他人民裁判ならぬマスコミ裁判は数知れず
そしてマスコミお得意の「報道しない自由」
これでも貴方は新聞を信用しますか
これでも貴方は新聞を購読しますか
よく考えて下さい -
サンケイ記者って朝日に採用されなかった奴がなるって本当?
-
>>24
三流新聞だからね。フジサンケイグループはネトウヨから左翼だと攻撃されて、ネトウヨ寄りになったヘタレ。 -
親会社はフジテレビ
-
スペシャリスト試験1ヶ月切って胃が上がってきたっす( ´Д`)y━・~~
-
あと18日。午後2は何とか仕上げられるかな
-
疲れた。試験受からぬかもしれぬ(´・ω・`)
-
落ちたか?
-
>>30
落ちたわ(´・ω・`) -
そっか、次がんばれ。
-
ブログとか文章を書いていると自動的に下書きされる仕組みがあれます。
あれって、同じテーブルに下書き用のフラグをつけてるのでしょうか?
それとも下書き用のテーブルを用意しているのでしょうか? -
それはWebシステム側の仕組みだから
DBはそれに応じて対応する -
>>33
下書き用テーブルに何か意味があるなら使ってみたら -
そんなん設計方針によるだろ
お行儀よくいくならテーブル分けたほうがいいけど、実態としては同じテーブルのことが多いんじゃない
published_at的なカラムがnot null &過去なら後悔っていうロジックにするんじゃね -
ブログの更新をどのような手順で行うのか
下書きの保持期間はどのくらいなのか
そのセッションで破棄するのか、数日間保持するのか
公開ページは、公開後に更新しないのか
更新や修正の履歴は残すのか
など、色々あるから -
WordPressは同一テーブルに保存する
だから無駄なレコードが増えまくる -
公開済み記事を中途半端に編集して一旦下書き保存とか
バージョン管理が必要なら別テーブルのほうがスッキリする
編集中の新バージョンの記事から旧バージョンの記事へのリンクをもたせて
バージョン管理することもできなくはないが諸々の処理が非効率になる -
システム側の問題だけど、自動保存は後始末が気になるな
どうしても余計なログが溜まっていくわけだし
cronなんかでわざわざ期限指定削除するのもあれだし -
要件次第っていい出したら議論の放棄にしか見えんな
「俺はAだ。だけどBもある。その他いろいろ」
って見解ならわからんでもないが -
「フラグをつける場合もあるし、下書き用のテーブルを用意する場合もある」
こう回答すると質問者の意に適うんだろうか
それなら聞かなくても良かったにならないか? -
それって単に相手の言葉を引用してるだけじゃん
それなら答えなくても良かったにならないか? -
データモデルを本当のプロに任せないプロジェクトが多すぎるんだよなあ。
-
「牛丼食べたいがどうしたらいい?」
って質問してるやつに、予算や場所や味の好みを聞くようなもんだな
普通に吉野家、松屋、自分で作る、コンビニで買う、冷凍食品を使う
など、それぞれが思うことを言えばいいだけなのに -
>「牛丼食べたいがどうしたらいい?」
>って質問してるやつに、予算や場所や味の好みを聞くようなもんだな
要件っていう言葉の意味を理解してないなw
牛丼食べたいなら食べればいいじゃん
なんでそんなことわざわざ聞くの?
どうしたらいいかなんでわからないの? -
そこを聞くのがSIerだろう
-
要件を明確にしないやつにろくなやつがいないから防御本能が働くのかもな
-
ここで回答してるのはSIerが業務でやってるわけじゃない
質問者は客じゃない
まともな回答がほしいなら要件は質問者がまとめて提示すべきで、要件次第って言われてるってことは
それだけじゃ答えようがないからもうちょっと詳しく条件書けってことだ -
お前ら和歌山県出身の下村拓郎様(35歳、元自衛隊)をご存知か、この方は将来素晴しい人物になるから覚えておいて損はないぞ
-
n;nのデータベースを作りたいです。
具体的にはパソコン部品と症状です。
簡単なケースとして
フリーズする→CPU
再起動する→CPU
みたいなデータです。
該当パーツを選ぶと関係する症状が出てくる。症状を選ぶと該当するパーツが出てくるという感じです
出来ればwebサイトにて構築したいのです。
難しければEXCELで。
ACCESSだとライセンスの問題が出てきてしまうのでACCESSは最後の最後の手段で
こんなサイトで作れるよとか
こんなソフトあるよ等アドバイスいただければ幸いです。
よろしくお願いしますm(__)m -
>>55
データベースならどんなやつでも作れるよ
設計スレなので設計の話をするとパーツ、症状、パーツと症状の組み合わせ、の3つのテーブルを作ればいいだけ
ちなみに「フリーズする」とか「再起動する」症状の原因はドライバだったり
アプリケーションだったりパーツとは関係ないことが大半
なので手間かけてWebサイト作るよりもまずはExcelでまとめたほうがよさそう -
何か部品と症状をタブ区切りにしてgrepやawk使って出来そうな気がする
-
>>56-58
ありがとうございます。
一番手軽なのは56番さんのやり方ですね
57番さんの言う通りソフト要因は当然ありますね
56&57番さん
手軽にアプリケーション不要で誰でもどこからでも参照、検索出来るようにしたいと思い
webアプリケーション?web上に構築したくて質問させていただきました。
とりあえずEXCELでデータ入力してどこかに構築出来そうなアテが出来たら移行してみたいと思います。
ありがとうございましたm(__)m -
プロフィールなどの設計で画像カラムが必要な場合、
1つの画像ならプロフィールテーブルに1つあれば十分ですが、
複数画像なら別テーブルにしますよね?
その際、「一覧に表示する画像(サムネイル)」はどうやって決めるのでしょうか?
画像テーブルにフラグでもつけるのでしょうか? -
DB設計として
■プロフィールテーブル
ID|名前
■画像テーブル
ID|プロフィールID|ファイル名|フラグ
としたら、
SELECT * FROM プロフィール INNER JOIN 画像 ON プロフィール.ID=画像.プロフィールID WHERE フラグ=1
みたいな感じで絞り込めば良さそうな気はしますが -
とりあえずはそれでもいいのかもしれないが実際設計するなら
プロフィールと画像の関係/ビジネスルール、画像データの使い方(CRUD)、データ件数、要求性能なんかをまず明らかにしてから考える
例えば
プロフィール1個につき必ず1つサムネイル用の画像が必要か?
一覧に表示する画像はプロフィール1個につき1つだけか? -
>なるほど。要件が増えるにつれてテーブル設計も変わってくるわけですね。
要件が増えたわけではなく>>62に書いてるのは最初の設計段階で明らかにしておくべきこと
プロフィール1つに対して複数の画像を紐付けたい場合
プロフィールと画像でテーブルを分けるのはRDBの場合は当たり前
その2つのテーブルをどういう設計にするかは要件次第
性能目的で1テーブルに非正規化する場合が全くないわけではないがかなり特殊なケース
そういう場合でも普通は正規化した構造を先に考える -
>>60
> その際、「一覧に表示する画像(サムネイル)」はどうやって決めるのでしょうか?
それを決めるのが要件定義
> 画像テーブルにフラグでもつけるのでしょうか?
それは実装だから要件が決まったらまたおいで -
要件によっていろんな形の設計がありうるから
こういうのはDB設計力を高めるには結構いいお題 -
>>60
タイムスタンプ -
HeidiSQLの作者があっさりMaterializedView非対応だとのべて逃げてしまった
5年前
そんなばかな
ひょっとしてMaterializedViewってアンチパターンなのか? -
恥ずかしい話なんだが20年くらいPGやっててDB設計やSQLが苦手でいつもできるやつにまかせてたんだけどやっぱ一から勉強しないとダメだなって思ってるんだけど最低限これできれば恥かかないよってのあったら色々おせーてください
-
SQL
レベル1: データの作成/更新/抽出やテーブル/ビュー/インデックスの作成/変更ができるようになる
レベル2: 実行プランが読めるようになる
レベル3: クエリのチューニングができるようになる
レベル1はその辺のドリル形式とかの入門書で比較的すぐに身につく
レベル2はRDBのアーキテクチャ理解が必須なので教科書的な本かベンダー資格で勉強するといいと思う
教科書的な本はこういうやつ。DB設計の基礎とも重なる部分
https://www.ohmsha.c.../book/9784274225161/
レベル3は実践 + チューニングに特化した本とかで知識を増やせばいいと思う
↓このサイトの内容やこの人が書いてる本はオススメ
https://use-the-index-luke.com/
DB設計は上でいうSQLのレベル2になってからはじめればいい -
>いつもできるやつにまかせてた
相当えらい人なんではないかな? -
てか、そのできる奴とやらにどういう処理なのか聞けば良くね?
-
>>71
SQLが苦手という人はだいたいレベル1が満足にできないもんよ
ちなみにSQLが得意とアピールする人も大半はレベル1の人なので要注意
プログラマー歴10年以上でも実行プランはコストだけ見る人とか
インデックス使ってそうかどうかくらいしか分からない人のほうが多い
その辺を見るのにベンダー資格はある程度役に立つ -
得意なんて言葉使ってる人はこれに限らず普通のレベルでしょ(人並程度ですとかわらん)
-
>>75
君は日本語能力が普通のレベルに達してないね -
調べれば調べるほどわからんことが出てきていつになっても得意なんて言えない
-
「あなたの得意な技術は何ですか?」
「調べれば調べるほどわからんことが出てきていつになっても得意なんて言えないです」
「。。。。。(ハイ、不採用っと)」 -
流石にそんな馬鹿正直には言わんよw
-
君が阿呆な面接官しか見たことないのはなぜか考えようねw
-
良い質問だ、今度面接に来た奴に出してみる
-
Yは4
-
面接官が理解できる範疇で答えないとダメなのは確かなこと。
-
DB設計の初歩について教えてください。
ECサイトのproductsテーブルの設計で以下の様なデータがあった場合には、後述するテーブルの様に正規化するのが正しいでしょうか?
|id|商品名 |型番|色|容量|
|id|iPhone14 Pro Max| MQ993J/A| Deep Purple |128GB|
|id|iPhone14 Pro Max| MQ9E3J/A| Deep Purple |256GB|
|id|iPhone14 Pro Max| MQ983J/A| Gold |128GB|
|id|iPhone14 Pro Max| MQ9D3J/A| Gold |256GB|
|id|iPhone14 Pro Max| MQ973J/A| Silver |128GB|
|id|iPhone14 Pro Max| MQ9C3J/A| Silver |256GB|
|id|iPhone14 Pro Max| MQ963J/A| Space Black |128GB|
|id|iPhone14 Pro Max| MQ9A3J/A| Space Black |256GB|
|id|iPhone14 Pro |MQ0F3J/A| Deep Purple |128GB|
|id|iPhone14 Pro |MQ173J/A| Deep Purple |256GB|
|id|iPhone14 Pro |MQ073J/A| Gold |128GB|
|id|iPhone14 Pro |MQ173J/A| Gold |256GB|
|id|iPhone14 Pro |MQ013J/A| Silver |128GB|
|id|iPhone14 Pro |MQ0Y3J/A| Silver |256GB|
|id|iPhone14 |MR3Q3J/A| Yellow |128GB|
|id|iPhone14 |MR3R3J/A| Yellow |256GB|
|id|iPhone14 |MPVJ3J/A| Blue |128GB|
|id|iPhone14 |MPWN3J/A| Blue |256GB|
|id|iPhone14 |MPUD3J/A| Midnight |128GB|
|id|iPhone14 |MPVW3J/A| Midnight |256GB|
|id|iPhone14 |MPWV3J/A| Midnight |512GB|
商品テーブル
id 商品名
1 iPhone14 Pro Max
2 iPhone14 Pro
3 iPhone14
色テーブル
id 色
1 Deep Purple
2 Gold
3 Silver
4 Space Black
5 Yellow
..more
容量テーブル
id 容量
1 64GB
2 128GB
3 256GB
4 512GB
5 1TB
商品詳細テーブル
id 商品ID 型番 色ID 容量ID
1 1 MQ993J/A 1 2
2 1 MQ9E3J/A 1 3
3 1 MQ9J3J/A 1 4
4 1 MQ9N3J/A 1 5
5 1 MQ983J/A 2 2
6 1 MQ9D3J/A 2 3
7 1 MQ9H3J/A 2 4
8 1 MQ9M3J/A 2 5
.....more -
よくwからないならとりあえず第三正規形にしとけ、というのはよく言われる話。
とはいえ正しく正規化をするにはそれなりの知識は必要だな。
>>85を見る限り正規化とは関係ないテーブル分割も混じっているし。 -
>>85
商品詳細テーブルの型番がユニークでIDと型番が1対1であれば
一応は第三正規形とみなせるので正規化の練習問題なら概ねいいと思う
実戦なら検索と更新の方法や扱う商品の種類など様々な状況に依存するから単純な正解はない -
ECサイトで商品管理の一番中心となる商品マスタは「商品詳細テーブル」にあたるもので
このテーブルで自社が管理する商品番号から特定の商品を一意に特定できるようにする
でも「商品詳細テーブル」という命名とカラムの並べ方からそういう認識ではなさそうに見えたのが少し気になったところ -
商品詳細テーブルが何か違うと思う
idはともあれ、商品IDが1固定というのは変 -
>>85
商品詳細テーブルに書いてる例が全部iPhone14 Pro Maxだから1 -
確かに言われてみれば最初のテーブルが全カラムをカバーできてるということなら第三正規形と言えそうだね
現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと
色や容量は機種によって取りうる組み合わせに制約があるから第五正規形までを考えるとその組み合わせが表現できるテーブルを作ることになる -
>現実には機種や色は書いてる以外の属性が入ってくるだろうから第三正規形でも分割が必要かもしれないのと
そういうのを正規化で分割し終わった結果があのテーブルかもよ -
基本的な SQL 文法をある程度理解して、小さいアプリを作ってるレベルなんですが、
そこそこ大規模な DB も設計してみたいのです。
設計の参考にしたいので、テーブル設計を公開している Web サービスがあれば教えて頂けないでしょうか? -
StackOverflowとかWebサービスではないけどRedmineとかは参考になると思う
和製ならEC-CUBEとかもDBスキーマ見れる
ただしかなり微妙 -
翔泳社のデータベースマガジンを書籍化したものなど、古い本だがいまでも考え方はかわらない。
↑今すぐ読める無料コミック大量配信中!↑