SaaSがもてはやされるようになっています。
どんな素晴らしい仕組みかと思いますよね。実際、中身は私なんかには、想像もつかないくらい凄い技術の塊なのでしょうね。
ちなみにSalesforceを使ってみた感想は、「えっ、これがSaaSなの？」（失礼しました。）別に作ろうと思えば、わたしにも作ることができると思ったわけでした。
サイボウズが登場したときも、blogが登場したときも、常に後でそう思っている「情けない私」ですからねえ。
今回もその口なんでしょうかね。
もっとも、「もの好き」を売り文句にする私としては、当然、作りたくなってくるわけです。
で、早速、設計し始めてみました。
まず、メインのジャーナルテーブルを設計してみました。
・・・
ここで素晴らしいことに「今更ながら」気づきました。
データベースの項目は、大きく以下に分類されることにです。
1. 連番（とにかく順序を表すか、他とは違う番号を表すか）
2. コード（他マスタと関係する）
3. コードの名前（コードで参照される）
4. 区分
5. フラグ
6. 年月日
7. コメント
8. 数値（単価、金額、率・・・）
9. ファイルパス
これでたぶん、ほとんどの項目を網羅できます。
SQL Serverであれば、
1. 連番 → int
2. コード → varchar(20)
3. 名前 → varchar(256)
4. 区分 → int
5. フラグ → char(1)
6. 年月日 → datetime
7. コメント → varchar(512)
8. 数値 → decimal(13,2)
9. ファイルパス → varchar(100)
これで基本設計終わりです。
なんて「ずぼら」なのでしょうか。
でも、実際、得意先コードはchar(8)、商品コードはchar(13)などと考えて確認して設計する必要あるんですかね。いまどき。
「大は小を兼ねる」
もし、成長するシステム、拡張性があるシステムを作るとしたらこんな風に割り切って、各項目の分類ごとに10とか15ずつのテーブルを作成しておいたほうが何でもできます。
もちろん、大容量の「パフォーマンスチューニング」が必要なシステムには向きません。
でも、中小企業ならほとんど、これでOKじゃないでしょうか。
だって、CPUが“Xeon”なら、CPUコアを4つ搭載した“Quad-Core CPU”、メモリが“2ギガバイト”なんていうスペックのサーバーですよ。
設計をこのくらいアバウトにしてもOKですよ。
でも「良い子はこれを鵜呑みにして真似しないでくださいね」（ちゃんと断っておかないとね！）
わたし的に忙しいので今回はこんなところで、オシマイ。
来週は、区分とフラグについての杉山的見解を話します。
Vol.00163