SQL質疑応答スレ 19問目
■ このスレッドは過去ログ倉庫に格納されています
このスレは 「こういうことをやりたいんだけどSQLでどう書くの?」 「こういうSQLを書いたんだけどうまく動きません><」 などの質問を受け付けるスレです。 SQLという言語はISOによって標準化されていますが この標準を100%実装したDBMSは存在せず、 また、DBMSによっては標準でない独自の構文が 追加されていることもあります。 質問するときはDBMS名を必ず付記してください。 【質問テンプレ】 ・DBMS名とバージョン ・テーブルデータ ・欲しい結果 ・説明 前スレ: SQL質疑応答スレ 18問目 https://mevius.5ch.net/test/read.cgi/db/1515071542/ >>102 複合列の一意制約の構文だろうけど、どのRDBMSかは俺もわからない。 >>98 は、見方によってはaとbの中間テーブルだがな ものすごく初歩的な質問すいません。 会社の業務で、OracleのデータベースからVBAを使って、データを取得しているようなのですが、この逆って出来るのでしょうか? 大量のExcelデータをVBAを使って、データベースを一気に書き換える、ようなスキルを身に付けたいと思っています。 また、このようなスキルを身に付けるにあたって、分かりやすい参考書のような書籍などありますでしょうか? 一気に書き換えるってことは DeleteしてInsertかな? ODBC接続してSQL発行すれば良いのでは >>109 古いExcel VBAの逆引き本に書かれている。ただ、正解はないのでどれが最適なのかは深く考えないこと。 >>110 ->>112 レスありがとうございます。 権限というのは、データベースに接続するためのID/PASSでしょうか? Oracleのデータベースからデータを引っ張ってくるVBAの記述を見ると、「ID」「PASS」の 文字列があるので、これを利用できそうです。それともデータベースというのは ID/PASSを知っているだけでは足りず、責任者の承認のようなものが一般的に必要と なるのでしょうか? 「ODBC接続」「SQL発行」というのが、今目指していることのキーワードとなるようですね。 古い本に載っているそうですが、最新のものはありませんか? それともネットのプログラミング講座を受講するのが早いでしょうか? 質問ばかりですいません。 よろしくお願いします。 >>113 そのID/PASSがテーブルを更新する権限があるかどうかが問題 てか、マジでそのデータベース管理してる人にそんなことして良いのか確認しなよ ヘタこいてデータぶっ壊しましたテヘペロ で済むならいいけど 普通DBの参照権限は貰えても更新権限は与えないよね。 そうだね Excelで扱うデータを引っ張るような業務レベルだと テーブル更新権限までは持たせないと思う >>114 ->>116 そうですか… せっかくスキルを身に着けたとしても、更新権限が付与されないのであれば意味がないですね。 おそらく管理者に確認しても、余計な事するな、となりそうなので ただSQLの知識はあっても損はないので、買った本くらいは通読してみようかと思います。 ぶっちゃけ、そのヤろうとしてることはクラッキングだからな 管理者の許可を得ず、データにアクセスして改竄 家のPCでSQLSERVERとかPostgreSQLとか構築してみたら勉強になる めっちゃ簡単だし >>119 そんなことをしなくても、Excelシートをリレーショナルデータベースとして扱える。 unique cnstraintに引っかかるとエラーが帰ってくるの? このエラーをtry exceptで例外処理して重複するのを防ぎたいんだけど commitしないとエラーがでなくて 毎回addする毎にcommitするしかないですか? >>127 普通はコミットするまでにエラーがでると思うが 使ってる言語かDBMSのスレで聞け 売上を記録するテーブルの設計について教えて下さい。 例えば商品マスタが以下の構造だとします。 ---------------------------- | 商品コード | 商品名 | 単価 | ---------------------------- 販売履歴を記録するテーブルは、 ----------------------------------- @| 商品コード | 商品名 | 単価 | 数量 | ----------------------------------- と、 -------------------------- A| 商品コード | 単価 | 数量 | ※商品名は、商品コードをキーにしてマスタから取得 -------------------------- と ----------------------- B| 商品名 | 単価 | 数量 | ※商品コードは、商品名をキーにしてマスタから取得 ----------------------- の3つのどれがいいのでしょうか? Aの場合、販売後に商品コードが変わると、販売時の商品名が分からなくなり、 Bの場合、販売後に商品名が変わると、販売時の商品コードが分からなくなるので、 @が一番いいのかな、と思うのですが、本当にそれでいいのでしょうか? 普通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日入れてる 日付形式にすると日付ではない値は セットできないのでデータ整合性が 保てる 日付形式で困るのは最大値だな データベースによって違うから 日付数字8桁なら99999999とかに すればいいけど 西暦はゼロ年、1年の扱いの違いもちょっと困ることがある 年だけをどのデータ型にするのがいいのかは 利用方法、DBMSの種類、件数、(もしあれば)規約などによる 一般的にはint, smallint, dateが候補だけど MySQLのようにyear型があればそれも選択肢になるし Oracleならdateは7バイトも使うのであまり選ばれない 個人的には年だけ表現したいのに関数使わずに見ると 2020/01/01って入ってるのは嫌なのでsmallintが第一候補 過去の西暦とか入力できる範囲も違うから必要ならチェック制約使う 1月2日とかが入るのを完全に排除できるならいいけど、それやるのにトリガとか使うくらいならintでいいよね。 >>198 数バイトが積み重なってレコード長が大きくなればパフォーマンスが徐々に悪化するからね ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる