- - PR -
自社開発グループウェアの設計のトレンド
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2008-05-13 11:12
いつも楽しく拝見させていただいております。
今回相談ごとのような形になるのですが、皆様にアドバイスをいただきたく投稿しました。 弊社は自社開発のグループウェア（サイ○ーズのようなもの）を持っているのですがそれの機能拡張に伴い、技術的にもいろいろ新しいものを取り入れようとしています。 そこで、特に営業資料的な報告書類（特定の項目（ただし報告書ごとに項目は違う上に変更の機会がある）テキスト＋画像）をそのシステムを通じて作成⇒印刷しているのですが、こういう場合、作成方法やデータ保持としてはどういったものがよいのでしょうか？ 今までは、PHP＋postgreSQLというよくあるパターンで開発しています。 状態としては、 サーバーサイドはLinux apache2 PHP5.2 文字コードUTF-8 PostgreSQL8 イントラネットでクライアントは100%IE7で、作成頻度としては１日数十枚程度のデータ量です。 項目変更機会が多いので（とはいっても１〜２ヶ月に一回程度）、そのたびにDBのカラムを変更し、ソースを変更という作業になるのですがもっとよいやり方はないものかという状態です。 今回の部分に関しては、社員は全員PCが利用できる若手です（エクセルでCSV等で作れと言ってもできる程度 当然開発者レベルではありませんが・・・） インターフェースから入力⇒DB登録ではなく、データ作成する形式をXMLやJSON形式で作成させて⇒システムにアップ⇒データ保持は元データ形式なども考えてはいますが・・・ 抽象的で申し訳ありませんが、今後こういうものがいいよ的なことでもかまいません。どうぞアドバイスのほどよろしくお願いいたします。 | ||||
|
投稿日時: 2008-05-13 22:29
そうですね。抽象過ぎて答えようがないですが。。。
まあ、XML&SOA会議室に投稿しているので （トレンドかなんか知らないですが。まあホットですが） SilverLightなんかかっこよさげですが。。。 | ||||
|
投稿日時: 2008-05-14 08:56
おはようございます。
新しい技術の導入が目的ですか？ それとも、現状で感じている問題点があって、 それの解決のために、今まで利用していない新しい技術の導入を含めた 改善案の検討をしたいということでしょうか？ このレス内容だけではあまり情報量として意味がないので… 私なら、真っ先にDBのカラム変更が極力起こらないようなテーブル構成にしたいなと考えます。 または、カラム変更が避けられないのなら、それによるソース変更ができるだけ少なくなるように考えます。 いま提示なさっている情報からは、私はそのような方向で考えます。 | ||||
|
投稿日時: 2008-05-14 09:00
>indigo-x様
お返事のほうありがとうございます。 昨日1日いろいろ見ていましたが、まあ、PHP＋apache＋DBで作るというのが今のところ硬そうですね・・・。 データを作成する際に全体を見ながら作成したいと思うので、CSVかテキストか、そういうものでデータ作成させて・・というのを考えてはいたのですが、画像ファイルがあるので、どうしてもブラウザ上で作らざるを得ないんですね・・・。ここをなんとか解決したいなぁと思っていたのですが・・・。 印刷物と同等のインターフェースでWEB画面を構築して入力させる路線（今までと同じですが・・・^^;）で今のところ設計に入ります・・・。ありがとうございました。 ＞SilverLightかっこいいですね。ちょっとダウンロードしてみたりしようと思います。 | ||||
|
投稿日時: 2008-05-14 09:13
＞未記入X様
お返事ありがとうございます。 今現状の問題というのは、その報告書のフォーマット（項目の増減）の機会が多いので、その際に、過去に作ったものとこれから作るもの等を考えながらという、開発側の負担が大きくなってきているというのが現状です。 /************************* 項目A テキスト 項目B テキスト ＋ 画像 項目C テキスト /************************ という入力フォーマットがあった場合、「6月からは項目Aはなしでいこう」とか「項目Cに画像が張れるようにして、項目Dを増やして」等・・・また、変更後の過去のフォーマットで出してくれ等が飛んできたりと（もちろんそういうときのためにAのカラムは消さないですが、そうなると、DBのテーブル設計図が非常に煩雑になるんですよね。こういう状態で1年も2年もまわしていると・・・特に新人にDBの状態を教えるときに、これは今はつかってないんだけどね、みたいな会話をするのが切ないというか）・・・。 まあ、仲が悪いとかそういう問題ではないので、それはその都度もちろん気前よく対応しますが、こういうときに、便利な技術というか、やり方等も踏まえてあるのではないかという、そういう状態です。 大変抽象的な質問で大変失礼しました。 設計資料等、全体を見えるようにする努力を怠らないが正解かもしれませんね・・・。 | ||||
|
投稿日時: 2008-05-14 11:30
技術的に新しいモノってあたりには疎いのですが、少ない作業で変化に耐えられるシステム作りには興味があります。
入力のユーザーインタフェースについては、スキーマ(XMLスキーマやDBスキーマ)を元に入力画面を自動生成する仕組みにしておくと楽できそうですね。 例えば、MSのOfficeの一つにInfoPathという製品がありますが、XMLスキーマやWSDLから入力フォームを自動生成できます。もちろん、スキーマに定義されている通りに、型に合った入力コントロール（テキスト・ドロップダウン・ファイル等）を設定してくれて、型チェックや必須チェックもしてくれます。（基本的にコーディング不要） これと似たことが実現できたらいいなと思いました。 次にデータベースですが、変化に強いっていうとXMLデータベースが気になるところですね。 @ITで、変化に強いとか最近こなれてきたって内容の記事を見たような気がします。 RDBでもXML対応を強化しつつあるようですし、その辺の機能が使えるなら使ってみるとか。 人に勧めといて、私はXMLデータベースに触れたことは全く無いのではありますが・・・。 出力のユーザーインタフェースは・・・、データソースがxmlとしたらxsltで印刷用htmlに変換する程度で済めばいいんですけど。それなら、データ構造に変化があったらxsltの差し替えるだけですから。 ただ、出力に関しては高度な注文が多そうですし、そうもいかないでしょうね。 以上、中途半端な妄想でした。 失礼しました。 | ||||
|
投稿日時: 2008-05-15 09:02
>かめたろ様
ご返信のほどありがとうございます。 データにスキーマとして項目情報を持たすというのもいいですね。。その分管理というか設計には時間がかかりそうですが（苦笑） 自分もXMLデータベースも話題には上がってきてますが、今の状態ではどうしてもRDBのほうに手がいってしまいます。開発経験の少なさが気になるところで（ｗスレッドと本末転倒ですが・・・ ＞ただ、出力に関しては高度な注文が多そうですし、そうもいかないでしょうね。 そうなのです。営業資料となるので印刷部分には妥協が許されないのですよね。。。 この部分とDBの部分とでジレンマのようなものがあります。 まあ、今後、いろいろ技術検証は行って見守っていく方向ですね。 お忙しい仲、お返事のほうありがとうございました。参考にさせていただきます。 | ||||
|
投稿日時: 2008-05-15 11:23
上記のような状況の場合は、通常DBでフィールド名カラムとデータカラムでのデータ縦持ちにしませんか？（私の通常がずれていたらすみません。） フォーマットIDやらいろいろもっておけばDBにもソースにも変更が入らない（フォーマットの追加・変更は必要）ようにできるのではないですかね。 技術・実現手段・トレンドではなく設計の問題のように見えますが･･･。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。