---

新しい名前を考えるのもめんどくさいし「オーケストラ楽曲データベース」みたいなの方が分かりやすいので、正式名称はこれにします。
が、長ったらしいのでコードネームはMuselのままにします。気に入ってるんだよ悪いかよ


まず、今回の開発で意識すべきポイントとしては、以下の3つを提唱します。


1.GUIによる管理操作を可能とする
2.容易に拡張可能なデータベース
3.オブジェクト指向をがんばる
4.ユーザー登録の切り離し


(1)の意味するところはデータベースの作成までもがGUIで可能にするということです。
ただ、実際のとこはデータベースをポコポコ作られたら困るので管理者(つまり私)のみに認可することになりますが、将来性を見据えて拡張可能なテンプレートにしなくてはいけませんね。たぶん役に立つことはないと思っていますし、僕自身にもその予定はないんですけど、あくまでも技術練習として。

構造としてはこのようなものを考えています。




これは(2)の話になるのですが、親にクラシックというデータベースを置きまして、その中のテーブル群にて具体的なデータを記述する構成です。
これにより共通のデータを持つ複数のデータベースというのが再現できるわけですね。
この構造で何がしたいかというと、例えばオケと室内楽のデータベースを2つ作りたいなぁと思った時、どう考えてもブラームスはどっちにも出現するので、親となるデータベースの中に格納してしまいましょうと。
ちなみに、ブラームスの室内楽は割と好きですが交響曲は嫌いです。弾いてて泥臭い。（笑）

スレーブ側は別にテーブルじゃなくてもいいんですけど、1つのシステムは1つのデータベースに入ってた方が見やすい気がして、接頭辞＋テーブル名みたいな感じでやればいいかなぁとか思ってます。まぁ、設計的にはあんまり宜しくない感じもしなくもないですけど。
GUIで生成したりってのを考えなかったら、参照先テーブルとかやっちゃってもいいんですけど、Laravelのシステムファイルの中に書き込まないと参照するデータベースを設定できなさそうなので、Laravelを使っている時点でスレーブDBみたいなものを作るのは厳しいです。不可能じゃないですけど、嫌な予感しかしないのでやめた方がいいと思います。（笑）


Laravelではスキーマビルダーというのを用いれば、データベースやテーブルが作成できるので、その辺をGUIでやれるようにしたいですね。



(3)は言わずもがな。オブジェクト指向に関しては、数をこなすしかありません。
ただ、Laravelで複数のクラスってどうやって扱うんだろう･･････なんか以前為した時ろくに動かなかった気がするんで、単なるclass列挙じゃダメっぽいですね。もうちょっと仕組みを調べないと。
Anonymousを作ってた時、例えば認証みたいな、後で弄ることはそんなない癖にほぼ全てのページで使うような機能なんかはマスタークラスみたいなとこに追いやってしまいたいなぁみたいなこと考えてました。


で、最後に(4)ですね。これはシステム開発の先駆けとして複数のシステムに共通するユーザー認証というのをやってみたいなと。
ただ、ここまで書いて思ったんですが、データベースが途中で増やせるようなシステムの場合、ハードコーディングが不可能なので標準のシステムだけじゃどう頑張っても実装不可能ですね。
ということで、認証システムを切り離し、そこにアクセスするAPIを書くか、あるいは認証周りだけは自作･･････ということになりそうですね。うわぁめんどくさいハードル上がったなぁ･･････。



全体をまとめると、とにかく拡張性あるシステムを設計しようという目標に基づきます。
こいつの設計はだいぶしんどいですけど、とりあえずゴリ押しプログラミングはやめた方がいいですね。しばらくは紙にお絵かきしてます。






･･････と、ここまでは実は数日前に書いていたんですが(笑)よくよく考えてみたらクロスシミュレーション使うのはオケだけだし拡張性とかなくて良くねという結論に達したので、あんまり拡張性は意識しないで作ろうかなぁとか思ってます。（笑）


吹奏楽は経験ないのでわかんないですけど、吹奏楽の場合は曲目がいっぱいなので、組み合わせとかクロスじゃ考えないと思うんですよね。オケの場合は基本、メイン1曲サブ2曲っていうテンプレがあるんですけどね。演奏時間が1時間近い交響曲と、十分弱で終わるような序曲とか組曲とか2曲っていう組み合わせです。なのでクロスシミュレーターなんてものが存在するんですよね。


ただ、検索部分とリスト絞り込み検索は他のデータベースをもし作るなら流用できそうだなぁとかは思ってますけどね。現時点では僕自身がデータ集めたくないので予定ないですけど。システムにしちゃってもいいかもですよね。




ちなみに現時点ではこんな感じです。横幅を大幅に抑えました。
横幅の基準はA4用紙の横向き印刷のサイズに合わせてます。一応1550pxにしてます。余白とか考えなかったらもっと拡張できそうですけど、Chromeの規定に合わせた形です。まぁ、pdf生成機能は将来的につけるつもりではありますけど。


スマホでのデザインとか変えてみるのはどうなんだろうとか微妙に思ってるんですが、やっぱり編成表検索として使われるのがメインだし、編成表である以上どうしても横幅は必要になるので考慮しなくてもいいかなぁ･･････とか思ったりして。



とりあえず、こんな風に現行のシステムを微調整するところから初めています。



あ、ちなみに荒らし対策は1つ提案があります。ロールバックです。
よくよく考えたら、各ページのデータって1つのレコードで表現しているんですよね。なので、更新時に更新前のレコードをログのテーブルに挿入していけば、履歴が保存できるわけです。
なので、ページが荒らされたらそのログからデータを取ってきて取り替えてしまえば良いわけですね。
で、こいつも悪戯される可能性を考えて、過去の履歴は消さない･･････つまり、ロールバックも更新の一種として取り扱うことですね。
こうすることで、とりあえず善良なデータが「消えることはない」という状況が作り出せるので、ひとまずは及第点でしょう。