問題タブ [data-modeling]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql - uniqueidentifier と ID
私は、asp_membership が uniqueidentifier を使用していることに気付きました。私には、スペースの無駄のように思えました。これを ID に置き換えない特別な理由が思いつかなかったからです。
ただし、SQL Server では int に変更できません。「接続されたデータベース サーバーでは、uniqueidentifier から int への変換はサポートされていません」と表示されます。グーグルで調べた後、すべての関係などを壊してから、列を手動で削除してintとして再度追加する必要があるようです。より良いアプローチを知っていますか?
複数のデータベースを扱うことはないと思うので、uniqueidentifier は不要のようです。同意しますか?
注意してください: 私は新しい Web アプリケーションを開始しています。これを修正するのは難しいと思いますか?
また、主キーは URL の一部ではないことに注意してください。
sql - これらは 3 つの SQL テーブルにする必要がありますか?それとも 1 つにする必要がありますか?
これは、この質問から生じた新しい質問です
回答により、質問の性質が変わったので、新しい質問を投稿しても問題ないと思います(?)。
以下に、私の元の DB デザインを示します。3 つのテーブルがあり、running_balances 計算のために特定のユーザーのすべてのレコードを取得するクエリが必要です。
- トランザクションは、相互信用のようにユーザー間で行われます。したがって、ユニットはユーザー間で交換されます。
- 発明化は、システムに持ち込まれる物理的なものです。ユーザーはこれに対して単位を取得します。
- 消費は消費される物理的なものです。ユーザーはこれに対して単位を支払う必要があります。
(「金額」は異なる単位であることに注意してください。これらはエントリであり、それらの金額に対して計算が行われます。理由を説明する範囲外ですが、これらはフィールドです)。
問題は、「これを 1 つのテーブルにすることができるか、それとも複数のテーブルにする必要があるか (今のところ)」です。意味的により理にかなっているので、私は 3 つのテーブル ソリューションが好きです。しかし、running_balances には複雑な select ステートメントが必要です (パフォーマンスが低下する可能性があります)。上記のリンクの元の質問は、このステートメントを求めていました。ここで、データベースの設計が適切かどうかを尋ねています (4 つの二重投稿をお詫びします。問題ないことを願っています)。
sql - データベースの設計を確認する / PHP/MySQL
私は現在、データベースの改善に取り組んでおり、成長の余地を作っています。現状では、さまざまなユーザーが Web サイトの領域に対してさまざまな「許可」を持っています。一部のユーザーは、Web サイトの複数の領域へのアクセス許可を持っています。
これを最も効率的な方法で行っている場合は、フィードバックをお願いします。
現在、「領域」ごとに個別のディレクトリがあります。ただし、これらのディレクトリをすべて 1 つのメイン ディレクトリに最小化し、ログイン時にユーザーを権限に基づいて適切な「領域」にリダイレクトしたいと考えています。
私はこれを正しくやっているように聞こえますか?私は、さまざまなパーミッションとさまざまな人々のグループを持つ多層サイトを作成したことがないので、これを正しく行う方法についてもっと学ぶことにオープンです。
どうもありがとう!
php - MySQL と PHP を使用して重複コンテンツを見つける
Web アプリの開発で問題に直面しています。説明は次のとおりです。
この Web アプリ (まだアルファ版) は、ユーザー生成コンテンツ (通常は短い記事ですが、長さが画面の約 4 分の 1 と非常に長くなる可能性があります) に基づいており、すべてのユーザーがこれらの記事を少なくとも 10 件送信するため、その数は急速に増加するはずです。性質上、約 10% の記事が複製されるため、それらを取得するためのアルゴリズムが必要です。
次の手順を思いつきました。
- 送信時にテキストの長さを取得し、それを別のテーブル ( ,length) に保存します。問題は、記事が PHP のspecial_entities
article_id
() 関数を使用してエンコードされ、ユーザーがコンテンツをわずかに変更して投稿することです (コンマ、アクセント、またはいくつかの単語を飛ばしても) - 次に、長さの範囲 = +/- 5% のデータベースからすべてのエントリを取得します
new_post_length
(記事の送信に関する人的要因を念頭に置いて、別のしきい値を使用する必要がありますか?) - 最初の 3 つのキーワードを取得し、手順 2 で取得した記事と比較します
- 最も可能性の高い一致を含む最終的な配列を取得し、PHP の levenstein() 関数を使用して新しいエントリを比較します
このプロセスは、cron を使用するのではなく、記事の送信時に実行する必要があります。ただし、サーバーに大きな負荷がかかると思います。
アイデアを教えてください。
ありがとうございました!マイク
sql - データベース設計に関するハードウェアのダブルチェックを探しています
皆さん、こんにちは...大学のデータベース設計クラスに取り組んでいます。以下に質問があります。ここで図を試してみましたhttp://tinypic.com/view.php?pic=httchc&s=3 .. 誰か見て、提案をしてくれませんか? 助けてくれてありがとう!!
質問:
質問 3 次の状況は、情報システムを導入したいと考えている会社を表しています。会社は、従業員、部門、およびプロジェクトを追跡したいと考えています。会社の MIS 部門が要件の収集と分析のフェーズを行い、次の説明を含む仕様レポートをあなたに渡したとします。
会社は、複数の場所を持つことができる部門に編成されています。各部門には、固有の名前、固有の番号、およびマネージャーがいます。会社は、各従業員が部門の管理を開始した日付を追跡します。
各部門は多数のプロジェクトを管理しており、各プロジェクトには固有の名前、固有の番号、および単一の場所があります。
会社は、各従業員の名前、社会保険番号、住所、給与、性別、生年月日を保存します。各従業員は 1 つの部門にのみ割り当てられますが、必ずしも同じ部門によって管理されるとは限らない複数のプロジェクトに取り組む場合があります。会社は、従業員が各プロジェクトで週に何時間働いたかを追跡します。会社はまた、各従業員の直属の上司を追跡します。
保険の目的で、会社は各従業員の扶養家族も追跡したいと考えています。会社は、各扶養家族の名、性別、生年月日、従業員との関係を記録したいと考えています。
この状況の EER ダイアグラムを描画します。
sql - 無限のサブカテゴリを持つサイトには、どのような種類のDB構造を使用する必要がありますか?
たとえば、「ドールバナナ」は一種の商品で、「バナナ」のカテゴリに表示されますが、「果物」のカテゴリを開くと、「ドールバナナ」が表示されます。
sql - char をプライマリ/外部キーとして使用することはできませんか?
「countries」または「currencies」テーブルにリンクするテーブルがたくさんあると考えてください。
データを読みやすくするために、国コード (US、GB、AU など) と通貨コード (USD、AUD) を含む CHAR フィールドをこれら 2 つのテーブルのそれぞれの主キーにし、他のすべてのテーブルはこの CHAR を次のように使用します。外国の鍵。
データベースは innodb エンジンを搭載した mysql です。
パフォーマンスの問題が発生しますか? それは私が避けるべきものですか?
sql - nvarchar(64) 列の代わりに、または追加の列として nvarchar(max) を使用する必要がありますか?
データベース内の特定のオブジェクトの履歴を追跡するためのテーブルを作成しています。現在、次の列があります。
ほとんどの場合、各履歴項目は HistoryTypeId によって一目瞭然であるため、HistoryDetails は Null または非常に小さい値になります。ただし、いくつかの履歴タイプでは、詳細データが大きくなります。すべてのレコードに nvarchar(max) を使用しても問題ありませんか、それとも分割して、64 文字を超える必要がある履歴タイプ用の列を追加する必要がありますか (以下を参照)。大まかな見積もりでは、レコードの 80% ~ 90% は 64 文字を超える詳細情報を必要とせず、テーブルには数百万のレコードが存在することになります。
sql - データベースのセットアップに関するヘルプ
私のサイトでは多くの製品を利用できますが、それらは完全に異なるサイト (ドメイン) に分類されます。
私の質問は、すべての製品を 1 つのデータベースにまとめて ID を使用してサイトを区別する方がよいでしょうか、それともサイトごとにテーブルや DB を設定する必要があるのでしょうか?
ここに私の考えがあります
別々のデータベース
- バックエンドからの読み取りが容易
- より良い分類
- バックアップがより困難になる
- スキーマを変更する必要がある場合は、すべてのデータベースにプッシュする必要があります
同じデータベース
- すべてが 1 か所に
- 扱いにくくなる可能性があります
- 1 つのデータベースのファイル サイズが膨大になり、ルックアップに問題が生じる可能性があります
どの方法が最適で、その理由についてアドバイスをいただけますか?
sql - DBの整合性:トリガーとキー/制約
私と私の友人は、データベースの設計について互いに議論しました。
彼は、複雑なデータベースの整合性を確保するには、トリガーを使用する方がよいと主張しています。
この目的には、キー(プライマリ、一意)、および制約を使用する方がよいと思います。
トリガーの使用は「舞台裏」で機能し、コマンドの実行後に何が起こるかを言うのは簡単ではないため、危険だと思います。さらに、トリガーにバグがある場合、DBの整合性を損なう可能性があります。
あなたはそれについてどう思いますか?