今日はわけわかんないかもしれないけれどご容赦を。
今日もお仕事用のシステムづくり。
データベースのSQL投げるとかのプログラムは問題ないんだけれど、
テーブルの設定に悩んでいます。
「正規化」と「取り回しやすさ」の問題なんだけれど・・・。
データベースを使うのに、正規化しすぎて連想配列みたいになっちゃうとかしたら
SELECT文がややっこしくなったりして嫌だし、
かといって、テーブルが融通のきかない構造になっちゃって
あとからALTER文乱発ってのも怖いし・・・。DROP文はもっと怖いし。
今日はテーブル構成を考えて紙の上でどうしようか考え込んでいました。
結局、前の職場で組んでたときのプログラムの形式が無難かな？と言った感じです。
あとは多数のアカウントを扱うのでセキュリティを
どう確保するかってところでまた考え込んで・・・。
でも、私がプログラム組んでて醍醐味を感じるのはこのへんのことをやってる時なんだな。
コーディングに入ると、資料と実システムの挙動が違ってたりとかしてイライラすることが多いし。
いや、面白くないことはないんだけれど。
出来合いのものを使うときは、どうしても裏技的な手法を思いつくかどうかがヤマになるし。
まあ、まだまだ実力が足らないってことでしょうか。
そんな合間に、グローバルIPを一個確保。高かったです。
さあ、気合が入ってきました。
こんばんは。
帳票とかOLAP用に正規化崩しとかもしますが、どんな用途のテーブルなのでしょうか。
でもやっぱり、マスタなら正規化していたほうが綺麗ですよね。正規化したテーブルを作って、参照用に崩したテーブルを別に作るとか。バッチとかで整合性を保つ面倒もありますが。
＞ブルーバード さん
こんばんは。
うわ、玄人っぽいツッコミですね。
PDFで帳票吐かせるためのテーブルです。マスタ兼用。
振替伝票の要素ごとにレコードを確保して、その関係を別テーブルで管理。
あと、勘定科目を収めたツリーのデータのテーブルが主な内容です。
まあ、集計も財務諸表を作るだけなんでそうややこしいものではなく、
入力の時にある程度加工して収めるようになってます。
問題は、PDF吐かせる時にサーバーの制限時間内に処理が終われるかどうかです。
300秒の制限との闘いです。
終わらないようだったら、あらかじめ途中まで処理しとくか何かすればいいかなと考えてます。
とすると、別にテーブルが必要になるというわけで、サーバーの能力を実際に計算させて見積もらないといけないなというところです。
多分、何とかなる・・・かな？甘いですかね？
わからないですが、伝票作るくらいなら、たぶん大丈夫ではないでしょうか。
大規模なトランザクションの集計とかなら、時間かかりますけど。
＞ブルーバード さん
そうなんですよ。わからないんです。
いっぺんにいくつものアカウントから出力を要求されたりとか、
意表をついて大規模なユーザーさんが現れたりしたら・・・。
って、そんな状態になったらサーバー増強すればいいんですが。
それなのでここしばらくクラウドコンピューティングにこだわっていたのでした。
MySQLのクラスタリングを勉強しとかないと・・・。