- ベストアンサー
MySQLのカラム名の付け方と在庫管理
- MySQLでのカラム名の付け方や在庫管理方法を教えてください。
- 現在、商品ごとに日付ごとの在庫総数を管理していますが、数値を取り出す際に表示形式を変える必要があります。通常、どのようなカラム名を利用しているのでしょうか?
- また、このような在庫管理のテーブルの持ち方は良くない方法でしょうか?アドバイスをいただけますか?
- みんなの回答 (4)
- 専門家の回答
質問者が選んだベストアンサー
> ということは、例えば、商品コード数(商品数)が1000個あるとすると、商品数のカラムが1000必要ということでよろしかったでしょうか? いいえ、違います。 テーブルは ========== CREATE TABLE 在庫管理テーブル ( 商品コード VARCHAR(10), 棚卸し日 DATE, 在庫数 INT ); ========== でOKです。 そしてデータは ========== INSERT INTO 在庫管理テーブル (商品コード, 棚卸し日, 在庫数) VALUES ('商品A', '2016-12-01', 100), ('商品B', '2016-12-01', 100), ('商品C', '2016-12-01', 100); INSERT INTO 在庫管理テーブル (商品コード, 棚卸し日, 在庫数) VALUES ('商品A', '2016-12-02', 90), ('商品B', '2016-12-02', 80), ('商品C', '2016-12-02', 70); INSERT INTO 在庫管理テーブル (商品コード, 棚卸し日, 在庫数) VALUES ('商品A', '2016-12-03', 70), ('商品B', '2016-12-03', 60), ('商品C', '2016-12-03', 50); ========== と言う風に毎日入れていきます。 これで商品数が増えようが、日付が増えようがテーブル構造を変える必要が無くなります。 あとはデータの抽出方法や後処理でどうにでも加工できます。 データの正規化について勉強しましょう。
その他の回答 (3)
- bardfish
- ベストアンサー率28% (5029/17766)
#1さんの補足も含めて、データベース設計が非常に不味いです。 エクセルを多少知っている程度のRDBMS素人が作るテーブル設計の典型ですね。 まず第一に、テーブルにCOLUMNをどんどん追加するというのは、データベースのパフォーマンスを著しく低下させる要因となります。 日次処理かなんかで、データをエクスポートしてテーブルを削除、その後でエクスポートしたデータをインポートするという方法もありますが、好ましくないケースもないわけではありません。 同じように、日々のデータを格納するためにテーブルを新規作成するというのも管理を煩雑にするだけで、後々収集がつかなくなってしまいます。 作るんだったら1つのテーブルに必要な項目を全部入れる。 ・在庫テーブル ・商品コード ・棚卸日 ・在庫数 これが基本なんですよね。 で、このテーブルに貴方がテーブル名にしようとした日付を項目として追加し、商品コードと合わせてインデックスを作成します。 棚卸しって月一とか年一ですよね。 テーブル名にしようとした日付の意味がいまいち理解できませんが、定休日などがあると日付が歯抜けになるでしょ? テーブル名を日付にしてしまったら、存在しない日付のチェックはどうするんですか? 項目に日付があればGROUP BYで日付を羅列できます。 当然ですが、WHEREで抽出条件を指定すれば更に絞り込むことができるし、Betweenを使用すれば日付の範囲指定が出来ます。 エクセルでも、列に対してフィルターを作成し、見えるデータを少なくすることができるでしょ? それと同じようなことがSELECT文ではできるんです。WHERE句やGROUP BY句を駆使すればエクセルでは難しい抽出が可能となり、ORDER BYで並び替えも自由自在。 私はOracleでRDBMSの基本をマスターしたのでMySQLが具体的にどうだかなんてわかりませんが、データベース全体のデータ量が多くなると、いい加減な設計のDBでは簡単な抽出にも数時間かかることもあります。 コンピューターのディスクスペースの利用効率も悪くなる場合があるし、1つの表領域にデータ本体、インデックス領域、テーブルやインデックスなどのシステム管理情報など、全てぶち込むと数年後に大変なことになりかねません。 質問文中に「カラムは永遠に増え続ける」と書かれていますが、作成できるカラム数には上限があるのが普通です。例えば、Microsft Accessのテーブルだとカムラ数は255が上限だったはずです。Oracleも無制限ではなかったはず。 作成できるテーブル数も無限ではありません。 つまり、貴方の思惑は既に破綻しているということになり、運用を開始してから破綻が発覚したら、全て作り直しになるということです。 そうならないためにも、データベース設計はしっかりやっておかないと・・・
補足
bardfishさま、ご回答ありがとうございます。 まさしく、エクセルのにわか仕込みの考えで考えていたら いずれ破たんすることが想像でき、不安でしたので質問させていただきました。 とりあえず、テーブル構造の基本についてお二方様よりご指摘いただたので道筋がはっきりしました。 あと、インデックスのことは、そこまで頭が回っていませんでしたので、とても参考になりました。 本当にありがとうございました!
- t_ohta
- ベストアンサー率38% (5238/13705)
> 日々、このテーブルを作っていくといことで間違いないでしょうか? いいえ、違います。 毎日レコードを作るだけです。
補足
再々で誠に恐縮です。 ということは、例えば、商品コード数(商品数)が 1000個あるとすると、商品数のカラムが1000必要ということで よろしかったでしょうか? 誠にすいません、よろしくお願いします。
- t_ohta
- ベストアンサー率38% (5238/13705)
そのデータの持ち方だと、日付が増える度にカラムを追加する事になり非効率です。 テーブルには ・商品コード ・棚卸し日 ・在庫数 と言う情報を持たせておくといいでしょう。 これだと棚卸し日がデータなので計算できますから、商品コードと日付で同じ商品の在庫数をSQLで引っ張れ、在庫の増減も簡単に導き出せます。 そして、カラムを増やす必要が無くなります。
補足
t_ohtaさま、早速のご回答ありがとうございます。 1つ確認させてください。 データは、毎日取得するのですが、 1つのテーブルのカラムが「商品コード」「棚卸し日」「在庫数」で 日々、このテーブルを作っていくといことで間違いないでしょうか? 在庫データーベース内 ・20161201テーブル (12月1日のデータ) ・20161202テーブル (12月2日のデータ) ・20161203テーブル (12月3日のデータ) ↓ 日々、テーブル作成 再度で恐縮ですがよろしくお願いしますm(__)m
お礼
t_ohtaさま、何度もご回答いただき、 また、非常にわかりやすいコードまでご提示いただき 本当にありがとうございます。 構造につきましては、イメージがつきました! あとは、レコード数がどんどんと増えるので 検索のスピードが落ちないように、 主キーやインデックスについて勉強したいと思います。 また、データの正規化について、 一から学んでいきます。 また、ご質問させていただくこともあるかと思いますが、 その時は、どうぞよろしくお願いしますm(__)m