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

Delphi UIアプリケーションのバックエンドとなるMS SQL Serverデータベースのユーザー認証モジュールをモデル化しようとしています。基本的に、ユーザーが1つのグループにのみ所属するユーザーアカウントが必要です。グループは、「n」個の権利を持つことができます。 また、ユーザーがアプリケーション設定（たとえば、90日ごと）に基づいてパスワードを変更する必要があるため、パスワード履歴をデータベースに追加します。 また、ユーザーがログインおよびログアウトするたびにイベントを記録したいと思います。私はこれを将来の追加イベントに拡張するかもしれません。 以下に、私の最初のクラックを見つけます。これを行うのはこれが初めてなので、改善するための提案があれば教えてください。 役割ベースのセキュリティの追加属性とパスワードルール/有効期限の制約が必要ですか？

15 database-design  datatypes  relational-theory  database-tuning 

MySQLで（Webアプリの）DB接続を開いたり閉じたりするCPU集中型の方法 ... DBソフトウェアがlocalhostにある場合 ... DBソフトウェアが別のマシンにある場合

15 mysql  database-design  mysql-5.5 

私は研究のために政府機関の情報システムに概念スキーマを要求していました。セキュリティリスクであるという理由で、私の要求は拒否されました。 私は実際に広範なデータベースの経験がないので、その主張を確認することはできません。スキーマを公開することは、本当に大きなセキュリティリスクですか？つまり、これらはかなり抽象的であり、ハードウェアおよびソフトウェアの実装とは離婚しています。攻撃者が概念スキーマをどのように悪用できるかについての説明をいただければ幸いです。ありがとう。

15 database-design  security 

長いhtmlページが1つあり、いくつかの質問セットが小さなセクション（1ページに約15のサブセクション）に分かれています。質問の合計は約100の質問です。入力、複数選択、チェックボックス、ラジオボタン、テキストエリア、およびファイルのアップロード。1つの質問には、チェックボックスのグループ、選択リストのグループ、複数選択のグループ、またはそれらすべてを1つの回答にまとめたもののいずれかから取得した多くの回答を含めることができます。私はこのデータベース設計を以下で使用するつもりだったが、結局のところそれは良いアプローチではないことがわかった。 1人の顧客は、1組の質問（100の質問につき1人の顧客）しか持てません。 古いアプローチでは、データベースに疑問を抱かず、代わりにPHPコーディングで定数として割り当てます。問題は、PHPの質問をデータベースの回答と同期させるために比較する必要があることです。1つの質問がPHPから変更/削除/移動された場合、質問データベースの回答と一致させるために間違いなく迷子になります。より良い解決策？ フォームの複数の要素から取得した複数の回答を1つの回答として1つのフィールドに保持できますか？このフィールドを取得して、フォームで顧客が表示するために再度表示するにはどうすればよいですか？ 下のどのオプションに行くべきですか？ オプション1：古いアプローチ（1テーブル） 表：アンケート ID（PK） 顧客ID 状態 A1 A2 A3 。 。 。 A100 オプション2：新しいアプローチ（2つのテーブル） 表：質問 QID（PK） 質問（varchar） 表：回答 援助（PK） 顧客ID QID（int） 回答（varchar） またはオプション3？

15 database-design 

私は、小規模企業の顧客向けのWebベースのClojureアプリケーションとして、VBベースのオンプレミス（ローカルにインストールされた）アプリケーション（請求書+在庫）を書き換えることを検討しています。これは、同様の取引の顧客向けのSaaSアプリケーションとして提供される予定です。 私はデータベースオプションを見ていました：私の選択はRDBMS：Postgresql / MySQLでした。最初の1年間で最大400人のユーザーにスケールする可能性があります。通常、ユーザーあたり1日あたり20〜40ページビューです。ほとんどの場合、静的ビューではないトランザクションに使用します。各ビューには、データの取得とデータの更新が含まれます。ACIDコンプライアンスが必要です（またはそう思う）。そのため、トランザクション量は膨大ではありません。 私の好みに基づいてこれらのいずれかを選択するのは簡単でしたが、この1つの要件のために、SaaSアプリの典型であると信じています：スキーマは、顧客/ユーザーを追加し、各顧客のビジネス要件の変更（最初に限って柔軟性を制限します）。私はDBの専門家ではないので、私が考えることができ、読んだことに基づいて、多くの方法でそれを処理できます。 複数のテナントをホストする単一のDBを使用して、MySQl / Postgresqlで従来のRDBMSスキーマを設計します。さらに、顧客を追加したり、既存の顧客に変更を加えたりするときに、将来の変更に対応できるように、各テーブルに十分な「浮動」列を追加します。これには、スキーマに小さな変更が加えられるたびにDBに変更が伝播されるという欠点があります。Postgresqlのスキーマ更新では、ロックなしでリアルタイムに更新できることを読んだことを覚えています。しかし、このユースケースでどれだけ苦痛であるか、どれほど実用的かはわかりません。また、スキーマの変更により、新しい/小さなSQL変更も導入される可能性があるためです。 RDBMSを使用しますが、データベーススキーマを柔軟な方法で設計します。エンティティ属性値に近い値を使用するか、単にキー値ストアとして使用します。（就業日、たとえばFriendFeed） オブジェクト全体をメモリ内にオブジェクトとして保持し、定期的にログファイルに保存します（edval、lmaxなど）。 MongoDBやRedisなどのNoSQL DBを探してください。しかし、私が収集できるものに基づいて、これらはこのユースケースに適さず、ACIDに完全に準拠していません。 SQLおよびACID準拠の動作を保持し、「新世代」のRDBMSであるVoltDbやJustoneDb（クラウドベース）などのNewSQL Dbsを探します。 neo4j（graphdb）を見ましたが、それがこのユースケースに適合するかどうかはわかりません スケーラビリティや分散コンピューティング以上のユースケースでは、「スキーマ+ ACIDの柔軟性+合理的なパフォーマンス」を実現するためのより良い方法を探しています。ネット上のほとんどの記事では、ACID / Transactions側を除外しつつ、パフォーマンス（NoSQL DBの場合）とスケーラビリティにつながる原因としてのスキーマの柔軟性について述べています。 これは、「スキーマの柔軟性とACID」トランザクションの「どちらか」のケースですか、それともより良い方法がありますか？

15 database-design  schema  nosql 

以前の変更を追跡するために、プロジェクトに履歴機能を設定する必要があります。 今、2つのテーブルがあるとします。 NOTES TABLE (id, userid, submissionid, message) SUBMISSIONS TABLE (id, name, userid, filepath) 例：ノートに行があり、ユーザーがメッセージを変更したい。変更前と変更後の状態を追跡したい。 これらの各テーブルに列を設定する最善の方法は、アイテムが「古い」かどうかを示すことです。0アクティブであればOR削除/不可視の場合は1。 また、以前の状態、新しい状態、これらのIDが関連するAUDIT TRAILテーブルを保持する履歴（）テーブルを作成したいのですが。idid

15 mysql  database-design  audit 

pricesこれらの列を持つテーブルを考えてみましょう。 id integer primary key product_id integer -- foreign key start_date date not null end_date date not null quantity integer price numeric データベースには、日付範囲内の特定の数量で1つの価格しか持てないというルールを適用したいのですが（を介してwhere <date> BETWEEN start_date AND end_date）。 この種の範囲ベースの制約は実行可能ですか？

15 postgresql  database-design  postgresql-9.4  exclusion-constraint 

私はPostgresを使用してデータベースを構築していますが、ここではmonthand によってグループ化されますが、によってグループ化されることはありyearませんdate。 整数monthとyear列を作成して使用できます。 または、month_year列を作成し、常にday1に設定することもできます。 前者は誰かがデータを見ている場合は少し単純で明確に見えますが、後者は適切な型を使用する点で優れています。

15 postgresql  database-design  datetime 

ルックアップテーブル（またはコードテーブルと呼ばれることもあります）は、通常、特定の列に指定できる値のコレクションです。 たとえば、次のparty2つの列を持つ（政党に関する情報を保存するための）というルックアップテーブルがあるとします。 party_code_idn、システム生成の数値を保持し、（ビジネスドメインの意味を欠いて）実際のキーの代理として機能します。 party_codeは、ビジネスドメインの意味を持つ値を保持するため、テーブルの実際のキーまたは「自然な」キーです。 そして、そのようなテーブルは以下のデータを保持しているとしましょう： +----------------+------------+ | party_code_idn | party_code | +----------------+------------+ | 1 | Republican | | 2 | Democratic | +----------------+------------+ party_code値は「共和党」と「民主党」を続けるの列は、テーブルの実際のキーであること、UNIQUE制約に設定されているが、私は必要に応じて添加party_code_idnし、論理的に言えば、ものの（表のPKとしてそれを定義しました、party_codeプライマリキー[PK]として機能する場合があります）。 質問 トランザクションテーブルからルックアップ値を指すためのベストプラクティスは何ですか？FOREIGN KEY（FK）参照を確立する必要があります（a）自然で意味のある値を直接参照するか、（b）値を代理しますか？ オプション（a）、たとえば +---------------+------------+---------+ | candidate_idn | party_code | city | +---------------+------------+---------+ | 1 | Democratic | Alaska | | 2 | Republican | Memphis …

14 database-design  foreign-key  primary-key  best-practices 

現在、2つのエンティティ間に外部キーがあり、その関係をテーブルの1つのentityTypeを条件とするようにします。これがテーブルの階層です。これは、子から親へのFK参照を介して行われます Store / \ Employees \ TransactionalStores / | \ Kiosks | BrickMortars Onlines 現在、従業員から店舗へのFK関係があります ALTER TABLE Employees ADD CONSTRAINT Employee_Store FOREIGN KEY (TransStoreId) REFERENCES TransactionalStores(StoreId) 条件を追加したい： WHERE TransactionalStores.storeType != 'ONLINE_TYPE' これは可能ですか、またはTransactionalStoresを2つの新しいsubType（PhysicalStoresおよびVirtualStoresなど）にサブクラス化する必要がありますか

14 postgresql  database-design  foreign-key  constraint 

私はSEに通知システムを構築する方法を検討して、他の場所と私はここに受け入れ答えである液に描か発見されている：/programming/9735578/building-a-notification-system た用途この構造： ╔═════════════╗ ╔═══════════════════╗ ╔════════════════════╗ ║notification ║ ║notification_object║ ║notification_change ║ ╟─────────────╢ ╟───────────────────╢ ╟────────────────────╢ ║ID ║—1:n—→║ID ║—1:n—→║ID ║ ║userID ║ ║notificationID ║ ║notificationObjectID║ ╚═════════════╝ ║object ║ ║verb ║ ╚═══════════════════╝ ║actor ║ ╚════════════════════╝ 通知は、何か（オブジェクト=イベント、友情..）が誰か（俳優）によって変更（動詞=追加、要求）され、ユーザー（対象）に報告されることに関するものです。これが正規化されたデータ構造です（MongoDBを使用しましたが）。特定のユーザーに変更を通知する必要があります。つまり、ユーザーごとの通知です。つまり、100人のユーザーが関与している場合は、100の通知を生成します。 最初はこのアプローチを理解していると思っていましたが、それを実装する準備を始めたとき、私は明らかにそれを特によく理解していないことに気付きました。回答に関する最後のいくつかのコメントは、ソリューションの理解に苦労した他のユーザーからの質問です。 私がいないことを確認これは私が次のように終わるだろうモデルがある場合だけど、それが持っているupvotesの数を考えると、私はそれは私がする恩恵を受けるだろうと確信して理解し、それを、私は確かのようにもっと勉強したいです。これがこの解決策を把握するのに苦労した他の人にも役立つことを願っています（偶然、私はこの質問に向けてその答えにコメントを残すのに十分なインターネットポイントを持っていません、他の誰もしてください！） ご質問 正しく理解できれば、notificationObjectIDはnotification_objectテーブルを指す外部キーであり、notificationIDは通知テーブルを指す外部キーです。オブジェクトは、通知の対象となるデータベースエントリ（特定のイベントや投稿など）のIDを参照する外部キーであるように見えますが、そのIDが属するテーブルを示す別のフィールドが必要ではないでしょうか？ 著者が書いた notification_object.objectは、文字列「friendship」のような変更タイプを識別します。私が話す追加データを含む変更されたオブジェクトへの実際の参照は、notification_change.notificationObjectIDにあります。 私には意味がないようです。オブジェクトは文字列（enum？）で、notificationObjectIDは通知の対象となるオブジェクトを参照する外部キーですか？それでは、真ん中のテーブルと正しいテーブルはどうやってつながっているのでしょうか？ 中央のテーブルは、通知の対象となるオブジェクト（またはオブジェクトのタイプ）、たとえばイベントや投稿を指定しているようです。次に、同じオブジェクトタイプを指すnotification_changeのエントリを多数持つことができます。これにより、通知（「25人のユーザーがXの壁に投稿されました」など）をバンドルできます。 しかし、左テーブルと中央テーブルの間に1：nの関係があるのはなぜですか？「25人のユーザーがSamのウォールに投稿されました」と「Maryが彼女の「Friday Picnic」イベントを更新した同じ通知IDを提供しますか？同じユーザーのすべての通知に同じ通知IDがある場合、なぜ左？ パフォーマンスに関する質問-ジョンがメアリーのピクニックイベントにコメントを投稿するとします。notification_changeエントリを作成する前に、Mary's Picnicのnotification_objectが既に存在するかどうかを確認するためにルックアップを行う必要があるようです。これはパフォーマンスに悪影響を及ぼしますか、それとも問題ではありませんか？前の段落からの質問を続けると、どのように我々は知っているだろう通知指すようにエントリnotification_objectをしますか？

14 database-design 

この方法で作成されたテーブルがあります： -- -- Table: #__content -- CREATE TABLE "jos_content" ( "id" serial NOT NULL, "asset_id" bigint DEFAULT 0 NOT NULL, ... "xreference" varchar(50) DEFAULT '' NOT NULL, PRIMARY KEY ("id") ); その後、IDを指定していくつかの行が挿入されます。 INSERT INTO "jos_content" VALUES (1,36,'About',...) 後で、IDなしでいくつかのレコードが挿入され、エラーで失敗します： Error: duplicate key value violates unique constraint。 どうやらidはシーケンスとして定義されました： 挿入に失敗するたびに、存在しない値に増分し、クエリが成功するまで、シーケンス内のポインターが増加します。 SELECT nextval('jos_content_id_seq'::regclass) テーブル定義の何が問題になっていますか？これを修正するスマートな方法は何ですか？

14 postgresql  database-design  insert  auto-increment  sequence 

私は現在、比較的大量のデータ用のストレージスキーマの実装を担当しています。データは主に現在のdata point値を判断するためにアクセスされますが、データの傾向分析のために過去6か月の履歴を追跡する必要もあります。 最近の要件は、過去1時間のmin/ max/ sum値を追跡するために追加されました。 注：理想的には、MongoDBオプションを検討したいと思いますが、最初にSQL-Serverオプションを使い果たしたことを示す必要があります。 データ 次の表は、プライマリデータソース（最も頻繁にクエリされる）を表しています。テーブルには約500万行が含まれます。データの変更は主に、初期データのロード後のUPDATE非常に不定期のINSERTステートメントを伴うステートメントになります。dataPointIdあなたがいつも選択するので、私はデータをクラスタリングすることを選びましたall values for a given data point。 // Simplified Table CREATE TABLE [dbo].[DataPointValue]( [dataPointId] [int] NOT NULL, [valueId] [int] NOT NULL, [timestamp] [datetime] NOT NULL, [minimum] [decimal](18, 0) NOT NULL, [hourMinimum] [decimal](18, 0) NOT NULL, [current] [decimal](18, 0) NOT NULL, [currentTrend] [decimal](18, 0) …

14 sql-server  database-design 

私は、巨大なセンサーアレイからのデータサンプルを保存するソリューション（appおよびdb）を実装することを任されました。アレイは現在約20,000個のセンサーで構成されていますが、まもなく100,000個のセンサーに拡大します。各センサーは10秒ごとにデータサンプルを送信し、各サンプルのサイズは28バイトです。 したがって、合計を行うと、次のようになります。 1日あたりセンサーあたり8640サンプル 1日あたりセンサーあたり242kBのデータ 1日あたり864百万サンプル 今、データを保存/取得する最善の方法は何だろうと思っていますか？ソフトウェアが既に指定された後、私はこのプロジェクトに「参加」したので、SQL Serverを使用してWindowsプラットフォームに実装する必要があります。 私の頭の中の現在の解決策は、データサンプルを格納する2つのテーブルを持つDBを作成することです。1つ目は2つ目のインデックスの一種として機能し、センサーごとに1日あたりのバイナリフィールドに照合サンプルを格納します。 Table 1: RecordID - BigInt - Identity SensorID - BigInt - Primary Key Date - DateTime - Primary Key (yyyy-mm-dd) Table 2: RecordID - BigInt - Primary Key (from an insert into Table 1) Data - Binary 基本的に、すべてのセンサーのサンプルを一時ファイル（センサーごとに1つ）に書き込みます。毎日の終わりに、表1のエントリを作成し、生成されたRecordIDを使用して、ファイルを表2のデータフィールドにダンプします。 この方法では、8億4400万エントリではなく、1日あたり100,000エントリしかテーブルに登録されません。データはLANまたは高速WANで利用可能である必要があります。そのため、1日単位でセンサーデータを取得できます。 すべてのデータを保存する必要がありますが、ほとんどのデータはおそらく読み込まれません。そのため、テーブルの読み取りの量は書き込みよりも大きくなることはありません。 データファイルへのパスを保存するだけで、ファイルシステムを使用して何かを実装できることは知っていますが、バイナリフィールドが256kB未満の場合、SQL ServerはNTFSよりも優れていることを読みました。（256 …

14 sql-server  database-design 

私は既存のプロジェクトで作業を開始し、前の開発者は、テーブルを、スキーマは同じでもデータが異なる10個の個別のテーブルに分割していました。 テーブルは次のようになります。 [tableName_0] [tableName_1] [tableName_2] [tableName_3] [tableName_4] [tableName_5] [tableName_6] [tableName_7] [tableName_8] [tableName_9] 主キーは整数idフィールドです。アプリケーションは、ハッシュアルゴリズム（idmod 10）を使用して、ルックアップ時にアクセスするテーブルを認識します。たとえばid= 10に生じるであろう[tableName_0]。 合計すると、テーブルにはおそらく100,000行あり、成長率は比較的低くなります。 だから、私の質問は、これが実行可能な解決策であるかどうか、それがどんな状況でも良い方法であるかどうかです。私の理論は、それらを組み合わせるようにプッシュすることですUNION。主な欠点は、すべてのアプリケーションコードを変更することと、長期的に見ても価値があるかどうかです。

14 mysql  database-design  best-practices