・エ・)抽象クラスのことを気にしだしたら、テーブルを作るクラスの継承関係にも気になりだし、関係をしっかりさせることにした。
ストア度プロシージャのできないことは、DB同士のデータの橋渡し。
せっかく外部のアプリケーションから、DBのデータを操作するのだから、目的に会わせてDBを分けて使おう。
外部に公開するつもりは全くないけど、もし、外部にさらすのであれば、セキュリティ的にもその方がいいはず。(ただ、PostgresqlにDB単位でアクセス制御できるのかは調べてないw)
ます、一番上のabstractクラスにDataBaseとでも名前をつけて、後は、何も書かない。(子クラスでいるなぁ、って思ったら追加してけばええw)
源泉となるデータの入っているデータベースに接続するコードが書かれているクラスにSoruceDBと名前をつけてDataBaseを継承する。そのあと、Chartを作るのに必要なデータを保存するデータベースに接続するコードが書かれているChartDBを作成して、SoruceDBを継承する。次は、ChartDBのデータを参照して、データを判断した結果を保存するデータベースに接続するコードの書かれたAnalysisDBクラスを作って、ChartDBを継承する。
したに行くほど継承されることでコードの量が多くなるが、まぁ、関係としてはこんなもんだろう。
なんかすっきりした。
ストア度プロシージャのできないことは、DB同士のデータの橋渡し。
せっかく外部のアプリケーションから、DBのデータを操作するのだから、目的に会わせてDBを分けて使おう。
外部に公開するつもりは全くないけど、もし、外部にさらすのであれば、セキュリティ的にもその方がいいはず。(ただ、PostgresqlにDB単位でアクセス制御できるのかは調べてないw)
ます、一番上のabstractクラスにDataBaseとでも名前をつけて、後は、何も書かない。(子クラスでいるなぁ、って思ったら追加してけばええw)
源泉となるデータの入っているデータベースに接続するコードが書かれているクラスにSoruceDBと名前をつけてDataBaseを継承する。そのあと、Chartを作るのに必要なデータを保存するデータベースに接続するコードが書かれているChartDBを作成して、SoruceDBを継承する。次は、ChartDBのデータを参照して、データを判断した結果を保存するデータベースに接続するコードの書かれたAnalysisDBクラスを作って、ChartDBを継承する。
したに行くほど継承されることでコードの量が多くなるが、まぁ、関係としてはこんなもんだろう。
なんかすっきりした。
コメント