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

私はリレーショナルデータベースでかなりの作業を行ってきましたが、優れたスキーマ設計の基本概念はかなりよく理解していると思います。私は最近、DBが高給コンサルタントによって設計されたプロジェクトを引き継ぐことを任されました。私の腸の本能-「WTF ??！？」-保証されていますか、それともこの男は私の天才であるかのような天才ですか？ 問題のDBは、従業員からのリクエストを入力するために使用される社内アプリです。そのほんの一部を見るだけで、ユーザーに関する情報と、行われているリクエストに関する情報が得られます。私はこれを次のように設計します： ユーザー表： UserID (primary Key, indexed, no dupes) FirstName LastName Department リクエスト表 RequestID (primary Key, indexed, no dupes) <...> various data fields containing request details UserID -- foreign key associated with User table シンプルでしょ？ コンサルタントは次のように設計しました（サンプルデータを使用）。 UsersTable UserID FirstName LastName 234 John Doe 516 Jane Doe 123 Foo Bar …

61 database  sql  schema 

私の経験では、過去に読んだプロジェクトの多くは、データベースにリレーションシップ定義を持たず、代わりにソースコードでのみ定義していました。だから私は、データベースとソースコード内のテーブル間の関係を定義することの利点/欠点は何なのかと思っていますか？より広範な質問は、カスケード、トリガー、手順などの現代のデータベースの他の高度な機能に関するものです...私の考えにはいくつかのポイントがあります。 データベース内： 設計からの正しいデータ。無効なデータを引き起こす可能性のあるアプリケーションエラーを防ぎます。 アプリケーションがデータの整合性をチェックするためにより多くのクエリを作成する必要があるため、データを挿入/更新する際のアプリケーションへのネットワークラウンドトリップを削減します。 ソースコード内： より柔軟。 複数のデータベースにスケーリングする場合は、リレーションがクロスデータベースになることがあるため、より良いです。 データの整合性をさらに制御します。データベースは、アプリケーションがデータを変更するたびに確認する必要はありません（複雑さはO（n）またはO（n log n）（？）です）。代わりに、アプリケーションに委任されます。また、アプリケーションでデータの整合性を処理すると、データベースを使用するよりも詳細なエラーメッセージが表示されると思います。たとえば、APIサーバーを作成するときに、データベースでリレーションを定義すると、何かが（参照されているエンティティが存在しないなど）うまくいかない場合、メッセージとともにSQL例外を受け取ります。簡単な方法は、「内部サーバーエラー」が発生したことをクライアントに500で返すことであり、クライアントは何が問題なのかわかりません。または、サーバーはメッセージを解析して何が間違っているのかを判断できます。これはmyい、エラーが発生しやすい方法です。アプリケーションにこれを処理させると、 他に何かありますか？ 編集：Kilianが指摘しているように、パフォーマンスとデータの整合性についての私の論点は非常に間違っています。そこで、自分のポイントを修正するために編集しました。データベースで処理できるようにすることは、より効率的で堅牢なアプローチになることを完全に理解しています。更新された質問を確認して、それについて考えてください。 編集：みんなありがとう。私が受け取った答えはすべて、制約/関係をデータベースで定義する必要があることを指摘しています。:)。もう1つ質問がありますが、この質問の範囲外であるため、別の質問として投稿しました：APIサーバーのデータベースエラーを処理します。いくつかの洞察を残してください。

60 mysql  relational-database  schema  rdbms 

Googleがページマークアップデータに重点​​を置く方向に移行していることを考えると、Schema.orgで使用されるデータ形式は、Microformatsのデータ形式とどのように連携しますか？これら（および他の仕様）はどのように互いに補完し合い、異なる状況で優先的に使用されるべきですか？ 編集： 主題に関する確立された内容から、意見はSchema.orgが破滅的で、地獄の火薬であり、取り締まりであると信じる人々と、それがいずれにせよ最終的には良いことだと考える人々の間で意見が分かれているようです。 両方の記事は、少なくとも、検索エンジンに過度の悲しみを引き起こすことなく、さまざまな形式が楽しく共存できることに同意します。ただし、特定のケースでさまざまなオプションがどのように使用されるかについての疑問は残っています。

19 html  data  search  schema 

ゼロダウンタイムの展開の実現には同じ問題が関係していましたが、検討している戦略に関するアドバイスが必要です。 環境 サーバー側の処理にApache / PHPを使用し、永続性にMySQL DB / filesystemを使用するWebベースのアプリケーション。 現在、インフラストラクチャを構築しています。すべてのネットワークハードウェアには冗長性があり、すべてのメインネットワークケーブルは、フォールトトレランスのためにボンディングペアで使用されます。サーバーは、ハードウェアフォールトトレランス用の高可用性ペアとして構成されており、仮想マシンのフォールトトレランスと一般的なパフォーマンスの両方で負荷分散されます。 私は、ダウンタイムなしでアプリケーションに更新を適用できることを意図しています。100％の稼働時間を提供できるように、インフラストラクチャを設計する際に多大な苦労をしました。更新が適用されるたびに10〜15分のダウンタイムが発生するのは非常に残念です。これは、リリースサイクルを非常に高速にすることを意図しているため、特に重要です（1日あたり1つ以上のリリースに達することがあります）。 ネットワークトポロジー これはネットワークの要約です： Load Balancer |----------------------------| / / \ \ / / \ \ | Web Server | DB Server | Web Server | DB Server | |-------------------------|-------------------------| | Host-1 | Host-2 | Host-1 | Host-2 | |-------------------------|-------------------------| Node A \ …

14 deployment  schema  strategy  downtime 

NoSQL対SQLデータベースに関する議論で、スキーマを新しいバージョンに移行するのは問題があるため、企業はスキーマレスのNoSQLデータベースを使用することを好むと聞きます。しかし、アップグレードを行うとき、それは本当に大きな問題ですか？リレーショナルデータベースは、このような操作に悪いですか？ MongoDBブログの次のブログ投稿を読んでください。なぜSchemalessなのですか？

13 database  nosql  relational-database  schema 

製品ミックスによって価格が異なる会社の新しいPOSに取り組んでいます。 すべての製品に基本価格があります。 私の問題を説明するために、私は次の情報を使用します： Product Category Price A 1 45 B 1 70 Q 2 20 R 2 27 S 2 15 X 3 17 Y 3 22 Z 3 16 会社にはパッケージがあります（パッケージ「コンボ」など）。製品AまたはBの場合、QまたはRのいずれかを選択し、X、Y、またはZのいずれかを選択すると、20ドルの割引が適用されます。 ケースA：注文時にベース商品に追加する場合があります。たとえば、商品Aではなく、商品Qと商品Pを追加して、割引価格のパッケージを作成します。次に、1つのRと1つのZを持つ1つの製品Bが必要であると追加します。 ケースB： 1 Aと2 B、2 Q、1 S、2 Xと1 Zを追加する場合があります。「コンボ」パッケージで規定されているルールに従って、Sはコンボアイテムではないため、2つのコンボのみが適用されます。 その他のプロモーションは数量に依存するため、Bを2つ購入すると20％オフまたは時間に依存し、午後5時以降または午前10時前の場合は10％オフ前にのみ有効です。別のプロモーションは、最後の購入がいつ行われたか、またはY期間に$ Xを超えて購入したかどうかによって異なります。 私の問題： 1）さまざまな要件を持つさまざまなタイプのプロモーションを追加するのに非常に柔軟な方法で、さまざまなパッケージまたはプロモーションを作成できるように、テーブルをどのように構成しますか？ 2）ケースB（またはケースAとケースBの組み合わせ）のように注文した場合、クエリを構造化して、注文に含まれる製品の組み合わせを確認し、それに応じて価格/説明を更新する方法？最終的に、このクエリの最良の結果は、どのパッケージとプロモーションが要件を満たし、その順に顧客に最もメリットがあるかを返します（つまり、注文したものがプロモーション1と3の要件を満たしますが、プロモーション3の方が安価です）。複数のプロモーションで機能する必要があります）。 助けてくれてありがとう！ アップデート＃1 目前の問題をよりよく説明し、これまでに行った作業を更新して問題を解決するために、問題に影響を与えるエンティティと属性に限定された製品モデルのERDを含めています（つまり、ここでは在庫が機能していないため、在庫はありません）エンティティが存在します）。 この質問に影響を与えるエンティティと属性からのサンプルデータも含めています（データの読み取りを簡単にするために、外部キーの代わりに名前/説明を入れています）。 これは、コンボの例を示すフローチャートへのリンクであり、テーブル構造を理解するための高速で視覚的な方法です。 …

11 web-development  database  database-design  schema  relationships 

メタデータを管理および作成するためにタグ付け/マークアップシステム（http://www.schema.org/など）を使用する場合に比べて、RDFS / OWLのオントロジー言語にはどのような利点があるのでしょうか。

10 schema  tagging  semantic-web 

データベーススキーマの質問に対するいくつかの回答は、現在の要件の一部ではない機能のデータベースを正規化するための追加のテーブルを提案しました（UserDepartmentテーブルは、従業員/ユーザーとそれらが異なる部門との多対多の関係を可能にします属します。） 正規化に反対ではありません。データベースの設計に関しては、誰かが将来的に望んでいると確信している機能を含めるように強く求められているようです。テーブル/フィールドをデータベースに追加して機能に対応することは、過度に設計する傾向があるので難しいですか？必要に応じて、他のアプリと同じようにリファクタリングまたはアップグレードされませんか？やり直しは決して楽しいものではありませんが、データをあるテーブルから新しいテーブルに移動することはできます。この考え方がどこで終わるのかわからない。 編集：これには多くの嫌悪感があります。データベースの大幅な変更を必要とする機能を追加しないプロジェクトや、新しいテーブルの代わりにDepartmentID2フィールドを追加するなどの非正規化されたアプローチがいくつあるのでしょうか？従業員が複数の部署を必要とすることは、よくあるドメインの問題です。多対多の関係で散らかされている多くのデータベーススキーマに気づかなかっただけです。

9 design  database  refactoring  schema 

いくつかの幼稚園から高校まで、一部の大学で使用されているオープンソースのPHP / MySQL Webアプリケーションを管理しています。私はプロジェクトの唯一の開発者でもあります。以前は、雇用主がホストするアプリケーションのソースダウンロードに過ぎませんでしたが、昨年、ドキュメント、番号付きリリース、公開変更ログなどを含む「本物の」オープンソースプロジェクトにするために取り組んできました。 アップグレードプロセスの改善を目指しています。特にITの専門家が不足している学校にとって、痛みを伴う可能性のある分野の1つは、リリース間でのデータベーススキーマの変更です。それらは頻繁に発生したり、大幅な変更になる傾向はありませんが、プロセスに関する提案をいただければ幸いです。 現在、データベースを新規インストールでセットアップするためのベースSQLインストールスクリプトを維持しています。これには、現在のリリースの完全なスキーマが含まれます。新規インストールの場合、これ以上のアクションは必要ありません。リリース間で発生する変更はupgrade-$releasever.sqlスクリプトに保存されます。スキップされたリリースについては、すべてのアップグレードスクリプトを段階的に実行する必要があります。 ユーザーの多くはシェルアクセスなしでホストを操作するため、シェルスクリプトは適していません。他の優先事項により、複雑なPHPブラウザーベースのインストーラー/アップグレードスクリプトが実現する可能性は低いです。ただし、アップグレードを簡素化するために、ブラウザーベースのPHPスクリプトを使用して何かを実行したいと思います。それへのアプローチ方法に関する提案？

9 database  release  upgrade  schema