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

現在、ユーザーが1 MB〜10 MBのサイズのファイルを保存および共有できるWebアプリケーションを作成しています。 データベースにファイルを保存すると、データベースアクセスが大幅に遅くなるように思えます。 これは有効な懸念事項ですか？ファイルシステムにファイルを保存し、データベースにファイル名とパスを保存する方が良いでしょうか？データベースを操作する際のファイルの保存に関連するベストプラクティスはありますか？ 私はこのプロジェクトでPHPとMySQLを使用していますが、ほとんどの環境（Ruby on Rails、PHP、.NET）およびデータベース（MySQL、PostgreSQL）で同じ問題があります。

188 database  database-design  mysql  file-handling 

私はプロジェクトのコンセプトに合わせてデータベースを設計しようとしており、熱く議論されている問題のように思われました。私はいくつかの記事を読んで、フィールドにIDなどのリストを保存することは決して（またはほとんど決して）大丈夫ではないことを示すいくつかのStack Overflowの回答を読んでいます-すべてのデータはリレーショナルでなければなりません しかし、私が直面している問題は、タスクアサイナーを作成しようとしていることです。ユーザーはタスクを作成し、複数のユーザーに割り当てて、データベースに保存します。 もちろん、これらのタスクを「Person」に個別に保存する場合、1人に0〜100個のタスクを割り当てることができるため、ダミーの「TaskID」列を数十個用意し、それらをマイクロ管理する必要があります。 繰り返しますが、タスクを「タスク」テーブルに保存する場合、ダミーの「PersonID」列を数十個用意し、それらをマイクロ管理する必要があります。これは以前と同じ問題です。 このような問題の場合、何らかの形でIDのリストを保存しても大丈夫ですか、それとも原則を破らずに達成できる別の方法を考えていないだけですか？

94 database  database-design  sql  relational-database 

作業するソフトウェアを設計および作成するとき、通常、最初にバックエンドSQLテーブルを設計および作成してから、実際のプログラミングに進みます。私が現在取り組んでいるプロジェクトは、私を困惑させます。これはおそらく、適切で堅実な要件が不足しているためですが、残念ながら今度はそれについてできることはほとんどありません。それは「それを実現させるだけ」のような状況です。しかし、私は脱線します。 ワークフローを頭に入れ、最初にUIクラスとデータモデルクラスを作成して、データベーススキーマが最終的にどのように見えるかを明確にすることを考えています。これはいい考えですか？私はUIになり、dbをどのように構成するのかまだわかりません。 好奇心anyone盛な方は、SQL Serverをバックエンドとして、MS Accessをフロントエンドアプリケーションとして使用しています。（アクセスも私の選択ではありません...だから、あまりにも嫌いにしないでください。）

77 programming-practices  database-design 

私は、プロジェクトのいくつかの要素にエンティティー属性値（EAV）モデルを使用することを考えていますが、Stack Overflowでのそれに関するすべての質問は、 EAVをアンチパターンと呼ぶ答えになります。 しかし、私はそれがすべての場合においてそれが間違っているかどうか疑問に思っています。 ショップ製品のエンティティを考えてみましょう。名前、説明、画像、価格など、ロジックに多くの場所で参加する共通の機能があり、時計やビーチボールなどの（半）固有の機能はまったく異なる側面で説明されます。したがって、EAVはそれらの（半）固有の機能を格納するのに適していると思います。 これはすべて、製品リストを表示するために製品テーブルに十分な情報があり（EAVが関与しないことを意味します）、1つの製品を表示するとき/最大5つの製品などを比較するときだけです。EAVを使用して保存されたデータが使用されます。 Magentoコマースでそのようなアプローチを見てきましたが、非常に人気がありますが、EAVが妥当な場合はありますか？

65 database-design  data-structures  anti-patterns 

ユーザーが設定できるアプリケーションを書いたとしましょう。この「構成データ」をデータベースに保存するには、2つのパターンが一般的に使用されます。 単一行のテーブル CompanyName | StartFullScreen | RefreshSeconds | ... ---------------+-------------------+------------------+-------- ACME Inc. | true | 20 | ... 名前と値のペアのテーブル ConfigOption | Value -----------------+------------- CompanyName | ACME Inc. StartFullScreen | true (or 1, or Y, ...) RefreshSeconds | 20 ... | ... 両方のオプションを実際に見てきましたが、どちらにも明らかな利点と欠点があります。 単一行の表は、使用できる構成オプションの数を制限します（通常、行の列の数は制限されているため）。追加の構成オプションごとに、DBスキーマの変更が必要です。 名前と値のペアの表では、すべてが「文字列で入力」されています（ブール値/日付/その他のパラメーターをエンコード/デコードする必要があります）。 （もっとたくさん） どのオプションが望ましいかについて、開発コミュニティ内でコンセンサスがありますか？

64 database-design  data-structures  configuration 

今日の私の同僚は、アプリケーションのすべてのクエリを調べ、それに応じてインデックスを追加することを提案しました。 私たちのアプリケーションはまだリリースされていないため、これは時期尚早な最適化だと思います。ライブになったら遅いクエリを監視し、それに応じてインデックスを追加することをお勧めします。 データベースを設計する際の一般的なコンセンサスは何ですか？新しいクエリを作成するたびに一致するインデックスを追加する必要がありますか？それとも、それがどのように進行するかを監視して確認する方が良いでしょうか？

61 database  database-design  indexing 

辞書のエントリ（通常は単一の単語）とその意味を別の言語で保存するデータベースを設計および設定する予定です。したがって、たとえば、テーブル用語集にはエントリと定義が必要であり、各テーブルレコードには、格納されているレコードのIDへの参照がありますTag（各エントリにはタグまたはカテゴリが必要です）。 私のデータは構造を持っているので、SQLデータベース（MySQLなど）を使用することは悪い考えではありません。しかし、人々はMongoDBの方がパフォーマンスがはるかに優れていると言います。 クライアント側では、アプリケーションは、バックエンドが提供するREST APIを使用するオートコンプリートを備えた検索ボックスを提供できる必要があります。このようなシナリオでMySQLを使用するのは安全ですか？または、これに他のソリューションのMongoDBまたはElasticSearchを使用する必要がありますか？このようにして、数十万件のレコードが保存およびアクセスされることになっています。

55 database-design  data-structures  mysql  relational-database  mongodb 

Youtubeを例として使用したいと思います。彼らはの形式のIDを使用しますPEckzwggd78。 単純な整数を使用しないのはなぜですか？ またはimgur.com- 9b6tMZS画像やギャラリーなどのIDも使用します。連続した整数ではありません。 なぜ整数（特に連続した整数）を使用しないのですか？ どのような場合、整数の代わりにそのような文字列IDを使用することが賢明な決定ですか？

54 database  database-design  web-services 

ユーザーがさまざまなウィッシュリストにアイテムを追加できるウィッシュリストシステムに取り組んでおり、ユーザーが後でアイテムを再注文できるようにする予定です。これをデータベースに保存して高速で混乱を起こさない最善の方法については本当にわかりませんものをきれいにするため）。 最初にpositionコラムを試しましたが、アイテムを移動するときに他のすべてのアイテムの位置の値を変更する必要があるのは非常に効率が悪いようです。 自己参照を使用して前の（または次の）値を参照する人を見てきましたが、繰り返しますが、リスト内の他の多くの項目を更新する必要があるようです。 私が見た別の解決策は、小数を使用し、それらの間の隙間にアイテムを貼り付けるだけです。これはこれまでの最良の解決策のように思えますが、より良い方法が必要だと確信しています。 通常のリストには最大で約20個程度のアイテムが含まれ、おそらく50個に制限されます。並べ替えはドラッグアンドドロップを使用し、おそらく競合状態などを防ぐためにバッチで実行されますajaxリクエスト。必要に応じて（Herokuで）postgresを使用しています。 誰にもアイデアはありますか？ 助けてください！

54 database  database-design  mongodb  postgres 

最小数のテーブルでデータベース構造を作成する必要がありますか？ すべてが1か所に収まるように設計する必要がありますか、それともテーブルを増やしても大丈夫ですか？ とにかく何かに影響しますか？ 私の友人がmediaWikiのデータベース構造を変更したため、この質問をしています。結局、彼は20個のテーブルの代わりに8個しか使用していなかったので、それを行うのに8か月かかりました（大学での割り当てでした）。 編集 私は答えを次のように結論付けています：ケースが例外的になるまで、テーブルのサイズは重要ではありません。この場合、非正規化が役立つ場合があります。 答えてくれてありがとう。

52 database  database-design 

1週間、NoSQLデータベースについて学んでいます。 NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。 しかし、多くの場合、NoSQLがリレーショナルデータベースを置き換えることができるかのように記事を書きます。そして、頭を動かせない点があります。 NoSQLデータベースは（多くの場合）キーと値のストアです。 もちろん、（JSON、XMLなどでデータをエンコードすることで）すべてをキーと値のストアに保存することは可能ですが、多くの場合、特定の基準に一致するデータを取得する必要があるという問題がありますユースケース。NoSQLデータベースでは、効果的に検索できるキーは1つだけです。リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。 そのため、NoSQLデータベースは、コンテンツで検索する必要がある永続的なデータには実際には選択できません。または、私は何かを誤解しましたか？ 例： Webショップのユーザーデータを保存する必要があります。 リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。 NoSQLデータベースでは、各ユーザーを自分のIDをキーとして、すべてのデータ（JSONなどでエンコードされた）を値として保存します。 したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者が彼らについて何かを知る必要があります）、リレーショナルデータベースでは簡単に行えますが、NoSQLデータベースではあまり効果的ではありません。すべてのユーザーを取得し、すべてのデータを解析してフィルターします。 私はそれが不可能だとは言いませんが、それははるかにトリッキーになり、NoSQLエントリのデータを検索したい場合はそれほど効果的ではないと思います。 この国に住んでいるすべてのユーザーのキーを格納する国ごとにキーを作成し、この国のキーに保管されているすべてのキーを取得することで特定の国のユーザーを取得できます。しかし、この手法により、複雑なデータセットはさらに複雑になります。SQLデータベースへのクエリほど実装が難しく、効果的ではありません。ですから、本番環境で使用する方法ではないと思います。またはそれは？ そのようなユースケースを処理するために、何かを誤解したり、いくつかの概念やベストプラクティスを見落としたりしたかどうかは、本当にわかりません。たぶん、あなたは私の声明を修正し、私の質問に答えることができます。

51 database  database-design  sql  nosql  relational-database 

私は新しい組織で働き始めました。データベースで見たパターンの1つは、ビジネスアナリストがクエリを記述しやすくするためにフィールドを複製することです。DjangoとそのORMを使用しています。 1つのケースでは、特定のコンテキストで患者を識別する一意の文字列を含むMedicalRecordNumberオブジェクトを保持します。我々は持っている登録患者を追跡および関連持つオブジェクトMedicalRecordNumbersをではなく、外部キー関係を使用するよりも、彼らが参加する書き込みを避けることができるように、彼らは文字列を複製（ないパフォーマンス上の理由のために）。このパターンは、データベース全体で共通です。 私にとって、データモデルがクリーンであることの重要性は、それについてよく考えることができるためです。不必要な複雑さは、限られた認知処理時間の無駄です。これは体系的な問題です。結合を書くのが気に入らないことは、修正可能なスキルの問題です。スキーマに戻って変更することを必ずしも支持する必要はありませんが、このタイプの複製に関する問題を説得力を持って明確に表現できるようになりたいです。

47 database-design 

RDBMSのデータベースモデルを確認すると、通常、PK / FK以外の制約がほとんどまたはまったくないことに驚かされます。たとえば、パーセンテージは多くの場合型の列に格納されますがint（tinyintより適切です）CHECK、値を0..100の範囲に制限する制約はありません。同様にSE.SEでも、チェック制約を示唆する回答は、データベースが制約の間違った場所であることを示唆するコメントをしばしば受け取ります。 制約を実装しないという決定について尋ねると、チームメンバーは次のように応答します。 そのような機能がお気に入りのデータベースに存在することすら知らないということです。ORMのみを使用するプログラマからは理解できますが、特定のRDBMSで5年以上の経験があると主張するDBAからはほとんど理解できません。 または、アプリケーションレベルでそのような制約を強制し、データベースでそれらのルールを複製することは、SSOTに違反して、良いアイデアではありません。 最近では、外部キーさえ使用されないプロジェクトが増えています。同様に、ユーザーが参照整合性をあまり気にせず、アプリケーションにそれを処理させることを示す、SE.SEに関するいくつかのコメントを見ました。 FKを使用しない選択についてチームに尋ねると、次のように伝えます。 たとえば、他のテーブルで参照されている要素を削除する必要がある場合は、PITAです。 NoSQLは揺れ動き、外部キーはありません。したがって、RDBMSではそれらは必要ありません。 パフォーマンスの点では大したことではありません（コンテキストは通常​​、小さなデータセットで動作する小さなイントラネットWebアプリケーションですので、実際にはインデックスでも大したことはありません。特定のクエリのパフォーマンスが1.5 。〜20ミリ秒） アプリケーション自体を見ると、次の2つのパターンに体系的に気付きます。 アプリケーションは、データベースに送信する前にデータを適切にサニタイズしてチェックします。たとえば102、アプリケーションを介して値をパーセンテージとして保存する方法はありません。 アプリケーションは、データベースからのすべてのデータが完全に有効であると想定しています。つまり102、パーセンテージで表示された場合、どこかでクラッシュするか、単にユーザーにそのまま表示され、奇妙な状況になります。 クエリの99％以上が1つのアプリケーションによって実行されますが、時間が経つにつれて、スクリプトが表示され始めます。必要に応じてスクリプトを手動で実行するか、cronジョブを実行します。一部のデータ操作も、データベース自体で手動で実行されます。スクリプトと手動SQLクエリの両方に、無効な値が導入されるリスクが高くなります。 そしてここに私の質問が来ます： チェック制約なしで、最終的には外部キーなしでもリレーショナルデータベースをモデル化する理由は何ですか？ 価値のあることについては、この質問と私が受け取った回答（特にThomas Kilianとの興味深い議論）により、データベースの制約についての結論を書いた記事を書くことになりました。

46 database-design  relational-database  rules-and-constraints 

私はドメイン駆動設計（DDD）に飛び込んでいますが、さらに深く掘り下げていくと、得られないことがいくつかあります。私が理解しているように、主なポイントは、ドメインロジック（ビジネスロジック）をインフラストラクチャ（DB、ファイルシステムなど）から分離することです。 私が疑問に思っているのは、マテリアルリソース計算クエリのような非常に複雑なクエリがある場合、どうなりますか？この種のクエリでは、SQLが設計された種類の重いセット操作を操作します。ドメインレイヤー内でこれらの計算を行い、その中の多くのセットを操作することは、SQLテクノロジーを破棄するようなものです。 DDDパターンでは、ドメインレイヤーを変更せずにMongoDBにSQL Serverなどの同じ機能がないことを認識せずにインフラストラクチャを変更できるため、インフラストラクチャでこれらの計算を行うこともできません。 それはDDDパターンの落とし穴ですか？

44 domain-driven-design  database-design  sql  database-development 

企業向けのWebアプリケーションを構築していますが、これまでは管理がExcelシートにのみ存在していました。ほぼ完了しましたが、最近、これらのシートからすべてのデータを新しいシステムにインポートするタスクを割り当てられました。システムはJavaで構築されていますが、このインポートは一度だけなので、代わりにPythonでスクリプトを記述し、SQLクエリで直接インポートすることにしました。ここに問題があります。新しいデータモデルには、既存のデータに含まれていないいくつかの新しい属性が含まれています。ほとんどの場合、これは問題ではなく、情報が見つからない場所にnullを置くだけです。しかし、その後、いくつかの属性に遭遇しました。これらの属性はブール値であり、デフォルトではNULLにはできません。最初に、データベース内のこれらのフィールドにnullを許可しようとしましたが、シニア開発者から許可しないように指示されました。将来的にシステムで問題が発生する可能性があるためです。そして今、私は何をすべきかよく分からない。明らかな解決策は、すべての不明なブール値をfalseにデフォルト設定することですが、それも間違っていると思います。 例：hasRadioパラメーターを持つエンティティCarがあるとします。ここで、このデータモデルにデータをインポートする必要がありますが、データには「Model」列と「Color」列のみがあり、無線の有無は関係ありません。設計上nullにできない場合、「hasRadio」列に何を入れますか？ この状況での最善のアプローチは何ですか？不足しているデータを手動で入力するように会社に伝える必要がありますか？または、デフォルトでfalseになっていますか？

38 programming-practices  database-design