24/01/13(土)15:21:51 SQLの勉... のスレッド詳細
削除依頼やバグ報告は メールフォーム にお願いします。個人情報、名誉毀損、侵害等については積極的に削除しますので、 メールフォーム より該当URLをご連絡いただけると助かります。
画像ファイル名:1705126911964.png 24/01/13(土)15:21:51 No.1145748710
SQLの勉強してる 手元にあるゲームソフトとゲームを管理するデータベースを設計してみたのでレビューしてほしい
1 24/01/13(土)15:26:40 No.1145750158
持ってないタイトルまで登録する必要もない気がする
2 24/01/13(土)15:29:30 No.1145751023
タイトルにジャンルコード入れたらいかんのか？
3 <a href="mailto:s">24/01/13(土)15:31:31</a> [s] No.1145751621
>タイトルにジャンルコード入れたらいかんのか？ ジャンルがまたがってるやつあるのでsteamみたいにジャンルをタグとしていっぱい登録できないかな…って
4 24/01/13(土)15:32:08 No.1145751777
>持ってないタイトルまで登録する必要もない気がする 持ってないけど気になってるタイトルとか登録するのかもしれない
5 24/01/13(土)15:32:56 No.1145752003
持ってるタイトルと持ってるハードのidいらなくない？ あとジャンルとタイトルの紐づけしてるidもそれっぽい名前にしたほうがいいかも
6 24/01/13(土)15:33:20 No.1145752117
これってSQLの勉強じゃなくてテーブル設計じゃね？
7 <a href="mailto:s">24/01/13(土)15:35:16</a> [s] No.1145752651
>これってSQLの勉強じゃなくてテーブル設計じゃね？ DBは全く初心者だから…ごめん たしかに他のデータベースもあるよね
8 24/01/13(土)15:35:19 No.1145752665
評価とかハードの状態は別テーブルの方がスマートかも タイトルの追加とかハードの所有状態とは別にそこだけ更新される可能性があるから
9 24/01/13(土)15:36:25 No.1145752991
>ジャンルがまたがってるやつあるのでsteamみたいにジャンルをタグとしていっぱい登録できないかな…って なるほど理解した ところでこれSQLじゃなくてDB設計の話なんじゃないか？
10 24/01/13(土)15:36:51 No.1145753120
ジャンルというテーブルならidでいい ジャンルIDにするんじゃなくて
11 24/01/13(土)15:38:32 No.1145753642
持ってるハードや持ってるタイトルにuser_idはいらんの？ usersテーブルはないの？
12 24/01/13(土)15:40:11 No.1145754139
ハードリストのmakerはハードの製造企業？任天堂とかソニーが入るの？
13 <a href="mailto:s">24/01/13(土)15:40:55</a> [s] No.1145754377
>持ってるハードや持ってるタイトルにuser_idはいらんの？ >usersテーブルはないの？ 俺が使うことしか考えてなかった！ 使う人が増えることを考えたら欲しいね
14 24/01/13(土)15:41:27 No.1145754570
ゲームメイカーとハードメイカーは別のテーブルにしたほうがいいかも
15 24/01/13(土)15:42:42 No.1145754945
タイトルリストにマイ評価があるのが違和感ある 持ってるタイトルの方にあるべき
16 24/01/13(土)15:43:43 No.1145755245
総合評価ならタイトルリストにあってもおかしくないけど マイ評価ならuser系のテーブルにあってほしいね
17 24/01/13(土)15:43:59 No.1145755310
メーカーが複数の場合たまにあるよな リスト化面倒だし第二第三を追加すれば良いか
18 24/01/13(土)15:44:17 No.1145755388
マイ評価は持ってるタイトルのてテーブルじゃないかな
19 24/01/13(土)15:44:31 No.1145755448
方眼紙やめろ
20 24/01/13(土)15:44:55 No.1145755584
>DBは全く初心者だから…ごめん >たしかに他のデータベースもあるよね でもこういうところから始めてここからケース別にSQL文を書いてみるのはかなり上達に役立つと思う
21 24/01/13(土)15:44:57 No.1145755589
セガみたいにゲーム出してるハード屋もあるしそこは別にどっちでもいいんじゃない
22 24/01/13(土)15:45:11 No.1145755672
手元にあるゲームって前提なのに複数ユーザーなんか考慮する必要あるのか
23 24/01/13(土)15:45:57 No.1145755906
ハードの名前integerでいいの？
24 <a href="mailto:s">24/01/13(土)15:46:12</a> [s] No.1145756000
完全に自分で使うことしか考えてなかったので確かに…ってなってる 評価がタイトルリストにあるのは同じソフトを2本持ってるときを考えてしまって惑わされたね
25 24/01/13(土)15:46:17 No.1145756023
持ってるハードと持ってるタイトルは「入手イベント」として表現したほうが良いかも (用途によるけど)
26 24/01/13(土)15:48:09 No.1145756608
こまけえこと言い出すとデベロッパーとパブリッシャーと…みてえな話になっていく 版権移譲された場合のタイトルの扱いとか移植とか地域ごとの販売担当とか広げようと思えばいくらでも広がっちゃう
27 24/01/13(土)15:48:44 No.1145756815
SQLわかっててもDB設計全然なやつもいるからこう言うとこからスタートするのいいと思う
28 24/01/13(土)15:49:31 No.1145757082
>>タイトルにジャンルコード入れたらいかんのか？ >ジャンルがまたがってるやつあるのでsteamみたいにジャンルをタグとしていっぱい登録できないかな…って 1対多か1対1かがわかる記号も表記するともっとわかりやすくなるかも！
29 24/01/13(土)15:49:54 No.1145757199
>手元にあるゲームって前提なのに複数ユーザーなんか考慮する必要あるのか 勉強ってのがお仕事に使うも視野にいれてるなら確実に入ってくる要素だし
30 24/01/13(土)15:49:55 No.1145757210
genreToTitleテーブルにidカラム要るかな？ genre_idとtitle_idの複合キーじゃだめ？
31 24/01/13(土)15:50:54 No.1145757511
矢印に1:nなら根本にnを置いて先に1を置いてほしいかな
32 24/01/13(土)15:52:00 No.1145757836
メーカーというか企業だから名前はcompanyテーブルとかにするかなぁ
33 24/01/13(土)15:53:21 No.1145758222
>SQLわかっててもDB設計全然なやつもいるからこう言うとこからスタートするのいいと思う 設計段階で狂ってると手に負えなくなるからな…
34 24/01/13(土)15:53:50 No.1145758355
正規化・一般化を進めていくと無味乾燥なテーブル名・フィールド名になっていく 最終的にはentityとかobjectみたいな概念にたどり着くのだ
35 24/01/13(土)15:54:00 No.1145758411
個人用途と勉強用ならこれで実際に作ってみてデータ入った状態で改修とかしてみるといい勉強になるだろうね
36 24/01/13(土)15:55:38 No.1145758879
細かいけどハードリストの名前がintになってる
37 24/01/13(土)16:00:50 No.1145760446
同じソフトを多数持ってるときはいっそ考えないほうがいいのかな あくまで持ってるか持ってないかで
38 24/01/13(土)16:01:52 No.1145760745
パッケージ版とDL版みたいな情報も必要か？
39 24/01/13(土)16:02:50 No.1145761011
状態は列挙型使ってみたいなぁと思いつついつも保守的に定数を使う
40 24/01/13(土)16:03:05 No.1145761078
>genreToTitleテーブルにidカラム要るかな？ >genre_idとtitle_idの複合キーじゃだめ？ 役割的にはジャンルとタイトルの関係テーブルだから上下関係というか方向を感じる命名も気になるっちゃなるな
41 24/01/13(土)16:03:28 No.1145761181
1対1で結びついてるレコードをテーブル分割する必要ないよ
42 24/01/13(土)16:03:38 No.1145761245
状態マスタは別で持っておいたほうがいい ソフトウェアや周辺機器の状態を管理したくなったときも使える あと同タイトルでハード違いのものの考慮が足りない
43 24/01/13(土)16:04:48 No.1145761582
スレ画ってなんのツール
44 24/01/13(土)16:05:10 No.1145761684
タイトルとハードは複合キーにして持ってるかはフラグでいいんじゃないと思ったけど データ的に持ってないタイトル入れないならなんかデータあれば持ってる扱いでいい気がしてきた
45 24/01/13(土)16:05:14 No.1145761712
>1対1で結びついてるレコードをテーブル分割する必要ないよ 無意識にやったんだろうけどuseridとか足すべきテーブルについてるからその辺なんとなく嫌な感じがしたんだろうなって その辺センスを感じる
46 24/01/13(土)16:05:15 No.1145761718
同名のジャンルは無いだろうから代理キーつけて別テーブルに分けなくてもいい気がするかな
47 24/01/13(土)16:05:42 No.1145761843
genreToTitleの命名が分かりにくい
48 24/01/13(土)16:05:58 No.1145761922
ジャンルトゥタイトルいらないかな タイトルマスタにジャンルIDもてばいいし
49 24/01/13(土)16:06:57 No.1145762212
>ジャンルトゥタイトルいらないかな >タイトルマスタにジャンルIDもてばいいし 既に突っ込まれてるけどタグ的な用途で考えてるってことだし素直に複合主キーでいいと思う
50 24/01/13(土)16:08:05 No.1145762567
個人的には持ってるタイトルもタイトルリストに入れちゃう 所持フラグカラムと入手日カラムつけちゃうな
51 24/01/13(土)16:09:43 No.1145763053
各テーブルのIDカラムはidがよくない？ 例えばジャンルリストならganre_idじゃなくてid GanreToTitle側はganre_idでいい
52 24/01/13(土)16:10:37 No.1145763321
言われてるけどGenreToTitleいらないのと マイ評価は持ってるタイトルに移行した方がいい あと持ってるタイトルにハードIDも追加した方がいい
53 24/01/13(土)16:11:02 No.1145763445
一対多ならジャンルっていうかタグだな
54 24/01/13(土)16:11:24 No.1145763555
GenreToTitleいらなくて TitileListにgenre_id持てば良い
55 24/01/13(土)16:11:32 No.1145763591
ゲームのプレイ進行度までは一々記録しないか
56 24/01/13(土)16:11:56 No.1145763706
genreToTitleの名前が1対1か1対多っぽくて混乱する 何も考えずに中間テーブルらしくgenres_titlesで良くないか
57 24/01/13(土)16:12:03 No.1145763735
売った場合とかも加味して 「持ってるタイトル」じゃなくて「遊んだタイトル」にして 所持フラグとか持たせてもいいかもしれない
58 24/01/13(土)16:12:23 No.1145763833
ゲームのジャンルは面倒だからな 縦STGと横STGのタグを分けたとき沙羅曼蛇とかどうなる？ってなるし
59 24/01/13(土)16:12:36 No.1145763905
実際のレビューでもわかりやすいツッコミどころがあると聞いてなかった人とかに何度も似たようなこと言われるの割とあるあるだな…
60 24/01/13(土)16:13:24 No.1145764148
フィールド名に日本語使うのはおよし…
61 24/01/13(土)16:13:29 No.1145764182
リリース日入れるなら値段も見たい気がする
62 24/01/13(土)16:13:38 No.1145764231
imgで設計レビューしてるの初めて見た
63 24/01/13(土)16:13:46 No.1145764268
そろそろアーケードゲームの基板の話をするか！
64 24/01/13(土)16:14:01 No.1145764368
マイ評価カラムをは持ってるタイトルに移すかどうかは過去に持っていたタイトルをどう扱うかとか、持ってないけどやったことのあるゲームをの評価を持つかどうかにもよる
65 24/01/13(土)16:14:13 No.1145764431
>リリース日入れるなら値段も見たい気がする 消費税関係も入れるとDB正規化のいい勉強になると思う
66 24/01/13(土)16:14:21 No.1145764473
>imgで設計レビューしてるの初めて見た スレ画は課題としていい感じすぎる…
67 24/01/13(土)16:14:28 No.1145764512
>各テーブルのIDカラムはidがよくない？ >例えばジャンルリストならganre_idじゃなくてid >GanreToTitle側はganre_idでいい そういう命名規則って複合主キーの場合どうなるの？
68 24/01/13(土)16:14:51 No.1145764635
レビューってする側も勉強になるからな…
69 24/01/13(土)16:15:30 No.1145764836
これSwitchとSwitch liteみたいなのはどうするの？ GBカラー対応GBソフトとかも
70 24/01/13(土)16:15:42 No.1145764898
メーカーリストはこうするfu3028426.png
71 24/01/13(土)16:16:27 No.1145765104
１タイトルが複数ジャンル持つの結構めんどくさいな ジャンル周りは画像の設計でも全然いい気がしてきた
72 24/01/13(土)16:16:40 No.1145765155
SFC内臓テレビはSHARPが作ってたがもし持ってたらそれはSHARPなのかNintendoなのか鴻海なのか…
73 24/01/13(土)16:17:52 No.1145765505
>１タイトルが複数ジャンル持つの結構めんどくさいな genre_id_1 genre_id_2 genre_id_3 genre_id_4 genre_id_5 このカラム追加するぜー！
74 24/01/13(土)16:18:14 No.1145765612
とするとハードじゃなくてプラットフォームってしたほうがいいのか？
75 24/01/13(土)16:18:19 No.1145765641
>メーカーリストはこうするfu3028426.png 履歴系マスタの日付は開始日と終了日を持つようにして そうするとbetweenでselectできるから
76 24/01/13(土)16:18:19 No.1145765644
メーカー名が合併したら存続会社以外はLiquidateフラグ立てとけばよくね
77 24/01/13(土)16:18:23 No.1145765670
タイトルリストはタイトルによって複数ハードで出てるものもあるからhd_idも主キーに含めて良いんじゃない
78 24/01/13(土)16:18:46 No.1145765797
>このカラム追加するぜー！ このゲームジャンル６つあるんですけど
79 24/01/13(土)16:18:46 No.1145765799
>そういう命名規則って複合主キーの場合どうなるの？ テーブル名+idって感じかな ジャンルリストをganres メーカーリストをmakers とするなら、ganres.idと紐づくカラムはganre_id、makers.idと紐づくカラムはmaker_idにするみたい感じ
80 24/01/13(土)16:18:48 No.1145765806
あ…このケースどうしよう…っていうのがあとから出てくるんだよな…
81 24/01/13(土)16:18:53 No.1145765824
正規化してんのに客は横型でないとわかりにくいんですけお！とか抜かすのやめろ
82 24/01/13(土)16:19:08 No.1145765879
>これSwitchとSwitch liteみたいなのはどうするの？ >GBカラー対応GBソフトとかも 確かに対応プラットホームみたいな形にしたほうが良さそうだな 後者のは流石にそれはもうGBカラー枠で良いんじゃないかな…
83 24/01/13(土)16:19:30 No.1145765992
>このカラム追加するぜー！ こいつをレビューから叩き出せ
84 24/01/13(土)16:19:53 No.1145766092
KanonはVisualArtsなのか？Keyなのか？ NECインターチャネルやPROTOTYPEも関わってくるな
85 24/01/13(土)16:20:18 No.1145766200
○○は使わないので考慮しないとするをしないと設計出来ない
86 24/01/13(土)16:21:20 No.1145766481
>あ…このケースどうしよう…っていうのがあとから出てくるんだよな… 既に動いているため影響が少ない対応をしていくと歪な形に…
87 24/01/13(土)16:22:06 No.1145766699
念の為に予備カラムを用意しておこうぜ！
88 24/01/13(土)16:23:06 No.1145766995
こういう具体例を見れるとホント勉強に良い…
89 24/01/13(土)16:23:43 No.1145767170
なんでimgで真面目なデータベース設計やってるんだ…？
90 24/01/13(土)16:24:04 No.1145767272
こうなったら購入店と購入方法も記録しておこう
91 24/01/13(土)16:24:12 No.1145767311
>念の為に予備カラムを用意しておこうぜ！ s1,i1カラムやめろ！
92 24/01/13(土)16:24:23 No.1145767361
マイ評価はタイトルリストじゃなくて持ってるタイトルの方じゃない？
93 24/01/13(土)16:24:39 No.1145767440
>なんでimgで真面目なデータベース設計やってるんだ…？ 荒らし対策込みの虹裏互換掲示板が出来るんだろう
94 24/01/13(土)16:25:14 No.1145767604
なんかすごく有意義がスレだ
95 24/01/13(土)16:26:06 No.1145767878
SQLアンチパターンいいよね…
96 24/01/13(土)16:26:13 No.1145767918
一定の制限をかけないとアカシックレコードの設計になるぞ
97 24/01/13(土)16:26:27 No.1145768002
>テーブル名+idって感じかな ありがとうなるほどそもそもまず単発のマスタ的テーブルがあること前提ということね 単に添字的な奴は単にsnumとかserialとかになる感じ？
98 24/01/13(土)16:26:32 No.1145768020
>>なんでimgで真面目なデータベース設計やってるんだ…？ なんか一発目のスレ画でわりとまともに考えられた設計がでてきたから……
99 24/01/13(土)16:27:06 No.1145768179
>後者のは流石にそれはもうGBカラー枠で良いんじゃないかな… GBC対応ソフト220本専用ソフト245本で結構数が有るけどまあどうでも良いか？ スターオーシャンでもないとどうせGBAかSPでプレイになるだろうし
100 24/01/13(土)16:29:09 No.1145768861
ゴリゴリに正規化しすぎても使いづらくなる 第三正規化くらいでいいよね
101 24/01/13(土)16:29:12 No.1145768881
>このカラム追加するぜー！ バカだなぁそんな事しなくてもコンマでつなげる方が帳票も出しやすいし楽だろ？
102 24/01/13(土)16:30:24 No.1145769197
>バカだなぁそんな事しなくてもコンマでつなげる方が帳票も出しやすいし楽だろ？ あとからの要件だとたまにやるやつがいる selectするときに苦しむ
103 24/01/13(土)16:31:20 No.1145769498
>第三正規化くらいでいいよね 第三以降ってあるんだ…知らんかった
104 24/01/13(土)16:31:52 No.1145769652
>ゴリゴリに正規化しすぎても使いづらくなる >第三正規化くらいでいいよね まあこれはかなり案件による…
105 24/01/13(土)16:32:20 No.1145769786
メーカーが対等合併した時どっちのID残せばいいかな
106 24/01/13(土)16:32:38 No.1145769869
本当に汎用的なDBにしようとすると手持ちのソフト1本のデータ入力するだけでぐったりする羽目になる
107 24/01/13(土)16:32:50 No.1145769928
JOINしたくないから一つのテーブルに纏めよう
108 24/01/13(土)16:33:25 No.1145770110
>あとからの要件だとたまにやるやつがいる >selectするときに苦しむ selectもそうなんだけどupdateの方がさらに辛い… てか今だと配列型とかjson型なんてのがあるからこう言うので使われたりするけど まずは普通に正規化することをマジで検討して欲しい…
109 24/01/13(土)16:33:37 No.1145770169
>メーカーが対等合併した時どっちのID残せばいいかな 発売時のメーカーで分類しとけばええ！
110 24/01/13(土)16:34:46 No.1145770526
持ってるかどうかは本数にしようぜ！
111 24/01/13(土)16:35:39 No.1145770803
ウチはSQLserverだからテーブルもカラムも全部日本語名だぜー！
112 24/01/13(土)16:37:21 No.1145771346
日本語で出来るなら日本語の方がいいわ
113 24/01/13(土)16:37:24 No.1145771369
>ウチはSQLserverだからテーブルもカラムも全部日本語名だぜー！ しね！！！！！！！！！！！！！！！！！！！！！！
114 24/01/13(土)16:38:26 No.1145771697
真面目な話日本語にしかないニュアンスとかもあるから使えるなら無理に英訳しない方がいいと言う考え方も別に間違いではないんだけど まぁそれはそれとして滅んでほしさはある…
115 24/01/13(土)16:38:42 No.1145771784
ローマ字じゃなくて日本語？ 日本語だとどうなる…？
116 24/01/13(土)16:39:09 No.1145771950
日本語名は許す だが()や（）なんかの記号は許さん
117 24/01/13(土)16:39:18 No.1145772005
いいか SQL serverにしろ何にしろDB決めたならそのDBから変えるな 似たような事してるからだいたい同じもんって考えると後で苦しくなる
118 24/01/13(土)16:41:58 No.1145772824
なんかこう自動で持ってこられるデータが欲しい
119 24/01/13(土)16:44:27 No.1145773583
データベース？よくわかんないけど無料のやつあるなら無料のにしといてよ
120 24/01/13(土)16:45:16 No.1145773853
じゃSQLiteで
121 24/01/13(土)16:46:25 No.1145774249
>いいか >SQL serverにしろ何にしろDB決めたならそのDBから変えるな >似たような事してるからだいたい同じもんって考えると後で苦しくなる DBの引っ越し…まこと地獄でござった…
122 24/01/13(土)16:47:32 No.1145774615
複数ユーザー想定してない完全個人用なら持ってるタイトルでテーブル作らんでも良い気がする 分けた方が綺麗っちゃ綺麗だけどいちいちJOINするの面倒だぞ それに今のままテーブル分けるならタイトルへの評価はユーザー個人に属するから持ってるタイトル側か別テーブルに移動だ
123 24/01/13(土)16:47:48 No.1145774706
>データベース？よくわかんないけど無料のやつあるなら無料のにしといてよ 勉強を兼ねないならこれ位スプレッドシート管理で良い気はするが…
124 24/01/13(土)16:48:50 No.1145775047
>DBの引っ越し…まこと地獄でござった… Oracleのメジャーバージョンアップでも大概なのにDB自体の移行とか考えたくもないな…
125 24/01/13(土)16:48:50 No.1145775050
お金のことを考えるなら１０００行くらいの管理ならスプレッドシートで十分だな……
126 24/01/13(土)16:49:14 No.1145775186
持ってるタイトルとか持ってるハードみたいなテーブルに主キーとしてID持つのってベーシックなのかな？ と思ったけど状態とか出てるから同じハード複数持ちがあるのか…
127 24/01/13(土)16:49:26 No.1145775255
そもそもSQLって何ですか 調べたけどよく分からなくて
128 24/01/13(土)16:49:30 No.1145775285
個人でDB扱うとしたらオススメとかあるの？MSアクセス？
129 24/01/13(土)16:50:22 No.1145775590
リブレオフィスのbaseとかで遊ぶのも良いかもしれん
130 24/01/13(土)16:50:24 No.1145775598
>Oracleのメジャーバージョンアップでも大概なのにDB自体の移行とか考えたくもないな… Oracleくんさあ 後方互換性くらいは確保してくんない？？
131 24/01/13(土)16:50:34 No.1145775651
>そもそもSQLって何ですか >調べたけどよく分からなくて 触るつもりないならあんま気にしなくていいよ 仕事で使わないなら縁が無い
132 24/01/13(土)16:51:16 No.1145775860
これは個人の好みかもしれないけど〇〇リストって名前にしないでほしい
133 24/01/13(土)16:51:34 No.1145775946
>>そもそもSQLって何ですか >>調べたけどよく分からなくて >触るつもりないならあんま気にしなくていいよ >仕事で使わないなら縁が無い ありがとう でも教えてくださいね
134 24/01/13(土)16:51:38 No.1145775963
>と思ったけど状態とか出てるから同じハード複数持ちがあるのか… PCとかぶっ壊れたり買い替えたりするし ここまでのPCでしか動かないタイトルとかそういうのもあるかもしれない
135 24/01/13(土)16:51:55 No.1145776043
SEやってんのにSQLしか書けないけど転職できんのかな…
136 24/01/13(土)16:51:57 No.1145776052
>ありがとう >でも教えてくださいね 知ってるけどお前の態度が気に喰わない
137 24/01/13(土)16:52:09 No.1145776111
>個人でDB扱うとしたらオススメとかあるの？MSアクセス？ SQLITEとかpostgreSQLとかでいいんじゃね SQLserverexpressとかでもいいよ
138 24/01/13(土)16:52:32 No.1145776215
折角なんでスレ「」はスレ画をマスタテーブル・トランザクションテーブル・ワークテーブルに区分けしてみて欲しい 区分け作業をしながらどうして区分けをするのかと各テーブルがなぜそこに入るのかを考えながらやってみて欲しい
139 24/01/13(土)16:52:34 No.1145776231
は？MySQLですよね？
140 24/01/13(土)16:52:37 No.1145776248
春から未経験でhtmlの簡単なレベルしか分からないのに VBとC#とSQLserverの開発職に就くぜ なんか勉強しといた方がいいと思うけど別にやんなくていいよって言われたから何もやってないぜ
141 24/01/13(土)16:52:58 No.1145776348
>SEやってんのにSQLしか書けないけど転職できんのかな… データベーススペシャリスト取ればいい
142 24/01/13(土)16:53:06 No.1145776388
>>ありがとう >>でも教えてくださいね >知ってるけどお前の態度が気に喰わない 優しくしてください SQLについてあなたが教えてください
143 24/01/13(土)16:53:25 No.1145776488
なんかもやもやするなと思ったらマスタをリストって名前にしてるのが気になってしょうがない ジャンルリストはジャンルマスタにしてto titleはジャンルって名前のテーブルでいいんじゃないかな
144 24/01/13(土)16:54:26 No.1145776792
>SEやってんのにSQLしか書けないけど転職できんのかな… テーブル設計とDBチューニングとかできればいいと思うけど ガチでSQL書くだけってなるとバッチとかストアドとか書けないと厳しそう
145 24/01/13(土)16:54:29 No.1145776811
>これは個人の好みかもしれないけど〇〇リストって名前にしないでほしい ちょっと違う話だけどRDBで二次元表と言われるとすごくモヤモヤする
146 24/01/13(土)16:54:32 No.1145776826
>春から未経験でhtmlの簡単なレベルしか分からないのに >VBとC#とSQLserverの開発職に就くぜ >なんか勉強しといた方がいいと思うけど別にやんなくていいよって言われたから何もやってないぜ 俺も似たような感じで去年転職したけど全然何とかなってるから安心して
147 24/01/13(土)16:54:46 No.1145776899
>>持ってないタイトルまで登録する必要もない気がする >持ってないけど気になってるタイトルとか登録するのかもしれない ウィッシュリスト機能は迷った時とかにあると便利だよね
148 24/01/13(土)16:55:10 No.1145777030
>なんかもやもやするなと思ったらマスタをリストって名前にしてるのが気になってしょうがない 確かに…リストいらないよね
149 24/01/13(土)16:55:29 No.1145777135
DB設計した後はテストデータ入れて実運用で使いたいクエリーをアレコレ作ってるといい SQL文複雑過ぎ長過ぎ！ってなったら設計の見直しだ
150 24/01/13(土)16:56:06 No.1145777319
>俺も似たような感じで去年転職したけど全然何とかなってるから安心して 言語は違うかもしれんけど 入門書とか入門サイトとか使った？ 後3ヶ月くらいあるしそれぞれ初級本一冊くらいは読んでおこうかなって思ったんだけど
151 24/01/13(土)16:57:37 No.1145777802
>データベーススペシャリスト取ればいい >テーブル設計とDBチューニングとかできればいいと思うけど >ガチでSQL書くだけってなるとバッチとかストアドとか書けないと厳しそう 社内ツールでBIシステム作ってるからテーブル設計とか諸々は最低限やれるつもり DBの過去問見てみますありがとう
152 24/01/13(土)16:57:50 No.1145777870
>折角なんでスレ「」はスレ画をマスタテーブル・トランザクションテーブル・ワークテーブルに区分けしてみて欲しい >区分け作業をしながらどうして区分けをするのかと各テーブルがなぜそこに入るのかを考えながらやってみて欲しい それぞれに入るであろうデータ量(レコード数)の見込みをつけながらやるとスムーズかもしれない
153 24/01/13(土)16:58:04 No.1145777955
初心者でもいいよって言われる現場は生で言語触ることはまずないと思っていいんじゃないか がちがちに組みあがったライブラリをちょろっと呼び出して動作を確認するだけの人員が欲しいだけのケースが多いと思われる
154 24/01/13(土)16:58:51 No.1145778214
>言語は違うかもしれんけど >入門書とか入門サイトとか使った？ 横からだけどミック氏のリレーショナルデータベースの世界 ほぼここだけで素人の状態からDBスペまで取れたよ それはそれとして本も面白い
155 24/01/13(土)16:59:20 No.1145778370
>初心者でもいいよって言われる現場は生で言語触ることはまずないと思っていいんじゃないか >がちがちに組みあがったライブラリをちょろっと呼び出して動作を確認するだけの人員が欲しいだけのケースが多いと思われる 実は自社開発の会社でずっと同じもん作ってちょろっとカスタマイズするくらいだけらしいから 多分そんな感じなんかもしれん
156 24/01/13(土)16:59:27 No.1145778403
>言語は違うかもしれんけど >入門書とか入門サイトとか使った？ >後3ヶ月くらいあるしそれぞれ初級本一冊くらいは読んでおこうかなって思ったんだけど 俺のときは半年座学あってマジの初歩から教わったから入社前はマジでなんもしなかったぜ！
157 24/01/13(土)17:00:00 No.1145778587
>>言語は違うかもしれんけど >>入門書とか入門サイトとか使った？ >横からだけどミック氏のリレーショナルデータベースの世界 >ほぼここだけで素人の状態からDBスペまで取れたよ >それはそれとして本も面白い ありがてぇ 読んでおくわ