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

このタグは、一般的なデータベースの質問用です。SQLに固有の質問の場合は、代わりにそのタグを使用してください。

8
地理的な住所/場所をデータベースに保存する一般的な方法は何ですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 地球上の住所に適した地理的な住所/場所の正しい形式は何ですか？今のところ： 国 シティ 通り 数 テキストデータ（簡単にするため） zip 緯度/経度 しかし、私はそれを改善できると信じています。国の州/地域または地域のようなものがあるかもしれません。または、シンガポールや香港には、地域/地域/州はありません。 通りはないかもしれませんが、道路や大通りなどがあります。多数の建物が複合している場合があります。床があるかもしれません。部屋番号。等....
6
データベースとユニット/統合テスト
Webアプリケーションを使用したユニット/統合テストについて誰かと話し合いをしましたが、1つのコアアイデアについて意見の相違があります。問題は、ユニットテストの対象となるデータベースにデータを事前に入力しておくべきだと考えている人が話していることであり、テストの実行前後に完全に空である必要があると思います。 データベースに事前入力されたデータに関する私の懸念は、データが良好な状態に維持されることを確認する方法がないことです。テスト自体はデータベース内のデータを作成、削除、変更するため、テストを開始する前にデータベースにデータを保持するのは良いことではありません。 データベースの機能をテストする最良の方法は、次のセットアップを行うことです。 テストを実際に実行する前の「セットアップ」フェーズでは、まずデータベース内のすべてのテーブルを切り捨てます 次に、実行しようとしているテストケースに必要なすべてのデータを挿入します 次に、テストケースを実行して検証します 次に、「ティアダウン」フェーズで、データベース内のすべてのテーブルを再度切り捨てます テスト対象のデータがテスト可能な優れたテストであることを保証する他の良い方法はありません。 ここに何かが足りませんか？これは、データベース関連の機能をテストする最良の方法ではありませんか？（テストを開始する前、またはテストが完了した後でも）データベースに常に存在するデータベースを事前に設定しておくと、メリットがありますか？私のプロセスを異なる方法で説明して、私のポイントをよりよく理解するためのアイデアの助けも素晴らしいでしょう（つまり、私のポイントにメリットがある場合）。
1
Redis vs Zookeeper
これら2つのサーバーが非常に異なるものを対象としていることを考慮して、これら2つのサーバーを比較するのはばかげているようです。しかし、考えてみると、構成データの保存、分散ロック、キューイングなど、多くの類似したことができます。 私はいくつかの生産関連のことのために使用しているRedisのインスタンスを持っていますが、サーバー間でいくつかの簡単な同期を行いたいと思います（主にコードを押し上げたりサーバー間で簡単なロックを必要としない構成変更）。Zookeeperは、Redisが提供しないことを何を提供してくれますか？
13
データベースが言語機能として統合されないのはなぜですか？
外部SQL（または他の）データベースに接続するのではなく、一流の言語機能として組み込みデータベースを備えたプログラミング言語はありますか？そのような機能の欠点と利点は何ですか？そのような機能はどのように見え、プログラムの方法をどのように変えるでしょうか？
3
双方向同期の競合解決
接続が常に利用可能ではないことを前提として、「メイン」データベースサーバーと多くの「セカンダリ」サーバー間の双方向同期、特に競合解決をどのように管理しますか？ たとえば、iOSでCoreDataを「データベース」として使用するモバイルアプリがあり、ユーザーがインターネットに接続せずにコンテンツを編集できるようにしたいと考えています。同時に、この情報はデバイスが接続するWebサイトで入手できます。2つのDBサーバーのデータが競合している場合/その場合はどうすればよいですか？ （CoreDataをDBサーバーと呼びますが、多少異なることがわかります。） この種の問題に対処するための一般的な戦略はありますか？これらは私が考えることができるオプションです： 1.常にクライアント側のデータを優先度の高いものとして使用します 2.サーバー側でも同じ 3.各フィールドの編集タイムスタンプをマークして最新の編集を行うことで競合を解決してください 3番目のオプションは壊滅的なデータ破損の余地を開くと確信していますが。 CAP定理がこれに関係していることは承知していますが、最終的な整合性のみが必要なので、完全に除外するわけではありませんか？ 関連質問：双方向データ同期のベストプラクティスパターン。この質問に対する2番目の答えは、おそらくそれができないということです。
2
照合と文字セットの違いは何ですか？
データベースに関する一般的な質問があります。通常、データベースとの照合という用語を使用します。文字セットとどう違うのか知りたいです。照合は文字セットのサブセットだと思います。その場合、文字セットの下での多重照合の目的は何ですか。
4
2つの異なるデータベース間でデータを同期する最良の方法
構造がまったく異なる2つの大きなデータベース間でデータ同期を実装する必要があります。基本的に、最初のデータベースのさまざまなテーブルにある製品に関するデータを収集し、2番目のデータベースの他のテーブルに再配置する必要があります。 初めて製品を作成することはそれほど複雑ではありません。しかし、私はすべてのデータではなく、各製品に関する特定のデータを更新する方法を探しています。 明らかに、これを難しくするいくつかの問題があります。 選択クエリを除いて、ソースデータベースで何もすることはできません。 ターゲットデータベースでは、通常のクエリ（選択、更新、挿入、作成）を実行できますが、既存の構造/テーブルを変更することはできません。 ターゲットとソースDBは完全に異なる構造を持ち、テーブルはまったく同じではないため、データを実際に再配置する必要があります-テーブルの比較は機能しません。 ターゲットデータベースはMySQLサーバーを使用します。ソースはDB2である場合があります。 どこにも「更新時間」フィールドはありません。 そのため、プロセス全体を1つのPython（理想的には）スクリプトで実行する必要があります。 ターゲットデータベースで更新するフィールドに基づいて、各製品のハッシュを作成することを検討します：md5（code + description + supplier +約10の他のフィールド）。同じデータに基づく新しいハッシュが、ソースデータベースから毎日作成されます。パフォーマンスのために、すべてのハッシュを単一のテーブル（項目コード、current_hash、old_hash）に保存します。次に、新しいハッシュが古いハッシュと異なる場合、製品を比較して更新します。 約50万の製品があるので、パフォーマンスが少し心配です。 それは良い方法ですか？
6
SQLからNoSQLに移行すると、どのサイズのデータ​​で有益になりますか？
リレーショナルデータベースプログラマーとして（ほとんどの場合）、リレーショナルデータベースがどのようにスケールしないか、MongoDBなどのNoSQLソリューションがどのようにスケールするかについての記事を読みました。これまでに開発したデータベースのほとんどは小規模から中規模であったため、インデックス作成、クエリの最適化、またはスキーマの再設計によって解決されなかった問題は一度もありませんでした。 MySQLはどのようなサイズに苦しんでいると予想されますか。何行ですか？ （これはアプリケーションと保存されるデータの種類に依存することを知っています。基本的には遺伝学データベースだったので、3つまたは4つのルックアップテーブルを持つ1つのメインテーブルがあります。メインテーブルには、他のもの、染色体参照、および位置座標。おそらく、そこに保存されているものを確認するために、染色体上の2つのポーション間の多くのエントリを照会されます。
7
本番データベースのデータを安全に修正する
バグが発生し、本番環境でデータを修正する必要がある場合があります。大企業の観点からこれを行う最も安全な方法は何ですか？役立つツールはありますか？この要件を推進するいくつかの考慮事項を以下に示します... 誰がクエリを実行し、何を実行したかを記録する必要があります 理想的には、関心のあるテーブルに対してクエリを実行するためのアクセスを短時間だけ許可する必要があります クエリを実行しているものが何であれ、明示的な許可なしにSQLを長時間実行およびロックすることを許可しないために、クエリについてある程度の知識が必要です。 このプロセスは、DBに依存しないか、少なくともDB2、Oracle、およびSQL Serverを理解する必要があります。 私たちは、アドホックな製品修正クエリが「間違ったこと」を行うリスクを減らし、同時にプロセスにセキュリティ/音声を追加しようとしています。考えやアイデア？
23 database  risk 
12
リレーショナルデータベースにxmlを保存する利点は何ですか？
今日は、AdventureWorksデータベースのチャンスをうかがっていたと私はテーブルの数が（ことに気づいたHumanResources.JobCandidateと Sales.Individual例えば）XMLデータを格納している列を持っています。 私が知りたいのは、基本的にデータベーステーブルの行のデータを別のテーブルの列に保存する利点は何ですか？これにより、この情報をクエリするのが難しくなりませんか？それとも、データを照会する必要はなく、保存するだけでよいという前提ですか？
23 design  database  xml 
11
一部のテーブルのデータベースにセカンダリ主キーを作成する
いくつかのテーブルに、「second_primary_key」を追加します。これは、uuidまたはランダムな長いキーになります。一部のテーブルでは整数をWebアプリケーションに公開したくないため、必要です。つまり、「/ invoices」ページには、請求書のリストと「/ invoices /：id」へのリンクがあります。ここで、：idは整数です。ユーザーにシステム内の請求書の数を知らせたくないので、「/ invoices / 123」の代わりに「second_primary_key」を使用して、URLが「/ invoices / N_8Zk241vNa」になるようにします。 同じことが、実際のIDを非表示にする他のテーブルにも当てはまります。 これは一般的な慣習ですか？これを実装する最良の方法は何ですか？ 結局のところ、この手法は何と呼ばれていますか？
7
データベースでビットマスクを使用する利点と欠点
少し前に同僚と話をしましたが、彼はデータベースに保存されているすべての値を理解するのが難しいため、ビットマスクの使用に間違いなく反対しました。私の意見では、例えば現在のユーザーの役割を決定するためにそれらを使用することは必ずしも悪い考えではありません。それ以外の場合は、別のテーブルに保存する必要があり、これによりもう1つのJOINが発生します。私が間違っているかどうか教えてもらえますか？ビットマスクを使用する他の副作用、利点/欠点はありますか？
9
アジャイル開発では、データベースの前にフラットファイルで永続化を試みる必要がありますか？
アジャイル開発では、ポリシーとアプリケーションロジックは永続化メソッドなどの詳細よりも重要であるため、最後に永続化の決定を下す必要があると誰かが説明してくれました。したがって、この方法の弱点が明らかになるまでフラットファイルなどのより単純な永続性から始めてから、リレーショナルデータベースなどを使用して永続性を変更することをお勧めします。 これは本当ですか、それともコンセプトを誤解しましたか？これはアジャイルチームが通常どのようにアプリケーションを構築するのですか？その理由は何ですか？また、このアプローチを採用すべきではないのはいつですか？
3
発効日の価格を保存する方法は？
製品のリストがあります。それらのそれぞれは、Nプロバイダーによって提供されます。 各プロバイダーは、特定の日付の価格を提示します。その価格は、そのプロバイダーが新しい価格を設定するまで有効です。その場合、プロバイダーは新しい日付で新しい価格を提供します。 現在、MySQLテーブルヘッダーは次のようになっています。 provider_id, product_id, price, date_price_effective 1日おきに、当日に有効な製品/価格のリストを作成します。各製品のリストには、その特定の製品を持つプロバイダーのソート済みリストが含まれています。そのようにして、特定の製品をたまたま最良の価格で提供できる人に注文することができます。 有効な価格を取得するために、を持つすべての行を返すSQLステートメントがありますdate_price_effective >= NOW()。その結果セットは、次のようなファイルを取得するために必要なソートとフィルタリングを行うルビースクリプトで処理されます。 product_id_1,provider_1,provider_3,provider8,provider_10... product_id_2,provider_3,provider_2,provider1,provider_10... これは私たちの目的にはうまく機能しますが、SQLテーブルはおそらくこの種の情報を保存する最良の方法ではないという悩みがあります。この種の問題は、他のより創造的な方法で以前に解決されたと感じています。 SQL以外にこの情報を保存するより良い方法はありますか？または、SQLを使用している場合、私が使用しているものよりも良いアプローチがありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.