SQL質疑応答スレ 19問目
■ このスレッドは過去ログ倉庫に格納されています
このスレは
「こういうことをやりたいんだけどSQLでどう書くの？」
「こういうSQLを書いたんだけどうまく動きません＞＜」
などの質問を受け付けるスレです。
SQLという言語はISOによって標準化されていますが
この標準を100%実装したDBMSは存在せず、
また、DBMSによっては標準でない独自の構文が
追加されていることもあります。
質問するときはDBMS名を必ず付記してください。
【質問テンプレ】
・DBMS名とバージョン
・テーブルデータ
・欲しい結果
・説明
前スレ：
SQL質疑応答スレ 18問目
https://mevius.5ch.net/test/read.cgi/db/1515071542/ 普通DBの参照権限は貰えても更新権限は与えないよね。 そうだね
Excelで扱うデータを引っ張るような業務レベルだと
テーブル更新権限までは持たせないと思う >>114->>116
そうですか…
せっかくスキルを身に着けたとしても、更新権限が付与されないのであれば意味がないですね。
おそらく管理者に確認しても、余計な事するな、となりそうなので
ただSQLの知識はあっても損はないので、買った本くらいは通読してみようかと思います。 ぶっちゃけ、そのヤろうとしてることはクラッキングだからな
管理者の許可を得ず、データにアクセスして改竄 家のPCでSQLSERVERとかPostgreSQLとか構築してみたら勉強になる
めっちゃ簡単だし >>119
そんなことをしなくても、Excelシートをリレーショナルデータベースとして扱える。 unique cnstraintに引っかかるとエラーが帰ってくるの？ このエラーをtry exceptで例外処理して重複するのを防ぎたいんだけど
commitしないとエラーがでなくて
毎回addする毎にcommitするしかないですか？ >>127
普通はコミットするまでにエラーがでると思うが
使ってる言語かDBMSのスレで聞け 売上を記録するテーブルの設計について教えて下さい。
例えば商品マスタが以下の構造だとします。
----------------------------
| 商品コード | 商品名 | 単価 |
----------------------------
販売履歴を記録するテーブルは、
-----------------------------------
①| 商品コード | 商品名 | 単価 | 数量 |
-----------------------------------
と、
--------------------------
②| 商品コード | 単価 | 数量 | ※商品名は、商品コードをキーにしてマスタから取得
--------------------------
と
-----------------------
③| 商品名 | 単価 | 数量 | ※商品コードは、商品名をキーにしてマスタから取得
-----------------------
の3つのどれがいいのでしょうか？
②の場合、販売後に商品コードが変わると、販売時の商品名が分からなくなり、
③の場合、販売後に商品名が変わると、販売時の商品コードが分からなくなるので、
①が一番いいのかな、と思うのですが、本当にそれでいいのでしょうか？ 普通1だし、商品名変わったら新しくID発行するだけで上書きはしないよね。 普通は、商品コードと数量だろ?
(属性は足りないと思うけど) その要件なら①で仕方ないと思うが、商品名の追跡が必要なら商品名ごとの
サブコードを発行しておくという手もあると思う。 何のために商品コードがあると思っているんだろうね。 値段の変動するものなら、その時の時価を記録してないと訳分からなくなるかも >>130
ずいぶん遅いレスだけど販売管理ならユーザーによって使い方が変わるからそういった点でも
できるだけ細かい情報を販売実績のテーブルに管理したほうがいいぞ 誰もがいつも表記の揺れのない正確な商品名を打てる世界を想定しなくはいけないのか？ データに全ての情報を埋め込むのは汎用機システム世代
リレーションシップデータベース世代になるとマスターに
できるのはできるだけマスター化する
しかし全てマスター化すると古いマスターもずっと残さないといけなくなりマスターが肥大化してしまうのでデータに埋め込んでおくのもいい場合がある リレーショナルデーターベースとしても意末は通らんけど >>130の商品コードと商品名が関数従属しないんならべつに①も非正規形ではないんだがな ユーザーによっては商品マスタを使いまわすところもあれば商品ごとにマスタを登録するところもある
商品はセール（値引き）以外にも返品なども行う事もおおいから単純にマスタを見て単価や名称を紐づけすればOKなんて考えは
販売管理作ったことのあるやつならナンセンスじゃね
請求書や領収書なんかも変わった商品名称や単価だすとかありえんしね テーブル設計の話題は 「DB設計を語るスレ」 でやってください プライマリキーが無くてもいいテーブルがあるDBは設計が間違ってる。 tempテーブルのこと言ってんでしょ？
それならプライマリキーなくても別に構わないよ えっ、temporaryテーブル(一時テーブル)のことだよ SQLスレにいるのにテンポラリテーブルも知らないのかw SQLの仕様に、テンポラリテーブルってのが有るのか・・・ 一時テーブルという機能を持つDBMSはあるが、一時テーブルだとプライマリキーが要らない
理由なんてないよなぁ。 意味的なプライマリキーと
DBMSのPRIMARY KEY制約がごっちゃになって話が混乱してるな >>164
逆に一時テーブルの機能を持たないRDBMSってあるのかい？ Oracleは18cまでまともに使える一時テーブルがなかったのね
いろいろと納得 最初は中間テーブルって話だったのにいつの間に温度テーブルの話にすり替わったのか >>166
それが混同されたとしても一時テーブルは関係ないわ SQLのスレなんで、DBMSの実装機能の話は無いのかと思ってたが,そう言うことか テンポラリテーブルはSQL-92で定義されてる標準だぞ
各実装が従ってるわけではないけど inner joinの前と後のテーブル入れ替えても同じ意味になりますか？ >>176
同じ意味というのが
同じ結果セットが得られるかということならイエス
同じ実行プランが得られるかということなら必ずしもそうはならない あ、inner join on x.id <> y.id のように不等号とか使ったら結果セットも変わるわ 二つのテーブルの内部結合なら不等号だろうが結果セットは変わらん気がするが
もちろん列指定ちゃんとやるって前提だが べつに文句を言っている訳ではないよ
順序に期待するならそこまで考慮しようねって事 同じSQLですら結果の順序がどうなるかわからんのにinner joinの結合順で結果の順序とか言い出す奴って… >>183
そういう基本的なことからわかってないのにデタラメを言うやつは年齢関係なくいるから困るよね。 このスレでの話ならスルーしてれば何も困らないだろう
職場にいるんなら、それはお前がどうにかしろ
こんなとこで愚痴るなよ、鬱陶しい 2020みたいな西暦って
integerかstr かtimeのどれ型を使うのが一般的ですか？ そうすか ありがとうございました
int ならorder by できますからね >>188
最近はDate型にして月日には1月1日入れてる 日付形式にすると日付ではない値は
セットできないのでデータ整合性が
保てる
日付形式で困るのは最大値だな
データベースによって違うから
日付数字８桁なら99999999とかに
すればいいけど 西暦はゼロ年、1年の扱いの違いもちょっと困ることがある 年だけをどのデータ型にするのがいいのかは
利用方法、DBMSの種類、件数、(もしあれば)規約などによる
一般的にはint, smallint, dateが候補だけど
MySQLのようにyear型があればそれも選択肢になるし
Oracleならdateは7バイトも使うのであまり選ばれない
個人的には年だけ表現したいのに関数使わずに見ると
2020/01/01って入ってるのは嫌なのでsmallintが第一候補
過去の西暦とか入力できる範囲も違うから必要ならチェック制約使う 1月2日とかが入るのを完全に排除できるならいいけど、それやるのにトリガとか使うくらいならintでいいよね。 >>198
数バイトが積み重なってレコード長が大きくなればパフォーマンスが徐々に悪化するからね 日付形式は検索するとき数字形式より遅くなる場合が多い
日付形式を検索するとき関数を使う場合が多く関数ある分遅くなる
例えばこんな感じ
Where TO_CHAR(sale_date, 'YYYY-MM-DD') = '1970-01-01'
俺は月次単位でデータを作る事が多く検索で多く使うから
年月は数字6桁でインデックス貼ってるな
年月は他のテーブルと連結する時も多く使われるので
後で変更する場合非常に面倒なのでよく考えたほうがいい
日付形式はデータ作成日時とか更新日時のではよく使う
パフォーマンス問題を引き起こす日付型
https://use-the-index-luke.com/ja/sql/where-clause/obfuscation/dates 日付型って内部は数値形式でしょう
比較したり順序を決めるのに文字列にする必要は無いんじゃないかな OracleにはSQL-92 DATEが無かったからそんな感じだったな。 >>201
知らなかった感じ？
SQL使うだけなら知らなくていいけど
DB設計するなら基礎の基礎だから知っておくといいよ とりあえずここはSQLのスレであってDB設計スレではない
そのことをまず知っておこう 物理メモリもストレージ容量も大きいのに少しのことを大袈裟に言うやつは引退した方がいい。
ハードウェアの進化に知識が追いついていない。 >Where TO_CHAR(sale_date, 'YYYY-MM-DD') = '1970-01-01'
こういうダメな例を書かないためには
SQL使うだけのやつもDB設計の基礎知らないといけないんじゃないか？ 自分の設計能力の低さをハード性能でカバーされてることに気づかないやつも引退したほうがいいけどな >Where TO_CHAR(sale_date, 'YYYY-MM-DD') = '1970-01-01'
確にこれは初心者 ON DUPLICATE KEY UPDATEのIF文について質問させてください
ON DUPLICATE KEY UPDATE
fb_like = IF(fb_like > VALUES(fb_like), fb_like, VALUES(fb_like))
このIF分の第二と第三の引数と戻り値の意味を教えて頂けないでしょうか。
第一は比較条件なのは分かりますが・・・
DUPLICATE KEY UPDATEのリファレンスを調べてもわかりませんでした・・・ >>203
普通に考えて第２引数は条件が真の時に返す値で第３引数は偽の時に返す値でしょ
てか答え書いてあるだろ
> 取得した数字がレコードの数字より大きければ更新
https://qiita.com/yuzroz/items/f0eccf847b2ea42f885f ■ このスレッドは過去ログ倉庫に格納されています
