問題タブ [system-design]

ピアツーピアのようなデータ交換 (ファイル転送、チャットなど) が可能であるが、シーダー/送信者の匿名性が完全に隠されているか、少なくともすべての参加者が「もっともらしい」情報を持っている「ブラック ネット」をプログラムでどのように設計しますか?つまり、彼らの正確な関与および/またはシステム上のトランザクションまたはアクティビティの知識は、合理的な疑いを超えて証明することはできませんか?

システムAがシステムBにデータを送信する2つのシステムがあります。各システムが互いに独立して実行でき、もう一方がダウンしてもどちらも爆発しないことが要件です。問題は、デカップリング要件を満たしながら、システムAがシステムBと通信するための最良の方法は何かということです。

システムBには現在、dbテーブルのデータをポーリングし、挿入された新しい行を処理するプロセスがあります。

提案されている設計の1つは、システムAがシステムbのdbテーブルにデータを挿入し、システムBに既存のプロセスで新しい行を処理させることです。質問は、このソリューションが2つのシステムを分離する要件を満たしているかどうかです。データベースはシステムBの一部と見なされ、システムAが使用できなくなり、システムAが爆発する可能性がありますか？

もう1つの解決策は、システムAがデータをMQキューに入れ、MQから読み取り、システムBのデータベースに挿入するプロセスを用意することです。しかし、これは単なる余分なオーバーヘッドですか？最終的に、MQキューはdbテーブルよりもフォールトトレラントですか？

私は、さまざまなクラスの作業項目の多数の生産者と消費者の異種ネットワークとしての単純な分散システムのモデルと、それらの作業項目をさまざまな速度で処理できる多数の計算ノードを持っています。レイテンシと帯域幅制限を導入するノードを接続するアークがあります。

私が探しているのは、(DSL として、またはグラフィカル エディターを使用して) モデルを記述できる実用的なツールであり、処理のためのワークアイテムの統計的分布とともに、モデルを (分析的にまたはシミュレーション) スループットの統計情報 (例: 平均スループット、特定の応答時間のしきい値を超える頻度など) について教えてください。そのようなツールは存在しますか?

システム内の人を説明するオブジェクトのリストを返す WCF サービスを設計しています。

レコード数は非常に多く、人の性別などのプロパティがあります。2 つの値 (Male と Female) を持つ Sex という名前の新しい列挙型 (複雑な型であり、より多くの帯域幅を消費する) を作成するか、bool IsMale のようなプリミティブ型を使用する方がよいでしょうか?

誰かがこの問題について何らかの洞察を持っているかどうか疑問に思っていました。

少し背景:

Rails を使用して古い dBase と Visual Basic ベースのシステムから移行し、ラベル印刷、在庫管理、出荷などを行う社内の IntrAnet を構築しました。基本的には ERP です。

ジレンマ

現在、Java で作成されていた古い顧客向け Web サイトを置き換える必要があります。この Web サイトは、クライアントが使用する内部システムに接続されます。在庫、発注、口座明細などの情報を社内システムから引き出して、ライブでサイトに公開できるようにしたいと考えています。その理由は、ウェブサイト、ファックス、電話で注文を受け付けており、時にはウォークインもあるからです。そのため、30 分以内に同じ商品を 2 人の顧客に販売するため、古い Java サイトで在庫の更新が少し遅れただけでも、(非常にまれに) 注文を取り寄せてしまうことがあります。通常は 1 日以内に修正されますが、将来的には回避したいと考えています。

実際の質問

これをより良い方法で達成する方法について誰か提案がありますか?

私が見る3つのオプションは次のとおりです。

a) 内部アプリが接続するのと同じDBに接続する別の Rails アプリを Web サーバー上に構築します。

• +++ プラス: ライブデータ - 内部アプリが見るのと同じもの、つまり、注文はリアルタイムで作成され、在庫はすぐに使い果たされます

• --- マイナス: 潜在的なセキュリティ リスク、コードの重複 - つまり、注文を処理するすべてのコントローラー、モデル、ビューなどを複製する必要があります。

b) 内部アプリとは別の DB に接続する別の Rails アプリを Web サーバー上に構築します。

• +++ プラス: セキュリティへの露出が少ない。
• --- マイナス点: Web DB と内部 DB を同期するための余分な労力 (または REST-API のような Web サービスを使用する)、在庫の枯渇と注文番号の作成を処理するための追加のコード、コードの複製 - つまり、すべてのコントローラーを複製する必要があります。注文を扱うモデル、ビューなど。

c) 内部アプリを Web に公開する

• +++ プラス: 上記のすべての問題が解消されました。これはかなり「DRY」な方法です。
• --- マイナス: セキュリティ上の問題がさらに多くなります。より複雑なログイン システム - 1 つは Web 用、もう 1 つは LDAP を使用する内部ユーザー用です。

それで、何か考えはありますか？誰もが同様の問題を解決しましたか？当社のリソースは限られていることに注意してください。つまり、これに専念する開発者は 1 人です。したがって、これは「お金/人/リソースを投入する」ソリューションではなく、「適切な」「スマートな」ソリューションの 1 つでなければなりません。

ありがとうございました。

管理者が個人に作業を割り当てるためのワークフローを備えたWebアプリ（ASP）があります。問題は、作業をサインアウトする前です。夕方/夜間/早朝の作業はスタッフが少ないため、他の重要な作業がコンピューターから離れて実行されている場合（メカニックの棚からツールを取得する場合）、作業の管理キューを注意深く監視できない場合があります。そのため、作業領域のモニターまたはTV画面に、割り当てられていない新しい作業を継続的に更新するプログラムを作成するための機能要件があります。

私の質問：デプロイメントアーキテクチャに推奨されるベストプラクティスはありますか？Webとデスクトップのシッククライアントアプリケーション？

ウェブ：

Pro-アーキテクチャの一貫性を維持します

短所-ボックスの制御が難しい場合がありますボックスが他のサイトにハイジャックされないようにするための追加の手順を実行し、制限されたログイン、他のセキュリティ、およびコンピュータリソースを制御します

デスクトップシッククライアント：

短所-Webアプリとクライアントアプリの両方をサポートする必要があります。2つのインスタンスを2つの場所にデプロイする必要があります

長所-セキュリティとボックスの使用制限は簡単です。アプリのセキュリティログインは必要ないため、PEなどの機能は必要に応じてアプリをバックアップできます。

さまざまなパラメーター (JobCode、State、Customer、Product など) に基づいて指示を管理する Web アプリケーションを構築しています。このような各パラメーターに約 20 のフィラー フィールドを割り当てました。フィールドの表示名は、プロジェクトごとに異なる場合があります。(複数の実装)。

一部のプロジェクトでは、20 個のフィールドすべてを使用するわけではなく、5 ～ 6 個のフィールドしか使用しない場合があります...

現在、私の同僚の 1 人が、ストアド プロシージャをカスタマイズして、プロジェクトで必要な列名を持つフィールドを返して受け入れ、SP に実際の列名でルックアップを行わせることを提案しています。彼はまた、コントロールを動的に構築することを提案しています。

20 個のフィールドすべてに静的コントロールを提供し、ラベルに必要なフィールド名を入力し、フィールド名「Filler1」、「Filler2」を使用して SP と対話することを考えました。これは、不要なコントロールを非表示にする必要があることも意味します...

経験豊富なユーザーとして...両方の長所と短所を列挙できますか...

ありがとう

Alan J. Perlis によるEpigrams in Programmingから:

22. 優れたシステムに弱いコマンド言語を使用することはできません。

これは何を意味するのでしょうか？この原則の良い例は何ですか?

この基準を満たすコマンド言語を実装する方法について、どこで詳しく知ることができますか?

SQL での Entity-Attribute-Value データベース設計の主な欠点はすべて、データのクエリとレポートを効率的かつ迅速に実行できることに関連しているようです。この件に関して私が読んだ情報のほとんどは、これらの問題と、ほとんどすべてのアプリケーションのクエリ/レポートの共通性のために、EAV の実装に対して警告しています。

私は現在、エンティティの 1 つのフィールドが設計/コンパイル時に不明であり、システムのエンド ユーザーによって定義されるシステムを設計しています。EAV はこの要件に適しているように思えますが、私が読んだ問題のために、このシステムにもかなり重いレポート要件があるため、実装をためらっています。私はこれを回避する方法を思いついたと思いますが、SO コミュニティに質問を投げかけたいと思います。

典型的な正規化されたデータベース (OLTP) がレポートを実行するための最良の選択肢であるとは限らないことを考えると、正規化されたデータベースからのデータがコピーされ、広範囲にインデックスが作成され、クエリを容易にするために非正規化されている可能性があります。EAV 設計の欠点を回避するために同じアイデアを使用できますか?

私が見た主な欠点は、EAV データベースで新しいフィールドが定義されているため、レポート データベースのテーブルを変更しなければならない可能性があるため、EAV データベースからレポートにデータを転送する際の複雑さが増すことです。しかし、それはほとんど不可能ではなく、EAV 設計によってもたらされる柔軟性の向上とのトレードオフとしては許容できるようです。すべての標準レポート ツールは SQL バックエンドに対してクエリを実行することを想定しているため、メイン データ ストレージに非 SQL データ ストア (つまり、CouchDB など) を使用する場合にも、この欠点が存在します。

クエリ用に別のレポート データベースを使用すると、EAV システムの問題はほとんどなくなりますか?

編集：これまでのコメントをありがとう。私が取り組んでいるシステムに関する重要なことの 1 つは、システム内のすべてではなく、エンティティの 1 つに EAV を使用することだけを話しているということです。

システムの全体的な要点は、事前に知られていない複数の異なるソースからデータを引き出し、データを処理して、特定のエンティティに関する「最もよく知られている」データを作成できるようにすることです。したがって、私が扱っているすべての「フィールド」は多値であり、それぞれの履歴を追跡する必要もあります。このための正規化された設計は、フィールドごとに1つのテーブルになるため、とにかくクエリを実行するのが面倒になります。

これが私が見ているテーブルスキーマとサンプルデータです（明らかに私が取り組んでいるものから変更されていますが、それは要点をよく示していると思います）：

EAV テーブル

レポート表

正規化された設計

ここでの「Confidence」フィールドは、SQL を使用して (たとえあったとしても) 簡単に表現できないロジックを使用して生成されるため、新しい値を挿入する以外の最も一般的な操作は、すべてのフィールドの人物に関するすべてのデータを取得することです。レポートテーブル。これは、単一のクエリを実行できるため、EAV モデルの方が実際には簡単です。正規化された設計では、大規模なデカルト積がそれらをすべて結合するのを避けるために、フィールドごとに 1 つのクエリを実行する必要があります。

この質問があまりにもオープンエンドではないことを願っていますが、正しい方向に微調整するだけで十分です。

私は現在、オンライン会計システムを構築しています。ユーザーは、登録、ログイン、顧客の作成、請求書やその他のドキュメントの生成、そして最終的にはそれらのドキュメントの印刷/電子メール送信を行うことができます。

私はJavaプログラマーですが、残念ながらWebプロジェクトとその設計概念についてはあまり経験がありません...

これは私がこれまでに得たものです-SpringをロードするTomcatWebサーバー。Springは、私のDAOとビジネスロジックに必要なクラスを処理します。Tomcatは、Webサイトを構成するページを含むJSPを提供します。インタラクティブにするために、ページ（jQueryとそのAJAX呼び出し）でJavaScriptを使用してJSONデータを送受信しました（これは、クラスの1つでhandleAction（）メソッドを呼び出すページに投稿することによって行われます）。

私の質問は、私はこのプロジェクトに正しい方法で取り組んでいますか？適切なツールと方法を使用していますか？プロジェクトに取り組む方法は文字通り無数にあることを理解していますが、試行錯誤された方法、一般的な慣行などに関してフィードバックをもらいたいと思っています。

前もって感謝します！

ザンデル