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

私はプログラマーですが、アーキビストとしても働いています。アーキビストとして、データを保持することが重要です。 データの操作に関しては、同僚と議論することがよくあります。CRUDのUとDはあまり好きではありません。レコードを更新するのではなく、新しいレコードを追加して、古いレコードへの参照を作成することをお勧めします。そのようにして、変更の履歴を作成します。また、レコードを削除するのも嫌いですが、非アクティブとしてマークします。 これに用語はありますか？基本的にデータの作成と読み取りのみですか？このアプローチの例はありますか？

14 terminology  database-design  data  crud 

これは、マイクロ管理のための小規模な個人プロジェクト用です。基本的に、次のようなSQLite3データベースにタスクを保存します。 id INTEGER PRIMARY KEY AUTOINCREMENT label TEXT deadline INTEGER そのため、各タスクには、Unixタイムスタンプとして保存される期日（期限）があります。これまでのところ、「明日：おばあちゃんを訪問」などのエントリを作成し、「おばあちゃんを訪問」というラベルを付けて新しい行を作成し、明日を期限のUNIX時間として変換します。 次に、新しいタイプのタスクを入力します：ルーチン-「毎日：クリーンキッチン」のような時間パターンで繰り返されるタスク。そのようなタスクをどのように保存またはモデル化できますか？ とりあえず、毎日実行する必要があるタスクの場合、同じラベルを持つ新しい行をテーブルに生成し、期限フィールドを1日増やします。この場合、将来的に制限を修正する必要があります。たとえば、毎日のルーチンを作成すると、残りの年の毎日の新しい行が作成されます。 これを行う簡単な方法はありますか？明らかなデータベース設計の原則が欠けていますか？

14 database-design 

データベーススキーマでは、VARCHARサイズがバイトオフセット128/256または4096に丸められることがよくあります。これも以前に行ったことがあり、その背後にあるアイデアはおそらく効率的なものでした。 しかし、今日そうする正当な理由はまだありますか？最近ではVARCHARサイズとして '50'、 '100'、または '200'をよく使用します。これらはより自然で、通常はユーザーに対する検証チェックでも表示されるためです。

14 database  database-design 

Oracleプログラマーなどについて読むたびに、混乱します。私は彼らが何をするのか正確には知りません。 私の理解では、アプリケーションプログラマはコア機能を開発する必要があります。彼らが使用するライブラリは、GUI開発やデータベース接続に役立つかもしれませんが、そのアプリケーションをプログラムする必要があり、すべてのアプリケーションを異なるものにする機能があります（他のものの微調整バージョンもあります）。 この関係では、データベースプログラミングは基本的にテーブルを作成しておらず、これらのテーブルは、通常フロントエンドであるアプリケーションによって発行されたSQLステートメントに応答して処理されませんか？テーブルの作成は大したことですか？

14 database  database-development  database-design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私は主にWeb開発者であり、キックオフしたい個人的なプロジェクトがいくつかあります。 私を悩ませているのは、データベースの設計です。私は学校のdb正規化などを経験しましたが、それは数年前であり、学校を除いてリレーショナルデータベース設計の経験はありませんでした。 それでは、Webアプリの観点からどのようにデータベースにアプローチしますか？どのように始めますか、何に注目していますか？注意すべきフラグは何ですか？

14 learning  database-design 

最近、いくつかのレガシーシステムに取り組み始めました。それを開発した人々は、データベーステーブルの単一のフィールドに文字列のリストを格納するというアイデアを思いつきました。これは、データベースに表現もデータもないオブジェクトの識別子であるとしましょう。その識別子の範囲は、本番環境では比較的小さくなります。 一方、私の直感と「良いデザインの好み」は、別のテーブルで表現する必要があることを示しています（多対多の関係を表すために使用されるテーブルと同様）。 彼らのアプローチは本当に悪いのですか？リファクタリングを開始する方が良いでしょうか？はいの場合、元の設計が将来どのような悪影響をもたらす可能性がありますか？そのアプローチを説明するリレーショナルデザインの原則はありますか？ コメントの返信を編集： おそらく、彼らはこのアプローチを使用して、階層構造化などの特定の問題を巧妙な方法で解決していません。最もありそうなシナリオは、彼らが時間のプレッシャーの下で単に働いていて、できるだけ早く新機能を実装する必要がある場合でした。 以前はフィールドが単一の値を表していたと思います。彼らは複数の値を保存する機能を実装する予定で、データベースの移行を回避しようとしました。

14 database  database-design  data-structures  relational-database 

私はプロジェクトに取り組んでいます。ある時点で、データベースに、すべてのレコードが使用するわけではない複数の列を持つ単一のテーブル、または複製されたスキーマを持つ複数のテーブルが必要かどうかを決定する必要がありました。 複数のスポーツを処理できるスポーツ情報アプリケーションを作成しています。たとえば、NBA、NHL、MLB、NFLを処理できます。各スポーツには、チーム、スケジュール、怪我、選手情報など、非常に似た概念があります。 もちろん、データソースは同じスキーマ内の各データを提供しません。各スポーツには、ベンダーからデータを受け取る異なるスキーマがあります。 共通性を判断するためにデータフィードの事前分析を行うのに十分な時間（クライアントの要求）がなかったため、賭けをヘッジし、「安全な賭け」を行い、すべてのテーブルのセットの代わりに、スポーツごとに個別のテーブルを作成しました使用されるスポーツ。 その結果、いくつかのテーブルでスキーマが複製され、データベースへのインターフェイス（ストアドプロシージャなど）も複製されます。NBA_Game、NFL_Game、NBA_Team、NFL_Teamなどがあります。各テーブルには、他のテーブルにはないプロパティがいくつかあり、いくつかのプロパティは共有されています。4〜5回のスポーツで5〜10個のテーブルが続きます。これが完全に悪いことであるかどうかはまだわかりません。すべてのスポーツが使用するわけではないプロパティを持つテーブルの単一セットを持つ代替案は、それ自体も扱いにくいかもしれません。 これを行った人は、この種の設計の落とし穴にぶつかり、ここで自分の経験を共有できますか？将来の困難な方法を学ぶのではなく、今私が知るのに役立つかもしれないことは何ですか？すべてのレコードが使用するわけではない列を使用して、1つの大きなテーブル/テーブルのセットを使用して、別の方法でそれを実行しましたか？どんな落とし穴に遭遇しましたか？ 過去に使用したテーブル継承など、より適切に機能する代替手段はありますか？ ありがとう

13 database  database-design  relational-database 

CAP定理（整合性、可用性、パーティション：2つを選択）を持たない限り、いわゆる "NoSQL"データベースについて話すことはできません。MongoDB（Partition、Consistency）とCouchDB（Availability、Partition）の間で言う必要がある場合、最初に考える必要があるのは「正しいデータが必要ですか、それとも常時アクセスする必要がありますか？」です。 これらの新しいデータベースは、パーティション分割されるように作成されました。しかし、私がそうしないとどうなりますか？リレーショナルデータベースではなく、キー/値、列、ドキュメントなどのデータベースを持ち、サーバーインスタンスを1つだけ作成し、決してシャードしないのが非常にクールだと思ったらどうでしょうか。その場合、可用性と一貫性の両方はありませんか？MongoDBは何も複製する必要がないため、利用可能になります。また、CouchDBにはデータのソースが1つしかないため、かなり一貫性があります。 それで、その場合、MongoDBとCouchDBはユースケースの用語にほとんど違いがないことを意味しますか？もちろん、パフォーマンス、API、およびその他は除きますが、基本的に異なる2つの要件セットを持つよりも、PostgreSQLとMySQLを選択することに似ています。 私はここにいますか？複数のインスタンスを作成しないことで、APまたはCPデータベースをACデータベースに変更できますか？それとも私が行方不明になっているものがありますか？ 逆に質問してみましょう。リレーショナルデータベースを使用し、MySQLを使用して、それをマスター/スレーブ構成にするとどうなりますか。ACIDトランザクションを使用しません書き込みをすぐにスレーブに同期する必要がある場合、それをCPデータベースにしませんか？そして、事前に定義された間隔で同期するとどうなりますか。クライアントがスレーブから古いデータを読み取っても問題はありません。それがAPデータベースになりませんか？これは、ACIDコンプライアンスを放棄しても、パーティション分割されたデータベースにリレーショナルモデルを使用できるという意味ではないでしょうか。 本質的には、基になるデータモデルよりも、CAP定理で放棄する準備ができているものについてのスケーラビリティですか？列、ドキュメント、キーバリューなど、リレーショナルモデルよりもスケーラビリティを高めるものはありますか？パーティショントレランスのためにゼロから設計されたリレーショナルデータベースを設計できますか？（たぶんそれはすでに存在します）。NoSQLデータベースをACIDに準拠させることはできますか？ 申し訳ありませんが、多くの質問がありますが、最近NoSQLデータベースについて多くのことを読みました。それらを使用することの最大の利点は、パーティションCAPだけでなく、データの「形状」により良くフィットすることですACIDコンプライアンスを放棄します。結局のところ、誰もがデータを分割するのに必要なほど多くのデータを持っているわけではありません。データのパーティション分割について考える前に、リレーショナルモデルを使用しないことでパフォーマンス/スケーラビリティの利点がありますか？

13 database-design  nosql  scalability 

バックグラウンド このテーブルがあります +-------------------------+ +------------------------+ |Airport | |Country | |-------------------------| |------------------------| |airport_code string (PK) | |country_code string (PK)| |address string | |name string | |name string | +------------------------+ +-------------------------+ +-------------------------+ |Currency | |-------------------------| |currency_code string (PK)| |name string | +-------------------------+ airport_codeは、IATA（国際航空運送協会）の 空港コードです。飛行機で旅行する場合は、荷物タグで確認できます。 country_codeはISO 3166-1 A3標準の国コードです。オリンピックで見ることができます。 currency_codeは、IS0 417標準の3文字の通貨コードです。国際通貨交換の表示板で確認できます。 ご質問 これらの自然なPKは十分ですか？ 業界全体で受け入れられているPKにとって十分な世界的に尊敬されている標準を使用していますか？ この表には、何があっても代理変数が必要ですか？

13 design  database-design  relational-database  rdbms  surrogate-keys 

最初に、ステータス列は、テーブル内のレコード（行）で表される実際のアイテムのステータスを反映するものではないことを明確にする必要があります。むしろ、レコード自体のステータスを表示することを目的としています。 これは、アクティブ/非アクティブとして、単純なようであるかのように複雑なことができます承認/削除された/ロック/保留/拒否などのステータスがマッピングで、ブール/短整数の列または単一文字列に保存することができるようにtrue/ 1=アクティブまたはA=承認済み。 基本的な考え方は、アプリケーションでごみ箱/ゴミのような回復をサポートすることです（データベースでシミュレートします）。ユーザーがレコードを「削除」できると思われるフロントエンドGUIまたはその他のインターフェイスがある場合、テーブル内のレコードは実際には削除されず、単にレコードのステータスが非アクティブまたは削除済みに変更されます。インターフェイスがレコードをフェッチするとき、ステータスがアクティブまたは承認済みであるという条件にのみ一致するレコードを常に取得します。 ユーザーがミスを犯し、「ユーザーの観点から」「削除された」レコードを回復する必要がある場合、DBAはレコードを簡単に修正してアクティブまたは承認済みに戻すことができます。そこ。または、インターフェイス自体で、ユーザーが削除されたレコードを別のビューで表示し、必要に応じてそれらを復元したり、完全に削除したりすることもできます（実際のレコードを削除します）。 私の質問： これは良い習慣ですか、それとも悪い習慣ですか？ データの正規化に影響しますか？ 潜在的な落とし穴は何ですか？ 同じ目標を達成する代替方法はありますか？（ノートを参照してください） 特定のステータスのデータに対してのみデータベースに一意の制約を適用するにはどうすればよいですか（ただし、他のステータスの重複をいくつでも許可します）。 データベースがネイティブで「ごみ箱」のような機能やテーブルトラッキング/リカバリを提供しないので、心配せずにインターフェイスで実際のレコードを削除できます。 注：別の履歴テーブルを維持することについて読みましたが、ストレージの観点からは悪く、トリガーを生成し、追跡テーブルのスキーマでトリガーを最新に保つ必要があるようです。

12 database-design 

私は自分の会社で作業しているデバイスで発生するトランザクションを追跡するリレーショナルデータベースの開発に取り組んでいます。デバイスで発生する可能性のあるトランザクションにはさまざまなタイプがあるため、メインレコードテーブルの1つに「trans_type」フィールドがあります。私のグループは、このフィールドの型を整数にし、列挙型として扱うことにしました。私の直感では、このフィールドを文字列にしてデータベースのデータをより読みやすく使いやすくすることをお勧めします。私の同僚は、これが価値以上のトラブルを引き起こすのではないかと心配しているようです。文字列の比較はコストがかかりすぎるため、タイプミスの可能性はあまりにも大きな障壁です。 したがって、あなたの意見では、本質的に列挙値であるリレーショナルデータベースのフィールドを扱うとき、このフィールドを整数または文字列にする方が設計上の判断が優れていますか？または、私が見落とした他の選択肢はありますか？ 注：明示的な列挙型は、使用しているデータベースではサポートされていません。そして、このデータベースとのインターフェースとなる開発中のソフトウェアはC ++で書かれています。

12 database-design  relational-database 

これは基本的に、弱いエンティティとは何かに関する質問ですか？それらをいつ使用する必要がありますか？どのようにモデル化する必要がありますか？ 通常のエンティティと弱いエンティティの主な違いは何ですか？ドメイン駆動設計を行う場合、脆弱なエンティティは値オブジェクトに対応しますか？ ここでトピックに関する質問を続けるのを助けるために、人々がこれらの質問に答えるために使用できるウィキペディアから取られた例です： この例でOrderItemは、弱いエンティティとしてモデル化されましたが、通常のエンティティとしてモデル化できない理由を理解できません。 もう1つの質問は、注文履歴（つまり、ステータスの変更）を追跡したい場合、それは通常のエンティティまたは脆弱なエンティティでしょうか？

12 design  database  database-design  entity 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はXML形式と次の引用について考えていました。 「XMLはデータベースではありません。データベースになることを意図したものではありませんでした。データベースになることはありません。リレーショナルデータベースは、20年以上の実装経験を持つ実績のあるテクノロジーです。彼らは、固体、安定した、有用な製品です。彼らは去りません。XMLは、異なるデータベース間またはデータベースと他のプログラム間でデータを移動するための非常に便利なテクノロジーです。ただし、それ自体はデータベースではありません。いずれかのようにそれを使用しないでください「 - 。効果的なXML：50の具体的な方法をあなたのXMLを向上させることではElliotte Rusty Harold著（230ページ、パート4、項目41、第二段落） これは、XMLをデータストレージに使用すべきではなく、プログラム間の相互運用性にのみ使用すべきであることを本当に強調しているようです。 個人的にはapp.config、プログラムの設定を保存するために使用される.NETのファイルは、XMLファイルのデータストレージの例です。ただし、構成などではなくデータベースにはXMLを使用しないでください。 ポイントを開発するために、2つの例を使用します 。A）すべてが1レベルのフィールドを持つ顧客に関するデータ。つまり、子を持たない1人の顧客にすべて関連するいくつかのフィールド があります。とプロパティは非常に理にかなっています だから私の質問は、これはまだ有効なステートメントであり、XMLを使用してデータを保存することは現在受け入れられますか？ 編集：私は彼の入力/追加のコンテキストを求めるためにその引用の著者にメールを送りました。

12 database  database-design  xml 

データオブジェクトにカスタムフィールドを追加する機能を持つオブジェクトを設計するための、またはオブジェクトの独自のカスタム定義を作成するための一般的な戦略または設計パターンはありますか。たとえば、独自の種類の情報を持つことができるSalesForceなどの製品、Expression Engineなどのフレームワーク、およびチャネルとチャネルフィールドグループの処理方法（例）、またはwordpressのようなCMSの機能カスタム投稿タイプにフィールドを追加します。

12 design-patterns  database-design 

CMSシステムのデータベース構造を見つけましたが、このデータベースが作成されているEFでデータベース構造をコピーしたいのですが、GNU v2ライセンスの下にあるオープンソースソフトウェアのデータベース構造をコピーしても大丈夫ですか？ ソフトウェアの残りの部分はデータベース構造だけにしたくない。

12 licensing  database  database-design