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

概念スキーマおよび/または論理モデルおよび/またはデータベースの物理設定の開発。

7
データベースにメールアドレスを保存するデータ型は何ですか？
254文字の電子メールアドレスが有効であることは理解していますが、調査した実装では、varchar（60）からvarchar（80）または同等のものを使用する傾向があります。例：このSQL Serverの推奨事項では、varchar（80）またはこのOracleの例を使用しています 最大254文字の最大文字数を使用しない理由はありますか？定義上、varcharはデータを保持するために必要なだけのストレージを使用しませんか？ 非常に多くの実装で使用可能な254文字よりも少ない文字を使用する、パフォーマンスへの重要な意味/トレードオフがありますか？
9
データベースで削除をどのように処理する必要がありますか？
ユーザーが気を変えて、削除されたレコードを回復できるように、Webアプリケーションに「削除解除」機能を実装したいと思います。これを実装する方法についての考えは？私が検討したいくつかのオプションは、実際に問題のレコードを削除し、別の監査テーブルに変更を保存するか、レコードを削除せず、ブールの「deleted」列を使用して削除済みとしてマークすることです。後者のソリューションでは、通常の状況で「削除された」レコードを無視するために追加のアプリケーションロジックが必要になりますが、アプリケーション側でレコードの回復を実装するのがはるかに簡単になります。
5
ネストされたビューは優れたデータベース設計ですか？
私はずっと前にどこかで読んだことがあります。この本は、SQL Serverでネストされたビューを持つことを許可すべきではないと述べています。私たちがそれができない理由がわからないか、間違った記述を覚えているかもしれません。 学生 SELECT studentID, first_name, last_name, SchoolID, ... FROM students CREATE VIEW vw_eligible_student AS SELECT * FROM students WHERE enroll_this_year = 1 先生方 SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers CREATE VIEW vw_eligible_teacher AS SELECT * FROM teachers WHERE HasCert = 1 AND enroll_this_year = 1 学校 CREATE …
5
ソートされたリストを保存するためのデータベースを設計する方法は？
データベース内にソートされたリストを保存したいと思っています。次の操作を効率的に実行したい。 Insert（x）-レコードxをテーブルに挿入します Delete（x）-テーブルからレコードxを削除します Before（x、n）-ソートされたリストでレコードxの前にある 'n'レコードを返します。 After（x、n）-ソートされたリストのレコードxに続く 'n'レコードを返します。 First（n）-ソートされたリストから最初の 'n'レコードを返します。 Last（n）-ソートされたリストから最後の 'n'レコードを返します。 Compare（x、y）-テーブルの2つのレコードxとyが与えられ、x> yかどうかを見つけます。 私が考えることができる簡単な方法は、ある種の「ランク」属性をテーブルに保存し、その属性でソートすることでクエリすることです。ただし、この方法では、ランク付きのレコードの挿入/変更はコストのかかる操作になります。より良い方法はありますか？ 具体的には、AmazonのSimpleDBを使用してテーブルを実装することを検討しています。ただし、リレーショナルデータベースの一般的な回答も役立つはずです。 負荷プロファイルの更新： これはWebアプリケーション用に計画しているので、アプリを使用するユーザーの数に依存します。 10万人のアクティブユーザーがいる場合（スーパーオプティミズム：P）、1日あたりの私のおおよその見積もりは 50万の選択、10万の挿入と削除、50万の更新 テーブルは合計で500kまで成長すると予想されます。 更新、挿入、および比較の操作を最適化しようとしています。アイテムのランクは常に変化するため、テーブルを更新し続ける必要があります。
5
既存の違反を無視する一意の制約を追加できますか？
現在、列に重複した値があるテーブルがあります。 これらの誤った重複を削除することはできませんが、一意でない値が追加されないようにしたいと思います。 UNIQUE既存のコンプライアンスをチェックしないを作成できますか？ 使用してみましNOCHECKたが、失敗しました。 この場合、ライセンス情報を「CompanyName」に関連付けるテーブルがあります 編集：同じ「CompanyName」を持つ複数の行を持つことは悪いデータですが、現時点ではそれらの重複を削除または更新することはできません。1つのアプローチはINSERT、重複に対して失敗するストアドプロシージャをsに使用させることです... SQLが独自に一意性をチェックすることが可能であれば、それが望ましいでしょう。 このデータは会社名で照会されます。少数の既存の重複について、これは複数の行が返されて表示されることを意味します...これは間違っていますが、ユースケースでは許容できます。目標は、将来それを防ぐことです。コメントから、ストアドプロシージャでこのロジックを実行する必要があるようです。
2
ユーザー、ロール、権利を持つデータベースモデル
ユーザーテーブルとロールテーブルを持つデータベースモデルがあります。最大10の異なる要素へのアクセス（権利）を制御したい。アクセスは、ロールまたは単一のユーザーに付与できます。以下は、ユーザー、ロール、およびアイテムのテーブル定義です。 CREATE TABLE users ( id serial NOT NULL PRIMARY KEY, username character varying UNIQUE, password character varying, first_name character varying, last_name character varying, ... ); CREATE TABLE roles ( id serial NOT NULL PRIMARY KEY, name character varying NOT NULL, description character varying, ... ); CREATE TABLE element_1 ( …
3
データベース設計：新しいテーブルと新しい列
（これはStackOverflowからここに再投稿することが提案されました） 現在、テーブルがあり、新しいデータ列の追加を開始する必要があります。すべてのレコードに（新しいデータ列を追加した後に新しいデータを使用する場合でも）データがあるわけではありません。だから、これは実際にはいくつかのデータ行の拡張であり、すべての行に適用できないため、これが新しいテーブルに適しているのだろうかと思っています。 言い換えると、これらの新しいデータ要素には多くの未使用の列があるため、新しいテーブルにより適しているようです。 最初の表はページビューの記録です（現在200万件の記録） -id - IPアドレス -視聴回数 -created_atタイムスタンプ -日付 すべてのIPアドレスについて、1日ごとに記録が作成され、1日あたりの時間ビューに連続したページビューが追加されます 追加のフィールドは、起点の追跡用です（つまり、google analytics source / medium / campaign） すべての訪問がその情報を持っているわけではありません。Imは、行の約10％にデータがあると想定します（通常は最初の訪問時にのみ属性付けされるため） データの主な用途は、人々の出身地を特定することです。これは、より頻繁に使用される可能性があります（それは、単一のテーブルに役立つようです） フィードバックに感謝-必要に応じてさらに追加できます
4
データベース内のすべての列名をリストまたは検索するにはどうすればよいですか？
データベースにある列の名前の文字列を検索したい。 私はメンテナンスプロジェクトに取り組んでおり、扱っているデータベースの一部には150を超えるテーブルがあるため、これをすばやく行う方法を探しています。 おすすめは何ですか？
5
なぜvarcharデータ型がまだあるのですか？
私のデータベースの多くには、varcharとして定義されたフィールドがあります。私はアメリカに住んで働いているので、これはそれほど問題ではありませんでした（存在する唯一の言語は「アメリカ人」です。ahem） 約5年間データベースを操作した後、最終的にvarcharフィールドの性質が限られているという問題に遭遇し、nvarcharとしてデータを保存するためにフィールドを変更する必要があります。テーブルに別の更新を行い、varcharフィールドをnvarcharに変換しなければならなかった後、私は考えました-なぜこのようにまだ行うのですか？私はずっと前から、新しいテキストフィールドをすべてvarcharではなくnvarcharに定義するという精神的な決定をしました。これは、10年前に学校にいたときに教科書から学んだことです。 2011年で、昨年SQL Serverの新しいリリースがありました。代わりにnvarcharを使用できる/すべきであるのに、なぜvarcharデータ型をサポートし続けるのですか？ nvarcharsはvarcharsの「2倍」であるとよく言われることを知っているので、varcarを保持するための1つの論点として、ストレージスペースの使用が考えられます。 ただし、今日のユーザーは、ストレージスペースを節約したい場合、デフォルトのUTF-16ではなくUTF-8としてデータを保存するようにnvarcharを定義できます。これにより、主に望ましい場合は8ビットエンコーディングが可能になりますが、DBに挿入される2〜8バイトのまれな文字が何も破損しないことが保証されます。 何か不足していますか？過去15〜20年でこれが変わっていない理由はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.