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

データベースエントリ（データ）のバージョン管理を許可する方法は何ですか？ 記事の変更を元に戻すコンテンツ管理システムの機能を考えてください。 彼らの長所/短所は何ですか？

21 design  database 

実稼働展開の前の一般的なアドバイスは、最初にDBをバックアップすることです。このように、新しい更新に潜在的なデータ損失または論理データ破損につながる可能性のある問題がある場合、古いレコードを比較して修正するためのバックアップがまだあります。 ただし、DBサイズが数GBになるまでこれはうまく機能します。DBのサイズが大きくなると、バックアップの完了に長い時間がかかります。コード展開の論理的な問題による論理データの破損を回避するために、このような状況で従うべきベストプラクティスは何ですか？

20 database  patterns-and-practices 

数人の開発者の間で議論がかなり白熱したアプリケーションがあります。 基本的に、Webレイヤーとバックエンドレイヤーに分割されます。Webレイヤーは単純なWebフォームによって情報を収集し、このデータをJSONドキュメント（文字列は.jsonファイル）としてバックエンドが使用する監視フォルダーに格納します。バックエンドは数秒ごとにこのフォルダーをポーリングし、ファイルを取得して、その機能を実行します。 ファイル自体は非常にシンプル（つまり、すべての文字列データ、ネストなし）で、最大で1〜2kで、システムはほとんどの時間をアイドル状態にします（ただし、最大100メッセージまでバーストします）。バックエンド処理ステップは、メッセージごとに約10分かかります。 議論は、ある開発者がファイルシステムをメッセージングレイヤーとして使用することは悪いソリューションであると示唆した場合、リレーショナルデータベース（MySQL）、noSQLデータベース（Redis）、またはプレーンREST APIコールなどを代わりに使用する必要がある場合に出てきます。 Redisは、キュー内のメッセージ処理のために組織内の他の場所で使用されることに注意してください。 私が聞いた議論は次のように分類されます フラットファイルを支持して： フラットファイルは、他のソリューションよりも信頼性が高くなります。ファイルは、「監視」フォルダーから、取得後に「処理」フォルダーに、最後に「完了」フォルダーに移動するためです。とにかく他のものを壊すような非常に低レベルのバグがない限り、メッセージが消えるリスクはありません。 フラットファイルを理解するには、それほど高度な技術は必要ありません- catそれだけです。書き込むクエリはありません。誤ってメッセージをキューからポップして、メッセージが永遠に消えてしまうリスクはありません。 ファイル管理コードは、すべての言語の標準ライブラリの一部であるため、プログラミングの観点からデータベースAPIよりも簡単です。これにより、コードベースの全体的な複雑さと、導入する必要のあるサードパーティコードの量が削減されます。 YAGNI原則州フラットファイルが今うまく動作することを、それを残して、より複雑なソリューションに変更するための実証され必要はありません。 データベースを支持して： ファイルがいっぱいのディレクトリよりもデータベースを拡張する方が簡単です フラットファイルには、誰かが「完了」ファイルを「監視」ディレクトリにコピーして戻すリスクがあります。このアプリケーションの性質（仮想マシン管理）により、これにより壊滅的なデータ損失が発生する可能性があります。 T / Sにより高度な技術を必要とするアプリは、教育を受けていないスタッフが物事を突くだけで何かを台無しにする可能性が低いことを意味します。 特にRedisなどのDB接続コードは、少なくとも標準ライブラリファイル管理機能と同じくらい堅牢です。 DB接続コードは、ファイル操作よりもレベルが高いため、開発者の観点からは（機能的にではないにしても）明らかに単純です。 私が見ることができることから、両方の開発者は多くの有効なポイントを持っています。 これら2人のプロファイル開発者、またはプロデータベース開発者のうち、どちらがソフトウェアエンジニアリングのベストプラクティスに沿っているのでしょうか？

20 database  programming-practices  file-handling  message-queue 

注文した情報をリレーショナルデータベースに適切に保存する方法を理解しようとしています。 例： 曲で構成されるプレイリストがあるとします。リレーショナルデータベース内には、Playlistsいくつかのメタデータ（名前、作成者など）を含むの。また、私はと呼ばれるテーブルを持っSongs含む、playlist_id曲固有の情報（名前、アーティスト、期間など）だけでなく、。 デフォルトでは、新しい曲がプレイリストに追加されると、最後に追加されます。Song-ID（昇順）で注文する場合、注文は追加の順序になります。しかし、ユーザーがプレイリストの曲を並べ替えることができるとしたらどうでしょうか？ いくつかのアイデアを思いつきました。それぞれに長所と短所があります。 と呼ばれる列orderは、。整数です。曲を移動すると、その変更を反映するために、古い位置と新しい位置の間のすべての曲の順序が変更されます。これの欠点は、曲を移動するたびに多くのクエリを実行する必要があり、移動アルゴリズムが他のオプションほど簡単ではないことです。 orderという10進数の列（NUMERIC）。曲を移動すると、隣接する2つの数字の間に浮動小数点値が割り当てられます。欠点：10進数フィールドはより多くのスペースを必要とし、数回変更するたびに範囲を再分散するように注意しない限り、精度が不足する可能性があります。 別の方法はprevious、next他の曲を参照するフィールドとフィールドを持つことです。（または、現在、プレイリストの最初の曲、最後の曲の場合はNULLです。基本的には、リンクリストを作成します）。欠点：「リストでX番目の曲を見つける」などのクエリは、一定時間ではなく、線形時間になります。 これらの手順のうち、実際に最もよく使用されるのはどれですか？これらの手順のうち、中規模から大規模のデータベースで最も速いのはどれですか？これを実現する他の方法はありますか？ 編集：簡単にするため、この例では、ソングは1つのプレイリストにのみ属します（多対1の関係）。もちろん、ジャンクションテーブルを使用して、song⟷playlistを多対多の関係にすることもできます（そして、そのテーブルに上記の戦略の1つを適用します）。

20 database  database-design  sorting  array  relational-database 

最近（SQLserver内の）テーブル間に制約を作成する理由はありますか？もしそうなら、いつ？私の分野のほとんどのアプリケーションはオブジェクトの原則に基づいて構築されており、テーブルは必要に応じて結合されます。需要は、アプリケーションのニーズに基づいています。単純なルックアップのために束縛されたテーブルをロードすることはありません。順番に（アクションの後）別の単純なルックアップが必要です。 EntityContext、Linq2Data、NHibernateなどのORMツールも、それ自体で制約を処理します。少なくとも、相互に必要なテーブルはわかっています。サーバー内で制約を行うことは、同じ変更を2回行う（強制する）だけのことですか？ これは通常、決定に疑問を投げかけるものではありませんが、このデータベースはまったく異なる設計になっています。設計は通常のように見えますが、ほとんどはアプリケーションで使用されるオブジェクトをミラーリングしています。私を悩ませているのは、SQLserver内で「カスケードなし」に設定されたすべての制約です。つまり、新しいデータベースクエリをコーディングするときは、「検索して検索」する必要があります。場合によっては、1回の削除を行うために最大10レベルの正確な順序が必要です。 これは私を驚かせます、そして、私はそれをどう扱うべきかわかりません。 私の単純な世界では、この設定により、制約のほとんどの目的が失われます。設計に関する知識がなくてもデータベースにホストからアクセスした場合はOKです。 このシナリオでどのように行動しますか？ dbからすべての制約を削除して、アプリケーションレベルで保持しないのはなぜですか。

20 .net  database  database-design 

最近、RESTfulより優れていると主張するGraphQLについて学びました。しかし、なぜ単純にSQLステートメントをHTTP GETリクエストに入れないのだろうと思い始めました。 たとえば、GraphQLでは次のように記述します { Movie(id: "cixos5gtq0ogi0126tvekxo27") { id title actors { name } } } これは、対応するSQLよりもそれほど単純ではありません SELECT id, title FROM movies WHERE id = cixos5gtq0ogi0126tvekxo27; SELECT actors.name FROM actors, actors_movies WHERE actors.id == movies.actor_id AND movie.id == cixos5gtq0ogi0126tvekxo27; クエリをURLエンコードしてサーバーに送信することができます GET endpoint?q=SELECT%20id%2C%20title%20FROM%20movies%20WHERE%20id%20%3D%20cixos5gtq0ogi0126tvekxo27%3B%0ASELECT%20actors.name%20FROM%20actors%2C%20actors_movies%20WHERE%20actors.id%20%3D%3D%20movies.actor_id%20AND%20movie.id%20%3D%3D%20cixos5gtq0ogi0126tvekxo27%3B HTTP/1.1 はい、クエリURLは長すぎる可能性がありますが、RESTへの準拠を気にしない場合は、POST要求の本文に含めることができます。（ところで、RESTが意味をなすようにHTTP RFCを改訂する必要があると思います：クエリ文字列の長さを制限することは、実装を最初の段階で仕様と混合します） クライアントからSQLを直接発行することには、次の利点もあります。 GraphQLを解析するためにサーバー側のコード/ライブラリは必要ないため、開発時間が短縮されます。 GraphQLを解析するためにサーバー側のオーバーヘッドは必要ないため、実行時間が短縮されます。 SQLステートメントは、GraphQLよりもはるかに柔軟性があります。なぜなら、ほとんどの場合、後者はSQLに還元されるからです。 誰もがSQLを知っています。 それでは、GraphQLがSQLより優れている点は何ですか？

20 architecture  database  web-development  api  web-services 

アジャイル手法、ドメイン駆動設計、オブジェクト指向分析および設計など、ソフトウェア開発への多くのアプローチでは、開発への1つの反復アプローチを採用することをお勧めします。 そのため、プロジェクトでの作業を初めて開始したときにドメインモデルを正しく実行することは想定されていません。代わりに、時間が経つにつれてモデルをリファクタリングします。なぜなら、時間とともに問題の領域をより深く理解できるからです。 それとは別に、完璧なモデルを事前に取得しようとしても、私はすでに非常に難しいと確信していますが、要件は変わる可能性があります。ソフトウェアがそのようにした後にしている生産に配備され、エンドユーザーは、一定の要件を完全に理解していなかったことに気づくかもしれない、あるいは悪化し、いくつかの要件が欠落していました。 ここでのポイントは、ソフトウェアの展開後にモデルの変更が必要になる場合があるということです。これが発生した場合、問題が発生します。本番データベースには重要なユーザーデータがあり、古いモデルの形式に既に適合しています。 コードが適切に設計されておらず、システムが大きい場合、コードの更新は困難な作業になる可能性があります。しかし、それは時間とともに実行できます。Gitのようなツールを使用すると、本番対応バージョンを損傷することなくそれを実行できます。 一方、モデルが変更された場合、クラスのプロパティが消失した場合など、データベースも変更される必要があります。しかし、問題があります。そこには、失われないデータが既にあり、古いモデル用にフォーマットされています。 ここのリレーショナルデータベースは、エンドユーザーの要求に応じて反復的な開発を行ったり、ソフトウェアを更新したりすることを妨げる障壁になっているようです。 私がすでに使用したアプローチの1つは、古いデータベーステーブルを新しいテーブルにマップする特別なクラスをコーディングすることでした。したがって、これらのクラスは古い形式のデータを選択し、新しいモデルで使用される形式に変換して、新しいテーブルに保存します。 このアプローチは最良の方法ではないようです。ここでの私の質問は次のとおりです。リレーショナルデータベースで反復開発を調整するためのよく知られた推奨アプローチはありますか。

19 database  agile  domain-driven-design  relational-database  ooad 

私は主に、すべてのページに複数のテーブルとそれらのテーブルに適用されるフィルターがある類似したページの束で構成されるJava Webアプリケーションを作成しています。これらのテーブルのデータは、SQLデータベースから取得されます。 私はmyBatisをORMとして使用していますが、データベースの設計が貧弱で、mybatisはデータベース指向のツールであるため、私の場合はこれが最良の選択ではないかもしれません。 データベースの設計が貧弱であるため、クエリが非常に異なる可能性があるため、類似したものに対して異なるクエリを作成する必要があるため、多くの重複コードを記述していることがわかりました。つまり、クエリを簡単にパラメータ化することはできません。これは私のコードに伝播し、単純なループでテーブルの列に行を入力する代わりに、次のようなコードがあります： 取得Aデータ（P1、...、PI）; get B Data（p1、...、pi）; Cデータの取得（p1、...、pi）; Dデータの取得（p1、...、pi）; ... そして、異なる列を持つ異なるテーブルがある場合、これはすぐに爆発します。 また、ページ内のhtml要素へのオブジェクトのマッピングである「ウィケット」を使用しているという事実も複雑さを増しています。そのため、私のJavaコードはデータベースとフロントエンドの間のアダプターになります。これにより、ロジックが混在した大量の配線、定型コードが作成されます。 正しい解決策は、ORMマッパーを、dbへのより均質なインターフェースを提供する追加レイヤーでラップすることでしょうか、または私が書いているこのスパゲッティコードを処理するより良い方法はありますか？ 編集：データベースに関する詳細情報 データベースは、主に電話情報を保持しています。貧弱なデザインは以下で構成されています： ドメインの知識とは関係のない人工キーを主キーとして持つテーブル。 一意のトリガー、チェック、または外部キーは一切ありません。 さまざまなレコードのさまざまな概念に一致する一般的な名前のフィールド。 条件が異なる他のテーブルと交差することによってのみ分類できるレコード。 文字列として保存される数値または日付である列。 まとめると、散らかった/怠zyなデザインです。

19 java  design  web-development  database  object-oriented-design 

リモートロケーションの中央データベースに効率的な方法でアクセスする方法をWebで検索し、データベースへの直接アクセス（JDBCなど）の代わりにWebサービスを使用するよう提案しました。 。

19 database  android  web-services 

シナリオは、ユーザーの数が増えており、時間が経つにつれて、ユーザーが同じテーブルで現在「削除済み」（フラグ付き）としてマークしているアカウントをキャンセルすることです。 同じメールアドレス（つまり、ログイン方法）を持つユーザーが新しいアカウントを作成したい場合、再度サインアップできますが、新しいアカウントが作成されます。（すべてのアカウントに一意のIDがあるため、メールアドレスはライブおよび削除されたものの間で複製できます）。 私が気づいたのは、システム全体で、ユーザーのテーブルを常に照会する通常の過程で、ユーザーが削除されていないことを確認していますが、私が考えているのは、それを行う必要はまったくないということです... ！[明確化1：「常にクエリを実行する」ということは、「... FROM users WHERE isdeleted = "0" AND ...」のようなクエリがあることを意味します。たとえば、私たちはそのクエリで、特定の日にすべての会議のために登録されているすべてのユーザーを取得する必要があるかもしれません、我々はまた、 isdeleted =「0」のユーザーから持っている-これが私のポイントが明確にありません]？ (1) continue keeping deleted users in the 'main' users table (2) keep deleted users in a separate table (mostly required for historical book-keeping) どちらのアプローチの長所と短所は何ですか？

19 database  database-design 

この質問は、データベースをどのように設計する必要がありますか？それは、より良いソリューションになるものに応じて、リレーショナル/ nosqlデータベースにすることができます 「会社」と「ユーザー」を追跡するデータベースを含むシステムを作成する必要があるという要件があるとします。1人のユーザーは常に1つの会社にのみ属します ユーザーは1つの会社にのみ所属できます 会社は多くのユーザーを持つことができます 「会社」テーブルの設計は非常に簡単です。会社には次の属性/列があります：（簡単にしましょう） ID, COMPANY_NAME, CREATED_ON 最初のシナリオ シンプルでわかりやすい、ユーザーはすべて同じ属性を持っているため、これはリレーショナルスタイルのユーザーテーブルで簡単に実行できます。 ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON 2番目のシナリオ さまざまな企業がユーザーのさまざまなプロファイル属性を保存する場合はどうなりますか。各会社には、その会社のすべてのユーザーに適用される定義済みの属性セットがあります。 例えば： 会社Aは、LIKE_MOVIE（ブール値）、LIKE_MUSIC（ブール値）を保管したいと考えています。 会社Bが保存したい：FAV_CUISINE（文字列） 会社Cは、OWN_DOG（ブール値）、DOG_COUNT（整数）を保存したい アプローチ1 ブルートフォースの方法は、ユーザーに単一のスキーマを持たせ、彼らが会社に属していない場合にnullを持たせることです： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON 多くのNULLと、それらに関係のない列を持つユーザー行（つまり、会社Aに属するすべてのユーザーはFAV_CUISINE、OWN_DOG、DOG_COUNTのNULL値を持つ）になってしまうため、これはやや厄介です アプローチ2 2番目のアプローチは、「自由形式フィールド」を持つことです。 ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON カスタムフィールドとは何なのかわからないため、それ自体は厄介です。データ型は、格納されている値を反映しません（たとえば、int値をVARCHARとして格納します）。 アプローチ3 …

18 database  database-design  sql  nosql 

まず、この質問はデータベース交換に属していると思いましたが、データベースよりもプログラミングソリューション全体に関連していると思います。人々がそれを最高だと思うなら、データベース交換に移行します。 データベーステーブルに作成および更新されたタイムスタンプをいつ追加する必要があるのか​​疑問に思いましたか？ 最初の明らかな答えは、何かが更新されたとき（トランザクション完了日など）をビジネスロジックが知る必要がある場合、それを入力する必要があるということです。 しかし、非ビジネスロジックの場合はどうでしょうか。たとえば、いくつかのビジネスロジックが失敗し、関連するデータベースの行を確認して、1つの行が更新される前に識別することができるなど、障害の検出に役立つように行が変更された日時を知ることが本当に役立つシナリオを考えることができますエラーの原因となっている別の行。 このユースケースでは、すべてのテーブルに更新を与えてタイムスタンプを作成することは理にかなっています（アプリケーションのどの部分によっても更新されない最も単純な列挙テーブルを除く）。 すべてのテーブルにタイムスタンプを与えることは、間違いなくデータベースをすぐに停止させる素晴らしい方法です。 それでは、データベーステーブルはいつタイムスタンプの作成と更新を使用すべきですか？

18 database  database-design  mysql  debugging  logging 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 多くのリレーショナルデータベース管理システム（RDBMS）に遭遇しました。しかし最近、休止状態を使用したため、オブジェクト指向データベースの方が人気がないのではないかと思い始めました。 JavaやC＃などのオブジェクト指向言語が非常に人気がある場合、オブジェクト指向データベース管理システム（OODBMS）も人気がないのはなぜですか？

18 object-oriented  database  rdbms 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ですから、私の父は現在、FileMaker Proを使用してデータベースを「ハッキング」する過程にあります。FileMakerProは、彼の小さな（4人の医師）実践のためのGUIベースのデータベース作成ツールです。このデータベースは、医療機器からの報告の負担を軽減するために使用され、非常に不器用なプロセスを合理化します。 彼にはプログラミングのバックグラウンドがなく、物事を正しく学ばないように全力を尽くしているようです。彼は重複したデータ型を持ち、データベースによって強制される関係（外部/主キー制約）を持たず、他にも多くの問題があります。Youtubeビデオを使用して、GUIツールを介してすべて手作業で行っています。 私の問題は、彼に100％成功させることを望んでいるのに、この種の決定を処理することは彼にとって適切ではないと思うことです。これらのトピックで何らかの教育を受けずに、一緒にハッキングされたソリューションは悪い考えだと彼に納得させるにはどうすればよいですか？彼は非常に頑固である可能性があり、彼はこれらのタイプの仕事を「子供の遊び」と見なしていると思います これにどのようにアプローチすればよいですか？それはそれでさえ悪い考えですか？または、メンテナンスの悪夢にならないように、これを処理するために適切なDBA /開発者を雇うべきだと思うのは正しいですか？ NB：私は4年間の開発コンサルタントであり、苦痛を伴う顧客実装のシェアを見てきました。 更新： それで、数年後の今、この質問について考える時間がありました。父は、Google Docs、FileMaker Pro、およびいくつかのメールフックを使用してソリューションを実装することになりました。彼はすべてを自分で設定し、彼はそれから計り知れない価値を得ていると言います。 あなたが経験豊富な開発者であれば、おそらくその説明を読んで、しつこいでしょう。しかし、私は実際に全体からかなり良い教訓を学びました-人々は結果だけを気にかけ、実装ではありません。お父さんが気にしているのは、患者の情報を紙に手動で入力する必要がなく、代わりにGoogleドキュメントのフォームにすばやく記入できるということだけです。素晴らしいのは、彼が実践の中で自動化に専念するために、ジュニア開発者/オペレーション担当者を雇おうとしていることです。

18 database 

多数のデータベース抽象化レイヤーにさらされた後、私は、データにアクセスするための独自の異なるパラダイムを発明するすべてのライブラリーのポイントが何であるか疑問に思い始めています。新しいDALを取得することは、新しい言語をもう一度学習するように感じます。通常、やりたいことは、既に自分の頭に書いたSQLクエリを出力するようにレイヤーを説得することだけです。 そして、それは事後の読みやすさにさえ触れていない： # Exhibit A: A typical DAL rows = db(db.ips_x_users.ip_addr == '127.0.0.1') .inner_join(db.ips_x_users.user_id == db.users.id) .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10) # Exhibit B: Another typical DAL rows = db.ips_x_users .join(db.users, on=db.ips_x_users.user_id == db.users.id) .filter(db.ips_x_users.ip_addr == '127.0.0.1') .select(sort=~db.ips_x_users, limit=10) # Exhibit C: A hypothetical DAL based on standard SQL syntax rows = …

18 database  sql  api-design  dsl