問題タブ [database-design]

ユーザーが入力した変更を特定のテーブルに保存する必要がありますが、管理ユーザーによって表示および承認されるまで、それらの変更は表示されません。これらの変更がまだ保留状態にある間、古いバージョンのデータを表示します。承認待ちのこれらの変更を保存する最良の方法は何でしょうか?

いくつかの方法を考えましたが、どの方法が最適かわかりません。これは非常に小さな Web アプリです。1 つの方法は、他のテーブルのスキーマを模倣する PendingChanges テーブルを用意し、変更が承認されたら、実際のテーブルを情報で更新することです。もう 1 つのアプローチは、テーブルにデータの複数のバージョンを保存し、承認済みとマークされた最も高いバージョン番号を持つレコードを常にプルする、ある種のレコード バージョン管理を行うことです。これにより、余分なテーブルの数が制限されます (複数のテーブルに対してこれを行う必要があります) が、適切なレコードを確実に取得するために、一連のレコードを引き出すたびに追加の処理を行う必要があります。

これらの方法やその他の良い方法に関する個人的な経験はありますか?

更新: 明確にするために、この特定の状況では、過去のデータにはあまり興味がありません。ユーザーが行った変更をサイトに公開する前に承認する何らかの方法が必要なだけです。そのため、ユーザーは自分の「プロファイル」を編集し、管理者はその変更を確認して承認します。承認されると、それが表示される値になり、古いバージョンを保持する必要はありません。

特別な PendingChanges テーブルで XML として追跡する必要があるテーブルからの保留中の変更を格納する以下のソリューションを試した人はいますか? 各レコードには、変更が行われたテーブルを示す列、変更されるレコードの ID (新しいレコードの場合は null) を格納する列、変更が行われたときに格納する日時列、および変更されたレコードの xml を格納する列 (おそらくデータ オブジェクトをシリアル化できます)。履歴は必要ないので、変更が承認された後、実際のテーブルが更新され、PendingChange レコードが削除される可能性があります。

その方法について何か考えはありますか？

私はかなり大きなアプリケーションとデータベースを維持していますが、いくつかのストアド プロシージャでデータベースのパフォーマンスが低下していることに気付きました。

パフォーマンスを向上させるために「インデックスを追加する」ことができるといつも聞いています。私は確かに DBA ではありません。インデックスとは何か、インデックスが役立つ理由、インデックスの作成方法も理解していません。

基本的にインデックス101が必要です。

学習できるようにリソースを提供してくれる人はいますか?

インデックスについて学習しようとしている「インデックスとは何ですか? また、それらを使用してデータベース内のクエリを最適化するにはどうすればよいですか? 」のフォローアップとして、インデックスの候補として適しているのはどの列ですか? 具体的には、MS SQL データベースの場合?

いくつかのグーグルの後、私が読んだことはすべて、一般的に増加し、一意である列が適切なインデックスを作成することを示唆しています（MySQLのauto_incrementなど）。これは理解していますが、MS SQLを使用しており、主キーにGUIDを使用しているため、そのインデックスは GUID 列に利益をもたらしません...

常にクエリと書き込みが行われる、7 つの列を持つインデックス付きの MySQL テーブルを考えてみましょう。データを他のテーブルに分割してパフォーマンスを向上させる前に、このテーブルに含めることを許可する推奨行数は?

私は自分のウェブサイトをデザインしていて、興味がありました。他の人のアイデアをリッピングする前に、データベースをデザインする際に考慮すべき重要な考慮事項と質問は何でしたか？

さて、今「ボックスアイテム」の表を作っています。

現在、ボックスアイテムは、使用目的/アイテムのステータスに応じて、「配送」ボックスまたは「返品」ボックスに関連付けられる場合があります。

ボックス アイテムに欠陥がある可能性があります。欠陥がある場合、ボックス アイテムの行にフラグが設定され (IsDefective)、ボックス アイテムは「返品」ボックスに入れられます (他のアイテムはそのベンダーに返品されます)。それ以外の場合、ボックス アイテムは最終的に「配送」ボックスに入れられます (他のアイテムが配送されます)。(配送ボックスと返品ボックスには独自のテーブルがあることに注意してください。すべてのボックスに共通のテーブルが 1 つあるわけではありませんが、可能であれば 3 つ目の可能性としてそれを検討する必要がありますか?)

今日ははっきりと考えていないだけかもしれませんが、この状況で何をすべきか疑問に思い始めました。

私の直感では、一度に 1 つのリレーションしか発生しない場合でも、考えられるリレーションごとに個別のフィールドが必要であることがわかります。これにより、ボックス アイテムのスキーマは次のようになります。

BoxItemID 説明 IsDefective ShippingBoxID ReturnBoxID など...

これによりリレーションが明確になりますが、無駄に思えます (リレーションは常に 1 つしか使用されないため)。そこで、BoxID 用のフィールドを 1 つだけ用意し、IsDefective フィールドに基づいて、それが参照している BoxID (配送または返品ボックス ID) を判断できると考えました。

BoxItemID 説明 IsDefective BoxID など...

これは無駄が少ないようですが、私には合いません。関係は明らかではありません。

それで、Stackoverflow のデータベースの達人であるあなたにそれを言います。この状況であなたはどうしますか？

編集: ご意見をお寄せいただきありがとうございます。いろいろ考えさせられました。1 つには、次にこのようなプロジェクトを開始するときに ORM を使用するつもりです。=) 2 つについては、私は今いないので、4 バイトをかじって 2 つのフィールドを使用します。

みんなありがとう！

私は、より大きなシステムの基盤として使用されるグループ階層のデータベース設計に取り組んでいます。各グループには、他のグループと、リーフ オブジェクトとして「デバイス」を含めることができます (デバイスの下には何もありません)。

使用されているデータベースは MS SQL 2005 です。

グループにはさまざまな種類があり、これらは動的であり、ユーザーが実行時に定義できる必要があります。たとえば、グループ タイプは「顧客」、「アカウント」、「都市」、または「建物」、「フロア」であり、各タイプには、ユーザーが定義できる異なる属性セットがあります。ビジネス ルールも適用されます。たとえば、「フロア」は「ビルディング」グループの下にのみ含めることができ、これらは実行時に定義できます。

アプリケーション機能の多くは、これらのグループに基づいてレポートを実行することで得られるため、特定のグループ (およびすべてのサブグループ) に含まれるすべてのデバイスのリストを比較的高速に取得する方法が必要です。

変更された事前注文ツリー トラバーサル手法を使用してグループを格納することには、高速であるという利点がありますが、かなり複雑で壊れやすいという欠点があります。外部ユーザー/アプリケーションがデータベースを変更すると、完全に破損する可能性があります。また、ORM レイヤーも実装していますが、この方法では、ほとんどの ORM ライブラリでリレーションを使用するのが複雑になるようです。

共通のテーブル式と「標準の」id/parentid グループの関係を使用することは、複数の再帰クエリの実行を回避するための強力な方法のようです。この方法に欠点はありますか？

属性に関する限り、それらを保存する最良の方法は何ですか? グループに関連する細長いテーブル? 「名前」などの一般的な属性は、属性テーブルではなく、グループ テーブルに格納する必要がありますか (多くの場合、表示に必要なのは名前だけです)。

この方法を使用すると、パフォーマンスの問題が発生しますか (クアッドコア Xeon 2 Ghz、4GB RAM などの適切なハードウェア上で、それぞれ平均 6 つの属性を持つ平均 2000 のグループと、平均 10 人の同時ユーザーを想定します)。 、他のプロセスを割り引いて)？

ここで概説したものとはまったく異なるスキーマを自由に提案してください。気になる問題点をまとめてみました。

データベースを作成するときに手作業でテーブルをコーディングするのは非常にうれしいですが、データベースに関する情報を他の人に伝えるのは最も簡単な方法ではありません。特に、スクリプトを使用してテーブルをコーディングするのが苦手で、代わりにphpMyAdminなどを使用する人はそうです。 。

したがって、データベースを設計できる無料のプログラム（私が使用するには、Macで動作する必要がありますが、同じQを持つ他の人にPCアプリを提案してください）またはスクリプト（できればPHPまたはPython）はありますか？構造を作成し、ユーザーが選択した基本的な図またはコードを出力しますか？

フィールド、テーブル、ビューなどのストアド プロシージャ名で問題が発生することがあります。例：

問題は、fromが SQL-92 の予約語であることです。フィールド名を二重引用符で囲んでこれを修正することもできますが、他のデータベース ツールがデータベースを読み込もうとしている場合はどうでしょうか。それはあなたのデータベース設計であり、他のアプリケーションがあなたのデータベースに問題を抱えている場合、それはあなたの責任です.

他にも多くの予約語(~300) があり、それらはすべて避ける必要があります。DBMS をメーカー A から B に変更すると、一部のフィールド名が予約語になっているため、アプリケーションが失敗する可能性があります。PERCENTというフィールドは oracle データベースでは機能する場合がありますが、MS SQL Server では予約語として扱われる必要があります。

これらの予約語に対してデータベースの設計をチェックするツールがあります。あなたも？

これが私のルールです

1. 32 文字を超える名前は使用しないでください (一部の DBMS はこれより長い名前を処理できません)。
2. az、AZ、0-9、およびアンダースコアのみを使用します (:-;,/&!=?+- は使用できません)
3. 名前を数字で始めないでください
4. これらの予約語を避ける

タスクを処理するための複雑なワークフロー状態をデータベースに格納する方法に関するベスト プラクティスについて質問があります。私はオンラインで探しても無駄だったので、コミュニティに彼らが何が最善だと思うか尋ねてみようと思いました.

この質問は、前の質問で示したのと同じ「BoxItem」の例から出てきます。この「BoxItem」は、さまざまなタスクが実行されているため、システムで追跡されています。タスクは数日にわたって人的介入を伴う場合があるため、BoxItem の状態を永続化する必要があります。誰がタスクを実行したか (該当する場合)、いつタスクを実行したかも追跡する必要があります。

最初に、実行する必要がある人間と対話するタスクごとに「BoxItems」テーブルに 3 つのフィールドを追加することで、これに取り組みました。

TaskName は完了していますか

日付TaskName完了

ユーザーTaskName完了

これは、ワークフローが単純だったときに機能しました...しかし、現在では複雑なプロセスに成長しています (フロー内で可能な人間の相互作用は 10 を超えています...その約半分はオプションであり、BoxItem に対して実行される場合と実行されない場合があります。その結果、これらのオプションのタスクにも「Do TaskName」フィールドを追加し始めました)、単純なテーブルであるべきだったものが、この状態情報の保持に完全に専念する40ほどのフィールドになっていることがわかりました.

もっといい方法はないかと悩んでいますが…困っています。

最初に考えたのは、特定のボックスで実行できるタスクを定義する一般的な「BoxItemTasks」テーブルを作成することでしたが、それでも日付とユーザーの情報を個別に保存する必要があるため、あまり役に立ちませんでした。

私の 2 番目の考えは、おそらくそれは問題ではないということでした。このテーブルに状態保持専用のフィールドが 40 以上あっても心配する必要はありません。しかし、それは保持する情報が多いように感じます。

とにかく、3番目のオプションが何であるか、または上記の2つのオプションのいずれかが実際に合理的であるかどうかについて、私は途方に暮れています. このワークフローは将来さらに複雑になる可能性があり、新しいタスクごとに、追跡をサポートするためだけに 3 ～ 4 つのフィールドを追加する必要があります。

この状況であなたはどうしますか？

これは、ORM を使用せずに構築された既存のシステムの保守であるため、ORM だけに任せることはできません。

編集：

Kev、あなたはこのようなことについて話しているのですか:

ボックスアイテム

(PK) BoxItemID

(その他関係ないもの)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

完成されました

完了日

ユーザー完了

BoxItemTasks

(PK) タスクタイプ

説明（必要であれば）

うーん...それはうまくいくでしょう...それは、どのアイテムがどの状態にあるかを確認するためにSQLクエリを実行する現在のアプローチを変更する必要があることを表していますが、長期的には、このようなものがよりうまく機能するように見えます(シリアライゼーションのアイデアが表すような根本的な設計変更を行うこと...時間があれば、そのようにしたいと思います.)

これはあなたがKinについて言及していたことですか、それとも私はそれを理解していませんか?

編集：ああ、現在の状態を判断するための「最後のアクション」についてもあなたのアイデアが見えます...私はそれが好きです! それは私にとってはうまくいくと思います...少し変更する必要があるかもしれません(ある時点でタスクが同時に発生するため)が、アイデアは良いもののようです!

EDIT FINAL：要約すると、将来、誰かが同じ質問でこれを調べている場合...システムに情報がクエリ可能なインターフェースに事前にロードされている場合（つまり、私が取り組んでいるアドホック システムのように、データベース自体を直接呼び出すわけではありません)。ご回答ありがとうございます。