質問: '恋するフォーチュンクッキー'; するとこういう感じです。 > > AKB48|恋するフォーチュンクッキー|秋元康|(略)|oricon2014|(略) > > AKB48|恋するフォーチュンクッキー|秋元康|(略)|oricon2013|(略) > > > 何年にランクインしているかがカラムmemoに「oricon0000」の感じで書いてあります。 テーブルsongsには、1曲につき1レコードにしたいのに、いま重複があるのでだめです...。 解消してきれいに作り直したいです。 作り直す方針としては、先日の質問でyonaさんに回答いただいたようにしたいです。 oriconranking2テーブルを以下のように作ろうと思っています。 oriconranking2テーブル id:プライマリーキー song_id:songsのプライマリーキー year:ランクインした年(2017,2016等) このように作り替えるにはどうしたらいいでしょうか? わたしは、 1. テーブルsongsにカラムsongidを作って、rowidを当てる。 2. Pythonを使って、forループでテーブルsongsを1レコードずつなぞる。 3. カラムmemoを見て、それをテーブルoriconranking2に転記する。 4. カラムtitleとカラムartistを見て、いま注目しているレコードと重複していたらそのレコードを削除? とかってやったらできるかな?と思うんですが、重複を解消する方法を考えていたら混乱してきました...。 SQLのほかにはPythonならすこし使えると思います。 お知恵を貸していただけたらうれしいです!
回答: > > 重複を解消する方法を考えていたら混乱してきました > > > 困っておられるようなので、 シンプルになるアイディアだけ言ってみてもいいですか。 (SQLは自力で考えてください) **ランキングと曲でテーブルを分ける**のなら、 曲にランキング、ランキングに曲のデータは**不要**なのでは? 曲の方は**JANコード**を使えば重複を排除できます。 ランキングの方はそのJANコードだけ入れるとか。 | ID | 年度 | 順位 | JAN | | --- | --- | --- | --- | | 1 | 2015 | 1 | 123... | | 2 | 2015 | 2 | 456... | | 3 | 2016 | 1 | 789... | | JAN | 曲名 | 歌手 | | --- | --- | --- | | 12345... | 恋しtail? | LoveLoveWomen | 上は単純化したサンプルです。 これがDB設計として良いかどうかともかく、 シンプルなのはシンプルだと思います。 少なくとも、質問の題の**正規化**はしてます。 なお、年度と順位の複合キーが自然ではありますが、 もし、オリコンのランキングが同率2位とかを許すなら、重複するので、 **自動連番**のIDを主キーにした方が確実かもしれません。 > > オリコンには関係なく、いろんな曲の情報を入れたいです > > > それならむしろ、**JANコードが主**で、ランキングの方を従、 と考えた方が、シンプルになりそうです。 アプリの**ドメイン**が、ランキングなのか、CD全体なのかの違いです。 かりに、本やゲームもDB化するなら、たとえば、AmazonのASINでもいいわけです。