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

データベースの設計とは、データベースの構造、つまりデータベースの論理的な側面を指定するプロセスです。データベース設計の目標は、データベースがモデル化しようとしている事実の種類、ビジネスルール、およびその他の要件である「談話の世界」を表現することです。

11
ユーザーエージェント文字列はどのくらい大きくできますか？
ユーザーエージェントをデータベースに保存する場合、どれくらいの大きさに対応できますか？ UAを200未満に保つことを推奨するこのtechnetの記事を見つけました。これは、少なくともHTTP仕様で定義されているようには見えませんが、私が見つけたものではありません。私のUAは既に149文字で、.NETの各バージョンがそれに追加されるようです。 文字列を解析して分解できることはわかっていますが、できません。 このブログに基づく編集 IE9は、短いUA文字列を送信するように変更されます。これは良い変更です。
5
多言語データベース設計のベストプラクティスは何ですか？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 多言語データベースを作成する最良の方法は何ですか？すべてのテーブルのローカライズされたテーブルを作成すると、デザインとクエリが複雑になり、他の場合、各言語の列を追加するのは簡単ですが動的ではありません。エンタープライズアプリケーションに最適なものを理解してください。
12
MySQLの主キーを削除する
user_customersをライブMySQLデータベースの権限にマップする次のテーブルスキーマがあります。 mysql> describe user_customer_permission; +------------------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | user_customer_id | int(11) | NO | PRI | NULL | | | permission_id | int(11) | NO …
11
データベースのレコードをバージョン管理する方法
データベースにレコードがあり、管理者と一般ユーザーの両方が更新を実行できるとします。 レコードを前のリビジョンにロールバックできるように、このテーブルのすべての変更をバージョン管理する方法について、良いアプローチ/アーキテクチャを誰かが提案できますか？
10
10進数の列にお金を格納する-どのような精度とスケール？
10進数の列を使用してmoney値をデータベースに格納していますが、今日はどの精度とスケールを使用するのか疑問に思っていました。 固定幅のcharカラムと思われる方が効率的であるため、10進数のカラムでも同じことが当てはまると考えていました。それは...ですか？ また、どの精度とスケールを使用すればよいですか？精度は24/8だと思っていました。やりすぎですか、それとも十分ですか？ これは私がやろうと決心したことです： 変換率（該当する場合）をフロートとしてトランザクションテーブル自体に格納します 通貨をアカウントテーブルに保存する 取引金額は DECIMAL(19,4) 変換率を使用するすべての計算はアプリケーションで処理されるため、丸めの問題を管理します コンバージョン率の浮動小数点数は問題ではないと思います。これは主に参照用であり、とにかくそれを小数にキャストするからです。 貴重なご意見、ありがとうございました。
19
代理キーと自然キー/ビジネスキーの比較[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、事実と引用で回答できるようにします。この投稿を編集。 6年前休業。 この質問を改善する ここで再び行きます、古い議論はまだ起こります... ビジネスキーを主キーとして使用した方がよいでしょうか、それとも、ビジネスキーフィールドに一意の制約がある代理ID（つまり、SQL Server ID）を使用した方がよいでしょうか。 理論を裏付ける例や証拠を提示してください。
12
タグ付けのためのデータベース設計
次のタグ付け機能をサポートするデータベースをどのように設計しますか？ アイテムには多数のタグを付けることができます 特定のタグセットでタグ付けされたすべてのアイテムの検索は高速である必要があります（アイテムにはすべてのタグが必要であるため、OR検索ではなくAND検索です）。 アイテムの作成/書き込みは、迅速な検索/読み取りを可能にするために遅くなる可能性があります 理想的には、（少なくとも）n個の特定のタグのセットでタグ付けされたすべてのアイテムのルックアップは、単一のSQLステートメントを使用して実行する必要があります。検索するタグの数やアイテムのタグの数は不明であり、数が多い場合があるため、JOINを使用することは現実的ではありません。 何か案は？ これまでのすべての答えをありがとう。 しかし、私が間違っていない場合、与えられた答えはタグでOR検索を行う方法を示しています。（1つ以上のnタグを持つすべてのアイテムを選択します）。効率的なAND検索を探しています。（すべてn個のタグを持つアイテムをすべて選択します。
13
履歴データを保存する方法
一部の同僚と私は、履歴データを保存するための最良の方法について議論しました。現在、一部のシステムでは、個別のテーブルを使用して履歴データを格納し、現在のアクティブなレコード用に元のテーブルを保持しています。それでは、テーブルFOOがあるとします。私のシステムでは、すべてのアクティブなレコードはFOOに入り、すべての履歴レコードはFOO_Histに入ります。ユーザーはFOOのさまざまなフィールドを更新できるため、更新されたすべての情報を正確に把握したいと考えています。FOO_Histは、自動インクリメントHIST_IDを除いて、FOOとまったく同じフィールドを保持します。FOOが更新されるたびに、次のようなFOO_Histへの挿入ステートメントを実行しますinsert into FOO_HIST select * from FOO where id = @id。 私の同僚は、これは設計が悪いと言います。これは、履歴上の理由でテーブルの正確なコピーを用意する必要がなく、履歴用であることを示すフラグを付けて別のレコードをアクティブテーブルに挿入する必要があるためです。 履歴データストレージを処理するための標準はありますか？100万レコードをはるかに超える可能性があることを考えると、同じテーブル内のすべての履歴レコードでアクティブレコードを乱雑にしたくないようです（私は長期的に考えています）。 あなたまたはあなたの会社はこれをどのように扱いますか？ 私はMS SQL Server 2008を使用していますが、回答を汎用的で任意のDBMSに限定したいと思います。
26
データベースの1対1の関係を使用することが理にかなっている時期はありますか？
先日、正規化について考えていましたが、データベースに1対1の関係があるはずがないと思いました。 Name:SSN？同じテーブルに入れます。 PersonID:AddressID？繰り返しますが、同じテーブルです。 1対多または多対多の適切な中間テーブルを使用して、膨大な数の例を思い付くことができますが、1対1になることはありません。 私は何か明白なものを見逃していますか？
10
（別の長さではなく）VARCHAR（255）が頻繁に使用されるのを確認する理由はありますか？
複数のコース、本、および仕事で、VARCHAR（255）として定義されたテキストフィールドを「短い」テキストのデフォルトの一種として見ました。良い丸めの数字である以外に、 255の長さが頻繁に選択される理由はありますか？正当な理由があった過去のある時点からのホールドアウトですか（それが今日適用されるかどうかにかかわらず）？ もちろん、ストリングの最大長がどういうわけかわかっている場合は、より厳しい制限がより理想的であることを理解しています。ただし、VARCHAR（255）を使用している場合は、おそらく最大長がわからないことを示していますが、それは「短い」文字列であることだけを示しています。 注：私はこの質問を見つけました（VARCHAR（255）V TINYBLOB V TINYTEXT）、VARCHAR（と言っていたnが）必要とn個の保存の1バイトのn <= 255、n個のストレージの2つのバイトをn個 255>。これが唯一の理由ですか？VARCHAR（256）と比較して2バイトしか節約できず、VARCHAR（253）と宣言することで、簡単に別の2バイトを節約できるため、それは一種の恣意的なようです。
14
サブクエリと結合
次のようなサブクエリの代わりに内部結合を使用するために、別の会社から継承したアプリケーションの遅いセクションをリファクタリングしました。 WHERE id IN (SELECT id FROM ...) リファクタリングされたクエリは、約100倍速く実行されます。（〜50秒から〜0.3）改善が期待されていましたが、それがそれほど劇的だった理由を誰かが説明できますか？where句で使用される列にはすべてインデックスが付けられました。SQLはクエリをwhere句で行ごとに1回実行しますか？ 更新 -結果の説明： 違いは「where id in（）」クエリの2番目の部分にあります- 2 DEPENDENT SUBQUERY submission_tags ref st_tag_id st_tag_id 4 const 2966 Using where vs結合された1つのインデックス付き行： SIMPLE s eq_ref PRIMARY PRIMARY 4 newsladder_production.st.submission_id 1 Using index
2
SQL ON DELETE CASCADE、削除はどのように行われますか？
次のように、データベースに2つの関係がある場合： CREATE TABLE Courses ( CourseID int NOT NULL PRIMARY KEY, Course VARCHAR(63) NOT NULL UNIQUE, Code CHAR(4) NOT NULL UNIQUE ); CREATE TABLE BookCourses ( EntryID int NOT NULL PRIMARY KEY, BookID int NOT NULL, Course CHAR(4) NOT NULL, CourseNum CHAR(3) NOT NULL, CourseSec CHAR(1) NOT NULL ); そして、私はこのように2つの間に外部キー関係を確立します： …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.