タグ付けされた質問 「database」

私のチームは、モノリシックASP.NETアプリケーションから.NET CoreおよびKubernetesに移行しています。コードの変更は予想通りに進行しているように見えますが、私のチームが多くの不一致に遭遇しているのはデータベースの周辺です。 現在、ビジネス全体のすべてのデータを格納するかなり大きなSQL Serverデータベースがあります。私は、コードを分割するのと同様の方法でデータベースを分割することを提案しています-1つの（論理）データベースのカタログデータ、別のデータベースの在庫データ、別の注文など-そして各マイクロサービスはそのデータベースのゲートキーパーになるでしょう。 ここでの意味は、マイクロサービスの境界を越える外部キーを削除する必要があり、境界を越えて到達するprocsおよびビューは禁止されることです。すべてのデータモデルは同じ物理データベースに存在する場合と存在しない場合がありますが、存在する場合でも、相互に直接対話することはできません。注文は引き続きIDでカタログアイテムを参照しますが、データベースレベルでデータの整合性が厳密に強制されることはなく、そのデータはSQLではなくコードで結合する必要があります。 これらの損失は、マイクロサービスへの移行と、それに伴うスケーラビリティのメリットを得るための必要なトレードオフと考えています。縫い目を賢く選択し、それらの周りに展開する限り、問題ありません。他のチームメンバーは、すべてが同じモノリシックデータベースにとどまる必要があるため、すべてがACIDであり、参照整合性をどこにでも保持できることを固く主張しています。 これは私の質問に私をもたらします。まず、外部キーの制約と参加に対する私の姿勢はもっともらしいですか？もしそうなら、誰かが私が同僚に提供できる信頼できる読み物を知っていますか？彼らの立場はほとんど宗教的であり、彼らはマーティン・ファウラー自身が彼らが間違っていると告げる以外に何かに左右されることはないようです。

18 architecture  database  refactoring  microservices 

私はマイクロサービスアーキテクチャが比較的新しいです。適度なサイズのWebアプリケーションがあり、現在進めているモノリシックシステムではなく、マイクロサービスに分割することの長所と短所を比較検討しています。 私が理解している限りでは、マイクロサービスAと、Bそれぞれが他方のデータのサブセットに依存しているものを検討してください。A何かが変更されたというメッセージが投稿された場​​合、Bそのメッセージを消費し、Aの情報のローカルコピーを複製し、それを使用してB必要な処理を実行できます。 ただし、もしBダウンしたり失敗したりしてしばらくすると、再び元に戻ります。そのダウンタイム中に、Aさらに2つのメッセージを公開しました。の情報のBローカルコピーを更新する方法はどのようにしてわかりますAか？ 場合確かに、B唯一の消費者であるAのキューは、それはそれがオンラインに戻ったら、それを読み始めることができますが、どのような場合には、そのキューとそれらのメッセージの他の消費者が消費されているがありますか？ より具体的な例として、マイクロサービスがダウンしているUsers間にBillingサービスの電子メールアドレスが更新された場合、Billingマイクロサービスが再び復旧した場合、電子メールが更新されたことをどのようにして知ることができますか？ マイクロサービスが復旧すると、「ちょっと復旧しました。現在の情報をすべて教えてください」というブロードキャストを行います。 一般に、データ同期の業界のベストプラクティスは何でしょうか？

17 database  microservices 

私のサービスには多数のユーザーイベントが継続しており、「日付D以降のイベントタイプTの発生をカウントする」などの処理を行いたいと考えています。 私たちは2つの基本的な決定をしようとしています： 何を保存しますか？すべてのイベントの保存と集約のみの保存 （イベントログスタイル）すべてのイベントを記録し、後でカウントします。 （時系列スタイル）毎日の単一の集約された「日付DのイベントEのカウント」を保存する データを保存する場所 リレーショナルデータベース（特にMySQL） 非リレーショナル（NoSQL）データベース内 フラットログファイル（ネットワーク経由で集中的に収集されるsyslog-ng） 標準的な慣行とは何ですか/さまざまなタイプのシステムの比較に関する詳細はどこで読むことができますか？ 追加の詳細： 合計イベントストリームは大きく、潜在的に1日あたり数十万のエントリ しかし、私たちの現在のニーズは、その中の特定の種類のイベントを数えることだけです 生データや集計結果にリアルタイムでアクセスする必要は必ずしもありません 私見、「すべてのイベントをファイルに記録し、後でクロールしてストリームをフィルタリングおよび集約する」は、かなり標準的なUNIXの方法ですが、私のRails-yの同胞は、MySQLでない限り、現実はないと考えているようです。

17 architecture  database  metrics 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 インデックスを使用してデータベースのパフォーマンスを向上させるためのDOとDONTは何ですか？ DOは、インデックスを作成する必要がある場合、またはパフォーマンスを改善する別のインデックス関連のヒントです。 DONTは、インデックスを作成する必要がない場合、またはパフォーマンスを損なう可能性のある別のインデックス関連のアクションです。

17 database  performance  mysql  database-design 

私にとって長年の疑問は、いつデータベーステーブルにデータ（実際の値）を保存し、いつコードに保存するのかということです。 知られていないコンセンサスは、通常そのようなものでした（*）： 単一の変数または単純な構造、またはいくつかの値の配列である場合、コードにデータを直接入れます。 [* コンセンサスはコメントと回答で議論されていますが、基本的には、質問を開始するための何らかの前提を望んでいたので、気軽に挑戦して改善してください] 例： $number = 44; $colors = array("blue", "yellow", ... "mauve"); 同じタイプの数百行以上のデータがある場合は、データベースを使用します。 しかし、灰色の領域があるようです。それほど明確ではないケースはどうですか？決定を下すために注意を払う必要がある考慮事項と要因は何ですか？ 例： 会社が「412T」として表すことができる10〜15種類のモーターフレームを使用しているとします。あなたはそれらの約30を持っています、そして、彼らはめったに変わりません。それらのDBテーブルを作成するか、データベースにハードコーディングできます。この場合、モーターは静的で物理的なものであり、頻繁に変更されることはありません。 それらをコードに保持すると、ソース管理の対象となります。データベースでは、通常、DBの変更は追跡されません。しかし、それらをデータベースに保持すると、コードをデータから解放（分離）できます。 私が使用できる別の（実際の）例は、私の質問です：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（現在48オプションデータの行）。

17 database  source-code  separation-of-concerns 

リレーショナルデータベースアプリケーションと「ユーザー」オブジェクトと「メッセージ」オブジェクトがあるとします。次に、このユーザーに未読メッセージの数を表示します。 これをアーカイブする最良の方法は何ですか？ユーザーにフィールドを導入し、ユーザーがメッセージを受信した場合にカウントアップし、メッセージを読んだ場合にカウントを減らしますか？または、毎回クエリを実行して、未読のフラグが付けられたユーザーのメッセージ数を計算しますか？ 最初のアプローチはより複雑でエラーが発生しやすいと思いますが、2番目のアプローチよりもパフォーマンスが向上します。 これは通常どのように行われますか、またはより良いアプローチは何ですか？

17 database  performance 

私はAndroid向けの最初のアプリケーションを作成しており、SQLiteデータベースを使用するため、できるだけサイズを制限しようとしていますが、この質問は一般的にデータベース設計に当てはまると思います。 テキストと作成日を含むレコードを保存する予定です。このアプリはスタンドアロンアプリです。つまり、インターネットにリンクせず、1人のユーザーのみが更新するため、特定の日付に複数のエントリが存在する可能性はありません。 テーブルにはまだID列が必要ですか？その場合、日付ではなくIDをレコード識別子として使用する利点は何ですか？

17 database 

質問に正しいタイトルを付けることができない場合があります。しかし、ここにあります、 資産管理のための金融ポータルを開発しています。10000以上のクライアントがアプリケーションを使用することを期待しています。ポータルは、株式市場のテクニカル分析に基づいて、さまざまなパフォーマンス分析を計算します。 データベースを介して、ストアドプロシージャ、ユーザー定義関数、トリガーなどを通じて多くの機能を開発しました。C＃コードを使用するよりも、データベースで直接作業を行うことで、パフォーマンスを大幅に向上できると考えました。そして、実際にパフォーマンスが大幅に向上しました。 CTOの功績について自慢しようとすると、コードではなくデータベースに機能を実装するという私の決定に疑問を呈しました。彼によると、そのようなアプリケーションにはスケーラビリティの問題があります。彼の言葉では「最近のものはメモリ/キャッシュに保存されます。クラスター化されたデータは時間の経過とともに管理するのが難しくなります。また、機能はデータベースから完全に分離する必要があります。」 彼の言うことが正しいかどうかについて、いくつかの提案をお願いします。そのようなアプリケーションを設計する方法は？

17 architecture  database  application-design 

フィルター処理された検索フォームを実装する際のご意見をお聞かせください。次の場合を想像してみましょう。 多数の列を持つ1つの大きなテーブル このSQL Serverを言うことは重要かもしれません このテーブルのデータを検索するフォームを実装する必要があります。このフォームには、この検索を最適化するためのいくつかのチェックボックスがあります。 ここで私の質問は、次のどれが検索を実装するための最良の方法であるべきかということです。 内部にクエリを含むストアドプロシージャを作成します。このストアドプロシージャは、パラメータがアプリケーションによって指定されているかどうかを確認し、指定されていない場合は、ワイルドカードがクエリに挿入されます。 動的クエリを作成します。動的クエリは、アプリケーションによって指定された内容に従って構築されます。 これは、SQL Serverがパフォーマンスを最適化するためにストアドプロシージャの作成時に実行プランを作成することを知っているためですが、ストアドプロシージャ内で動的クエリを作成すると、実行プランによって得られる最適化が犠牲になりますか？ あなたの意見で最善のアプローチは何でしょうか教えてください。

17 database  sql  sql-server  methodology  development-approach 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 現在、一般的な顧客情報（ユーザーID、パスワード、姓、名、電子メール、住所、telfnrなど）のデータベースを作成する新しいプロジェクトの可能性を評価しています。この時点で、要件は大まかにのみ定義されています。 顧客DBは、何百万ものレコードに含まれていると予想されます。DBサイジングのためのいくつかの裏側の数値を計算し、潜在的なDBオプションとアーキテクチャを評価するために、これらの種類のレコードの事実上の標準を探しています。特に、すべてのフィールド（名、姓、住所など）の標準サイズ、または単純な顧客レコードの一般的な平均は素晴らしい情報です。 非常に多くのeコマースWebサイトがあるため、再利用でき、車輪の再発明を避けることができる、ある種の典型的な構成が必要です。 何か案は？ ----編集---- 答えは、標準の顧客レコードを採用するのではなく、独自のレコードを設計することに向かっているようです。この質問の焦点は、顧客オブジェクトのフィールドサイズの参照を見つけることであり、それを自分で理解することを避けることであることを強調したいと思います（元のテキストの部分を強調しました- 今は太字にしています）。

17 database  database-design  enterprise-architecture 

重い開発の時代には、データベーススキーマは急速かつ継続的に変化し、ベータビルドへの毎週のプッシュが来るまでに、スキーマは大きく変化したため、唯一可能な賢明なオプションは、可能な限りすべてのテーブルを破棄することですdevデータベースから新しいバージョンをコピーします。明らかに、これは起動後は機能しません。プロダクションデータの削除は災害のレシピであるため、あるバージョン/リビジョンから別のバージョン/データベーススキーマへの変更を管理するための戦略はどこにあるのでしょうか。 私が見つけたまたは経験したもの： あるデータベースから別のデータベースへの直接的な核ダンプ（今私がやっていること） スクリプトまたは手動で実行されるSQLステートメントを含むUPDATE.sqlファイルを維持します。 アクティブなデータベースで対応する「db-schema-version」値を持つupdate.phpファイルを維持する 3番目のオプションは最も賢明な方法のようですが、不完全に構築されたSQLクエリがスクリプトの途中で失敗し、データベースが半分更新された状態のままになり、バックアップの復元が必要になる可能性がまだあります。 それは問題ではないように見えますが、チームとしてphpMyAdminを使用しているため、実際に実行されます。実行されたSQLステートメントをコピーしてupdate.phpファイルに貼り付けることを忘れないでください。別のページに移動したら、SQLステートメントを手動で書き直すか、変更を元に戻して再度実行する必要があります。 私が望んでいるのは、確立された開発ワークフローに影響を与えないソリューションですか？

17 database  versioning  push 

これは私自身の議論であり、私の同僚の何人かは、私がここに来て、それについて一般的なコンセンサスがあるかどうかを確認すると思います。 基本的に、データベースコールに関する次の2つの意見があります。1。データベースコールの数を減らすために必要なすべてを取得するために、1つの大きなコールを行います。 DB呼び出し これが特に効果を発揮するのは、一般的なコードです。Employeeクラスの例を使用しますが、これはかなり簡単です。 Employeeクラスに10個の値属性（名、姓、雇用など）があり、次に2つのクラス属性があります... 1はDepartmentクラスを指し、1つのスーパーバイザーは別のEmployeeオブジェクトを指しているとします。 考え方1では、従業員データと、Department属性とSupervisor属性を設定するために必要なフィールド、または少なくともこれらのサブオブジェクトから最も頻繁に使用されるフィールドを返す1つの呼び出しを行います。 考え方＃2では、最初にEmployeeオブジェクトのみを設定し、次に実際に要求された場合にのみDepartmentおよびSupervisorオブジェクトのみを設定します。 2のスタンスは非常に単純です。要求のサイズと、それらの要求のいずれかが行われるたびにヒットする必要があるデータベースオブジェクトの数を最小限に抑えます。＃1のスタンスは、適切に実装できたとしても、コードが複数の接続を作成しなければならないという事実が、Webサーバーとデータベース間の接続を減らすのではなく、より多くの負担を引き起こすということです。 この調査の背後にある原動力は、Webサーバーとデータベースサーバー間のトラフィック量が制御不能になっていることです。

17 database  coding-style 

メッセージのキューイングに関するアドバイスを求めています。「ジョブ」をメッセージキューに投稿する必要があります。 最初の提案は、SQL Serverインスタンスを使用して、そこからのメッセージを処理することだけでした。インターネットで読んだことはすべて、Message Queueにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。このため、RabbitMQまたは他のサードパーティMQを使用するというアイデアが提案されました。 もう1つ考慮すべきことは、「ジョブ処理」の要件が30秒以上にならないことです。したがって、ジョブを実行するプロセスは30秒ごとにデータベースをポーリングします。私には、これはそれほど悪くはないようで、おそらくデータベースに大きな負荷をかけなくても大丈夫でしょう。 クライアントに必要な追加サポートを追加しないように、これに使用できるデータベースが既にクライアントに配置されていますが、サードパーティMQを追加した場合、ネットワーク構成などの追加サポートがあります。多くのユーザーがいることを考えると、かなりの数です。 私が検討していたもう1つのオプションは、ユーザーがどちらかを選択できるようにすることでした。小さいユーザーの場合、SQL Serverソリューションは問題ありませんが、大きいユーザーの場合、サードパーティのMQソリューションを構成できます。 私はソリューションで販売されていません。誰かが私が考慮すべきことやアドバイスを持っているかどうか疑問に思っています。

17 database  message-queue 

MongoDBは、非常に使いやすいことがわかっているNoSQLデータベースです。最近、HTTPリクエストを使用していくつかのデータを収集し、データの処理後に結果を保存する必要のある簡単なアプリケーションを開発する必要があり、MongoDBを使用してみました。 この経験から、私は従来のリレーショナルデータベースよりもはるかに使いやすく、DBAではなく開発者であるため、作業が大幅に簡素化されました。 それでも、SQL ServerやMySQLのような従来のリレーショナルデータベースの代わりにMongoDBをいつ使用すべきかわからないことがあります。 その場合、リレーショナルデータベースの代わりにMongoDBを使用できるのはいつですか？MongoDBに関して、状況によっては不適切となる、非常に大きな警告がありますか？

17 database  nosql  mongodb 

より速いパフォーマンスとは何ですか？REST APIを作成し、WebアプリでREST APIを使用してデータベースとのすべてのやり取りを行うか、データベースに直接クエリを実行します（つまり、JDBC for Javaなどのデータベースのクエリに使用する一般的なオブジェクトを使用します）？ RESTでの見方： コード内にオブジェクトを作成して、RESTメソッドを呼び出します HTTPメソッドを呼び出す REST API内のコードがデータベースを照会します データベースがデータを返します REST APIコードはデータをJsonにまとめてクライアントに送信します クライアントはJson / XML応答を受け取ります コード内のオブジェクトへの応答をマップする 一方、データベースを直接クエリする場合： データベースをクエリするクエリ文字列でオブジェクトを作成します データベースがデータを返します コード内のオブジェクトへの応答をマップする これは、REST APIの使用が遅くなることを意味しないのでしょうか？たぶんそれはデータベースのタイプ（SQL vs NoSQL）に依存しますか？

16 database  rest  sql