MariaDB PR

初心者がテーブルにCSVデータをインポートしたけど思った表示にはならなかった

SQL文
記事内に商品プロモーションを含む場合があります

 

FTPサーバーを立ち上げデータの移動は完了したので、今度は移動したデータをMariaDBにテーブルにインポートしてみた。

 

データをラズパイ側に移動したおかげで、インポート自体は実行することができたが、何だかワーニングが発生し、しかも全数が対象だった。

インポートした結果、データ形式とテーブル形式が微妙に違っていたので、ワーニングが発生したようだ。

やっぱりやる事が素人なんで、所々でトラブルが発生するよね。

そんなデータをインポートしたのだけれど、期待した内容でデータが格納されていなかった事について今回は紹介しよう。

 

CSVデータをインポートする

さて、前回はWindows側にあったCSVデータをインポートしようとしてエラーとなったため、FTPサーバーを立ち上げてラズパイ側にデータを移すことに成功した。

次はいよいよラズパイ側に有るデータをMariaDBのデーブルにインポートするんだ。

 

それでは実際にやっていこう。

前回も記述したかもしれないが、CSVデータをテーブルにインポートするSQL文はload dataになる。

従って、SQL文としては以下の通り。

load data local infile "/home/jkawasaki/numbers3jnb.csv" into table result fields terminated by ',' OPTIONALLY enclosed by '"';

今回は自分のホームディレクトリにデータを格納したので、/home/jkawasakiがファイルのパスになる。

それでは実際にSQL文を実行してみよう。

MariaDB [numbers3]> load data local infile “/home/jkawasaki/numbers3jnb.csv” into table result fields terminated by ‘,’ OPTIONALLY enclosed by ‘”‘;
Query OK, 519 rows affected, 2077 warnings (0.058 sec)
Records: 519 Deleted: 0 Skipped: 0 Warnings: 2077

 

前回と違い、SQL文自体の間違いは無く無事実行されたためQuery OKと言う表示がでました。

しかし、その後の結果表示が非常に気になりました。

Records: 519 Deleted: 0 Skipped: 0 Warnings: 2077

 

結果としては、519のレコードがあり、削除は0、スキップも0、しかしWarningsが2077も発生しているのです。

どういう事?って思いますよね。

考えられるのは、データのインポートは519レコードできたけど、インポートした内容に誤りが2077発生していると言うことだろう。

 

 

インポートしたCSVデータを確認してみた

とりあえずテーブルが、どんな内容になっているのかを確認をする必要があるよね。

と言う事で、データがインポートされたテーブルの内容を確認してみることにした。

テーブルのデータを確認するにはSELECT文を使用する。

今回は、インポートしたデータ全部を確認したいので、SQL文は以下の通りになる。

select * from result

全項目対象なので*となりresultはテーブル名だ。

MariaDB [numbers3]> select * from result;

実行した結果は以下の通り。

+——+——-+————+——-+——-+——-+
| id | kaisi | hizuke | 3digi | 2digi | 1digi |
+——+——-+————+——-+——-+——-+
| 1 | 2023 | 0000-00-00 | 4 | 4 | 0 |
| 5664 | 2021 | 0000-00-00 | 1 | 5 | 0 |
| 5665 | 2021 | 0000-00-00 | 5 | 3 | 0 |
| 5666 | 2021 | 0000-00-00 | 4 | 2 | 0 |
| 5667 | 2021 | 0000-00-00 | 1 | 1 | 0 |
| 5668 | 2021 | 0000-00-00 | 8 | 4 | 0 |
| 5669 | 2021 | 0000-00-00 | 7 | 8 | 0 |
~                   ~
| 6165 | 2023 | 0000-00-00 | 7 | 4 | 0 |
| 6166 | 2023 | 0000-00-00 | 4 | 4 | 0 |
| 6167 | 2023 | 0000-00-00 | 3 | 4 | 0 |
| 6168 | 2023 | 0000-00-00 | 3 | 2 | 0 |
| 6169 | 2023 | 0000-00-00 | 6 | 1 | 0 |
| 6170 | 2023 | 0000-00-00 | 7 | 5 | 0 |
| 6171 | 2023 | 0000-00-00 | 3 | 7 | 0 |
| 6172 | 2023 | 0000-00-00 | 2 | 8 | 0 |
| 6173 | 2023 | 0000-00-00 | 2 | 5 | 0 |
| 6174 | 2023 | 0000-00-00 | 8 | 4 | 0 |
| 6175 | 2023 | 0000-00-00 | 2 | 1 | 0 |
| 6176 | 2023 | 0000-00-00 | 3 | 7 | 0 |
| 6177 | 2023 | 0000-00-00 | 2 | 0 | 0 |
| 6178 | 2023 | 0000-00-00 | 3 | 9 | 0 |
| 6179 | 2023 | 0000-00-00 | 9 | 4 | 0 |
| 6180 | 2023 | 0000-00-00 | 0 | 9 | 0 |
| 6181 | 2023 | 0000-00-00 | 1 | 1 | 0 |
+——+——-+————+——-+——-+——-+
519 rows in set (0.004 sec)

これではワーニング表示がでるよね。

CSVデータの最初の列は開催回数となっているが、テーブルではIDとなっている。しかもIDは1から始まり自動で加算していく指定になっている。

ここでまずはアンマッチとなってしまっている。

従って、開催日のと列には2023だけ入り、それ以降に残りのデータがずれて入っている。

従って、1桁目(1digi)の列は全て0になってしまっているんだ。

と言う事で、素人がCSVデータをインポートしたらお粗末な結果になってしまった。

 

これを解消するには、一度テーブルを削除してもう一度テーブルを作り直してから再度CSVデータをインポートすることになる。

はぁ~、やっちまったよ。

 

 

初心者がテーブルにCSVデータをインポートした まとめ

素人がCSVデータをテーブルにインポートしてみたのだが、テーブル書式とCSVデータ書式が合っていなかったので、テーブルのデータは欠落し使い物にならなかった。

こうなった理由としては、テーブルは参考書を見ながら勝手にテーブル構造を作った。

この時、CSVデータの構造を確認しなかったことが一番の原因で、この時にCSVデータの構造をチェックして、それに合わせれば良かった。

 

まあこれも良い経験として、テーブルを作る手順としては

  1. CSVデータ構造を実際に紙に書いて見える化をする
  2. 見える化したデータを元に、テーブル構造を検討する
  3. テーブル構造をSQL文に置き換えテーブルを作成する

 

やはり何事も見える化することが重要であることを、ここでも再認識しました。

 

次回はこの手順に沿って、もう一度テーブルを作り直しから始めます。

スポンサーリンク



 

 

スポンサーリンク