- - PR -
なにを覚えるべきか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-02-15 18:28
やはり今までExcelとAccessベースでやってこられたようですので、 Microsoft SQL Server2000をサーバに、AccessとExcelをクライアントに してクライアントサーバで行うのがよいと思いました。 本格的なリッチクライアントやWebアプリは工数も多く、 従来の経験も生かしにくいと思います。（利用者、開発者とも） wiemさんの会社の規模として適切かどうかわかりませんが、 Small Business Serverの新版も出たことですし、 一度ご検討されてはいかがでしょうか。 | ||||||||
|
投稿日時: 2004-02-15 22:05
私が今いるところが、そうです。半年ほどのソフトウェア教育を受けた人２人、Oracleに強い人１人、私（オープン系１２年）で、半年でつくりました。
私が先に言った「無駄」とは「作ったもの」のことでした。「知識」は無駄にはなりません。データベースも、RDBMSを使うなら構成は同じだし、SQLも標準を覚えて、そして方言を覚えておけば、すべてが無駄にはなりません。 また、あることを成すための方法が１つでないように、ソフトウェアを作る方法も１つではありません。CHNさんの「とにかく沢山作る」というのは、ここにかかってきます。たくさんの事例をこなし、「こういうことをやった」ということを覚えておいて、そして応用力を用います。 量をこなし、それらの概要を覚えておけば、応用が利きます。応用することができれば、すべてを「無駄」にすることはありません。 | ||||||||
|
投稿日時: 2004-02-16 00:18
素人目には、ひとつのデータファイルを、
複数のパソコンからアクセスするということは、 別段、どうってことないように感じるのですが、 現実には、わたしの想像を絶する労力が 払われているのだろうと思います。 それにしても、早く、もっと簡単にいくようには ならないものなのでしょうか？ この辺の歯痒いところが改善されれば、コンピュータも もっと、画期的な威力を発揮するのだろうに、と 感じてしまいます。世界各国のプログラマーが その問題があっさり単純に解決されないばかりに なんと、多くの時間を割いているのかと想像すると 空しささえ感じてしまいます。 それはさておき、まずは自分で何とかやってみたいなと 感じているところです。 「...の考え、休むに似たり」というような言葉も 脳裏をかすめますが、やってみたいという気持ちが 台頭してきまして、一度、徹底的に挫折でもしない限りは、 きっと、元に戻りません。 プログラミングの言語として、C#から始めてみようと 決めるまで、本屋さんではずいぶんと時間を費やしました。 いろいろな意見がありすぎて、決めかねていました。 ただ、決定的なダメージを受ける恐れがあるならば、 言語の習得すら、すぐにでも考えを改めていくことも、 必要でしょう。まずは、やってみます。 ちなみに、半年は当然とのご意見は、貴重な意見として 常に念頭においていきます。それでこそ有用な道具として コンピュータを操れるのだな、と感じます。 なにか、ありましたら、ぜひご意見ください。 | ||||||||
|
投稿日時: 2004-02-16 09:47
ん〜？例えば、ここに２人の人がいます。目の前に饅頭が１つあります。２人とも饅頭が好きだったら、けんかにならないでしょうか？ まぁ、そういうようなことが発生するわけです。どちらがデータを書き替えるか。多くのDBMSには「トランザクション」という機能があります。ある時から始まって、望みの時までに行った変更をなかったことにできます。１つのユーザ操作で複数のテーブルデータを書き替える場合、後から書き込んだデータが更新できなかったら全体を取りやめにするために用います。この「トランザクション」中に多数の人間が同じデータを違う内容に書き替えたら、いったいどれを「確定」させればよいのでしょう。もしこれが「最初」とか「最後」とかと、機械的に決められていたなら、それはそれで使いにくいデータベースになります。 つまり、「あっさり単純に解決」できないのは、できないのではなく、少なくとも「単純に解決」してはいけないのです。そこには運用方法や人の思惑が絡んできます。あっさり解決させていないのは、人の要求です。 Accessは安いです。けれども、排他処理などは考慮されていません。つまり、「複数の人が同時にアクセスすることは、OSのファイルロックによって排除する」と、「単純に解決」させているのです。そのため、「多人数でアクセスするならAccessより・・・」となるのです。逆にOracleやSQL Serverはそのあたりを解決させていません（DBMS内では解決しています）。使う（開発）側に解決をゆだねています。そのために「使いにくい」けれども、「安心して使える」わけです。
言語の習得についてムダといった覚えはありません。ムダなのは、「使われないシステム」を作ったときです。“今”の要望で作り始め、５年後にできあがっても、５年後の要望は“今”とは異なっているはずです。だから、“今”に対応するためには半年、長くても１年で対応するべきではないでしょうか。 まぁ、過去に「先を越された」ことがあったので、「時は金なり」という思いが強いかもしれません。 それから開発の手法ですが、プロトタイプや段階的開発を考えられてはいかがでしょうか。大きなシステムを、素人が、すぐに開発することは不可能です。まず、システムの全体像だけは決めておき、機能ごとに優先順位を付け、優先順位の高い機能から半年〜１年でリリースしていく、ということです。また、「１機能」であっても、「機能」の括りが大きいなら、細分化します。小さいものを少しずつ積み上げていくというわけです。これなら改修も容易なように作ることも出来、時々のニーズに対応する、「使われる／ムダにならないシステム」を作ることができると思います。 | ||||||||
|
投稿日時: 2004-02-16 10:39
るぱんです。
毎度毎度個人的な意見ですが、今回も御他聞にもれず個人的な意見です。 結論から申し上げると、業務の概要（全体像）を模索するのが先・・・かな？と。 どういう位置関係で何をどうしたいのか。 これがデキテルだけで、情報システム部はものすごい使い物になる場合があります。 連携する・・・事を念頭において、 何をどうしたいのか整理される事が重要だと考えます。 そのために、全員が納得できる概要を 「的確な言葉で」言い表せるかどうかってすごい大事だと思うんですね。 片方では「あたりまえ」かもしれないですが、 もう片方では「は？なにそれ？」になってる場合が往々にして見受けられるケースが多いです。 意味上の言葉（この場合は「何」にあたる部分）を 統一（誰も突っ込み様が無いぐらい明確に定義）した上で、 「何」を「どうしたい」とすると簡単なのかな・・・？ なんて思いました。 全体像のデザインの無い物は疲弊した時に多大な労力が必要になります。 どうせいつかやらなければならないのであれば、 「今」力をこめてやるのがいいのかな・・・？って考えました。 参考にして頂けたら幸いです。 | ||||||||
|
投稿日時: 2004-02-16 10:48
目に見えない世界なので容易な話に思えますが、 # 技術者にも理解出来ていない人もいます。（当スレッド投稿者ではありません） 根本的な所として、 「自由」である事は「制約」がある事以上に「問題」を起こします。 同時操作が可能である事は、システムどころか現実世界でも大いなる問題を起こします。 # wiemさんの担当業務が判らないのですが．．．この問題は # 業務で締処理をしている最中に集計対象の伝票が変る事を想定して頂ければ結構です。 その為、安価なアプリケーションでは同時操作は基本的に禁止し この制約により、シンプルな構成になり、安価で提供が出来るのです。 # 締日以前の伝票の修正は禁止、申請は禁止のルールで、作業が楽になりますよね？ # これを可能にすると、収集が付かないと思います。 現実に、ノートが１冊あってそれを複数の人間で記入する場合の 手順を記述して見てください。 この解決手段（手順）は沢山あり、それぞれに一長一短と「新たな問題」や 「前提条件」を含んでいると思います。 システムは、ルールに添って処理手順を自動的に行う物と考えて頂ければ、 同時操作が厄介な問題だと認識して頂けると思います。 # wiemさんの、この素朴な疑問は大切です。
生産性の無い、個人的な意見です。＾＾； wiemさんが試みている事は、前例が非常に少ない無い事と思います。 取りあえずヤッテ見ては如何でしょうか？ 別の意見にもあった通り、手段は幾らでもあります。 wiemさんが考えている事も、その内の一つです。 前向きに取組む姿勢を忘れなければ、ここの誰もが想像し得なかった、 知識や理論体系が生まれるかもしれません。 問題があるからチャレンジだと思います。 チャレンジの先にある目的、目標を見失わ無い様に気をつけて下さい。 
[ メッセージ編集済み 編集者: はにまる 編集日時 2004-02-16 10:50 ] | ||||||||
|
投稿日時: 2004-02-16 13:04
こんにちは。
まずはEXCELでやってみるのがいいんじゃないでしょうか。 EXCELでADOというデータアクセス方法が使えますので、まずはそのあたりの勉強がいいでしょう。練習段階で使うデータベースとしてはACCESSでいいですし。 感じがつかめたらACCESSの替わりにMSDEでやってみて、いけそうなら業務で使えるか検討。使えそうなら実際にちょっと使ってみる。で、効果を計るのとと問題点の洗い出しができたら正々堂々と上司に相談したらいいんじゃないでしょうか。 いきなりC#だのJAVAだの持ち込むと「wiemさんがいないとどうするの？」の状態になりそうなら、それは避けたほうがいいじゃないでしょうか？ | ||||||||
|
投稿日時: 2004-02-16 13:54
私見ですが、まだ今の段階では他のものに移る必要はありません。安易に他のもの に移ってこれらが解決したところで、自分自身のためには何も残らない可能性が あるからです。結論としてはC#を勉強するのはいいのですが、３〜５ヶ月の期間 投資ふぁ可能なら、現状環境でもっと試行錯誤しましょう。 つまり、上記の問題点は問題点として理解できますが、何故そうなるのかというとこ ろをはっきりさせておきましょう。たとえば、不安定という部分ですが、なぜ不安定 なのか？というところの直接的な原因はEXCELの不安定（容量が大きいとかマルチの アクセスがあるとか）というところでしょう。 でも、この原因を生み出しているのはどこでしょうか？EXCEL内にデータを持ち込ん でいるからこの原因が生まれるのではないでしょうか？ じゃ、データはすべて外に持たせたらどうだろうとかいうように考えてみてはいかが でしょうか？必要なときに必要な量だけEXCEL内に取り込むというように。 で、当然そこで思いつくのはACCESS（ACCESSが無くてもMDBというファイル）ですね。 ここにデータを格納するということが思いつけば、スタンドアロン（一人で使う）とし ては完成です。が、複数人で共有したいということであればMDBの問題点の排他制御と いう点が浮上します。（ただ参照のみですと使えます。） ここで安易にORACLE、SQLServer等を検討するか、もう少し試行錯誤してみるかによっ てだいぶ違いが出てきます。 ま、私だったら複数の人が書き込みをすることがだめなら、１箇所で書き込むようにす れば良いのでは？というように考えちゃいますね。 どうするかはいろんな方法があります。テンポラリを使ったバッチ、MTSのような３階層 構造を作る等々。 このあたりでいろいろ試してみるとか、こんな風にとか考えるのが設計と呼ばれる行為 なので、ひょっとして楽しいかもしれませんよ。とにかく今は、現状の環境で何とかする ことを考えてみることをお勧めします。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。