6

これは、ビジネス指向のプログラミングの質問であり、解決方法がわかりません。私は、BASIC を 20 年以上使用しているプログラマーのチームと一緒に働いています。私は、.NET で同じソフトウェアを作成するのを手伝うために連れてこられましたが、更新と最新のプラクティスだけが必要でした。問題は、他の 3 人のチーム メンバー (全員が BASIC プログラマーですが、1 人は現在 .NET もやっています) にリレーショナル データベースを正しく行う方法を理解してもらえないことです。彼らが理解できないことは次のとおりです。

基本的にはお客様のタグ情報を追跡する取引を行っております。現在の取引と過去の取引を追跡できる必要があります。古いシステムでは、フラット ファイル データベースが使用されていました。このテーブルには、顧客の現在の基本的なトランザクションのレコードが含まれるテーブルと、顧客の以前のすべてのトランザクションと重要な金銭情報が含まれる別のトランザクションが含まれていました。冗長性を防ぐために、現在のトランザクションを履歴トランザクションで上書きします (履歴ファイルが最初に更新され、次に現在のファイルが更新されます)。必要なトランザクション テーブルは 1 つだけなので、これはまったく必要ありませんが、上司または他の 2 つの共同テーブルのいずれかが必要です。 - 労働者はこれを理解できないようです。どうすれば彼らに光を見るように説得できますか? ばかげた量の作業をしなければならず、データタブに何度もアクセスすることになりますか? 入力していただきありがとうございます！

4

7 に答える 7

7

まず、あなたの説明から、既存の構造のデータ構造とロジックフローが実際に何であるかが完全に明確ではないことを認めなければなりません。これは、おそらくあなたが同僚に対しても自分自身を明確にしていないことを暗示しているので、あなたの優先事項の 1 つは、口頭で、またはできれば書面や図表で、現在の状況と提案された代替案を説明できるようにする必要があります。これは、あなたの質問に対する批判ではなく、観察として受け取ってください。

次に、20 年の経験を持つプログラマーがリレーショナル データベースとトランザクションを理解していないことは非常に注目に値します。フラット ファイルのコーディングは、かなり前に主流から外れました。1988 年に初めて商用環境でリレーショナル データベースを扱いましたが、90 年代半ばにはかなり一般的になりました。取り組んでいるセクターと製品タイプは何ですか? ある種の組み込みシステムまたは「異常な」システムを扱っている可能性があるように思えます。その場合、何らかの通信の問題がなく、大きな象を見落としていることを確認する必要がありますそれはあなたに指摘されていません - あなたは、適切な情報が与えられていないことによって何らかの方法で設定されたチームに連れてこられた最初の「コンサルタント」ではないでしょう.

最後に、あなたが自分の立場に完全に確信を持っていて、あなたの提案を受け入れないチームに直面している場合 - そして時間を割けるならデモコードは良い考えです - そしておそらくあなたはその提案を受け入れなければならないでしょう.優雅に決定し、1つを移動します。この立場にある私自身、問題を抽象化しようとします-たとえば、データベースの更新をストアドプロシージャに移動して、両方のテーブルを更新するコードがSPにあり、後日変更してスキーマに移動することができます対応するアプリケーションの変更？後で機会があれば再検討できるように、議論が十分に文書化および記録されていることを確認してください。

社内の政治的理由から最適ではないソリューションを実装しなければならなかったコーダーは、あなたが初めてではありません。そのような状況に対処するための自己啓発の学習体験としてそれを使用し、追加料金が支払われるという考えに共感してください。仕事。多くの場合、そのような議論の決定要因は論理ではなく、あなた自身が持ち込む「評判の重み」です。その後のケースで十分な評判を得る前に、彼らが同意したことを実装することに優れて評判を得るために取り組む必要があるかもしれません-最初に改造する必要があります!

于 2009-01-29T22:49:49.630 に答える
4

時々あなたはできません。

XPの本をいくつか読んだ場合、彼らはしばしば、あなたの最大のハードルの1つは、チームがいつも行ってきたことを放棄するように説得することになると言います。

一般的に、彼らは適応できない人々を他のプロジェクトに行かせることを勧めます（または単に彼らを手放すこと）。

コードレビューはあなたの場合に役立つかもしれません。コードのすべての行の必須のコードレビューは前代未聞ではありません。

于 2009-01-29T21:18:29.457 に答える
4

時々、最良の議論は例です。私はプロトタイプ（またはあまり多くの作業がなければ代替品）を書きます。調べる例を使用すると、リレーショナルデータベースの長所と短所を簡単に確認できます。

余談ですが、フラットファイルデータベースは、真のリレーショナルデータベースよりも「管理」が非常に簡単であるため、その場所があります。心を開いてください。;-)

于 2009-01-29T21:18:40.110 に答える
3

私はあなたが模範を示す必要があるかもしれないと思います - 「新しい」方法がより少ない仕事であると人々が見るとき、彼らはそれを採用します（あなたがそれに鼻をこすらない限り）.

また、古いデザインが実際に問題を引き起こしているのか、それとも見た目が煩わしいだけなのかを自問することもできます. 古い設計がパフォーマンスの問題を引き起こしたり、システムの保守を困難にしたりしていない場合は、古い設計をそのままにしておくことが重要です。

最後に、古い設計をそのままにしておく場合は、新しいコードと古いデータベースの間のインターフェイスを抽象化してみてください。そうすれば、後で設計を改善するよう同僚を説得する場合に、変更せずに新しいスキーマをドロップできます。他に何か。

于 2009-01-29T21:31:06.247 に答える
1

元の質問から一般的なフラストレーションを除いて、すべてを抽出することは困難です。

確かに、技術の変化を考えると、長年の経験者が時間をかけて習得する多くの技術や習慣が役に立たず、コストがかかることさえあります. 処理能力、メモリ、さらにはディスクが高価だった時代には理にかなっているいくつかのことは、今では最適化の愚かな試みになる可能性があります. また、人々が時間の経過とともに悪い習慣や悪いプログラミング パターンを蓄積することもよくあります。

ただし、注意が必要です。

時には、それらの古いタイマーが行うことには正当な理由があります。悲しいことに、彼らは「なぜ」を言語化することさえできないかもしれません。

初心者がエンタープライズ ソフトウェア開発ショップにやってくると、この種のフラストレーションがたくさん見られます。環境がすべてかなり最新のテクノロジーとツールであっても、それは悪いことです. あなたの経験のほとんどがスモール コミュニティのデスクトップおよび Web アプリケーションの作成である場合、あなたが "知っている" ことの多くは間違っている可能性があります。

多くの場合、DBMS が実行できるレベルより上のレベルでのトランザクション ジャーナリングの要件があります。時系列の正確性、1 回限りの更新、復元力、および否認防止を保証するために、DB トランザクション セマンティクスを超えることが必要になることがよくあります。

そして、これは、企業または企業間のスケーラビリティーに関連する問題に対処することにもなりません。1 日に 50 万件の複雑なトランザクションに近づき始めると、RDBMS テクノロジが役に立たないことに気付くでしょう。リレーショナル データベースは大量のトランザクションを処理するように設計されていないため、正規化と更新の標準的なパラダイムを破らなければならないことがよくあります。従来の RDBMS ロック手法では、問題にハードウェアを投入してもスケーラビリティが損なわれる可能性があります。

そのすべてを、よろめきや一般的な頭の悪さ、さらには無能さとして片付けるのは簡単です。ただし、常にそうであるとは限らないので注意してください。

ところで、RDBMS 以外にもモデルがあり、RDBMS に代わるものは必ずしも「フラット ファイル」ではありません。これは、今日のほとんどのコーダーの経験とは異なります。RDBMS よりもはるかに高いスループットを処理できるトランザクション階層 DBMS があります。 たとえば、IMSは大規模な IBM ショップで今も健在です。他のベンダーは、異なるプラットフォーム用に同様のソフトウェアを提供しています。

もちろん、4 人の店では、これは当てはまらないかもしれません。

于 2009-06-21T16:56:04.793 に答える
0

いくつかのまともなトレーニングにサインアップしてから、新しいテクノロジーでもっと多くのことが可能である（または少なくとも簡単にできる）ことを彼らに納得させるのはあなた次第です。

しかし、ここで最も重要なことは、プロの認定トレーナーが最初に基本を教えることだと思います。彼らは、同僚の1人だけが「ねえ、これを使ってみませんか？」と言うのではなく、それにもっと感銘を受けるでしょう。

ここに関連する投稿。

于 2009-01-29T21:17:09.223 に答える
0

以下は年の状況では当てはまらないかもしれませんが、技術的な詳細についてはほとんど言及されていないので、私はそれについて言及したいと思いました...

現在のデータと履歴データのアクセスパターンが大きく異なる場合があります（この例を作成していますが、現在のデータは1秒間に数千回アクセスされ、列の小さなサブセットとすべての現在のデータにアクセスするとします1 GB未満に収まりますが、たとえば、履歴データは数千GBを使用し、1日に数百回しかアクセスされず、すべての列にアクセスできます）、

そうすれば、パフォーマンスを最適化するために、同僚が行っていることは完全に理にかなっています。現在のデータを（冗長に）分離することにより、履歴テーブルでは実行できなかったより高い頻度のアクセスパターンに対して、そのテーブルのインデックスとデータ構造を最適化できます。

実際の実際の状況に適用した場合、純粋に関係の観点から「学術的に」または「技術的に」正しいすべてが意味をなすわけではありません。

于 2009-06-21T17:48:04.057 に答える