1

サードパーティの PDF アカウント フォームにクライアント データを事前入力するための PHP アプリを構築していますが、データベースの設計に行き詰まっています。

現在のフォームには約 70 のフィールドがあり、個々の列として設定するには多すぎるように思われます。特に、クライアントが必要とするアカウントの種類によっては関係のないもの (会社/信頼情報など) があるためです。

正規化しようとしましたが、結合が多くなり、複数のアドレスなどのためにいくつかのサブクエリが必要になるようです。

また、スクリプトが INSERT、DELETE、または UPDATE を実行する必要があるかどうかを判断するために、更新時に行が存在するかどうかを確認するための追加のクエリが大量にあることを意味します。毎回。

これが役立つかどうかはわかりませんが、ほとんどのフィールドのリストを次に示します。

id, account_type, account_phone, account_email, account_designation, account_adviser, account_source, account_complete, account_residential_unit_number, account_residential_street_number, account_residential_street_name, account_residential_street_type, account_residential_suburb, account_residential_state, account_residential_postcode, account_postal_unit_number, account_postal_street_number, account_postal_street_name, account_postal_street_type, account_postal_suburb, account_postal_state, account_postal_postcode, individual_1_title, individual_1_firstname, individual_1_middlename,個人_1_姓、個人_1_生年月日、個人_1_職業、個人_1_電子メール、個人_1_電話、個人_1_ユニット番号、個人_1_通り_番号、個人_1_通り_名前、個人_1_通り_タイプ、個人_1_郊外、個人_1_州、individual_1_postcode, individual_2_title, individual_2_firstname, individual_2_middlename, individual_2_lastname, individual_2_dob, individual_2_occupation, individual_2_email, individual_2_phone, individual_2_unit_number, individual_2_street_number, individual_2_street_name, individual_2_street_type, individual_2_suburb, individual_2_state, individual_2_postcode, company_name, company_date, company_unit_number, company_street_number, company_street_name, company_street_type, company_suburb, company_state, company_postcode, trust_name、trust_date、決済銀行、決済アカウント、決済_bsbindividual_2_street_number、individual_2_street_name、individual_2_street_type、individual_2_suburb、individual_2_state、individual_2_postcode、company_name、company_date、company_unit_number、company_street_number、company_street_name、company_street_type、company_suburb、company_state、company_postcode、trust_name、trust_date、決済銀行、決済アカウント、決済_bsbindividual_2_street_number、individual_2_street_name、individual_2_street_type、individual_2_suburb、individual_2_state、individual_2_postcode、company_name、company_date、company_unit_number、company_street_number、company_street_name、company_street_type、company_suburb、company_state、company_postcode、trust_name、trust_date、決済銀行、決済アカウント、決済_bsb

これが処理する必要がある最大のアプリケーションは約 200,000 です。データがデータベースに格納されると、データが変更されたとしてもそれほど頻繁には変更されません。関連性があるかどうかわかりませんか?

したがって、これを設計するための最もスマートな方法を見つけたかっただけです。たとえそれが単なる名前またはトピックであっても、さらに調査する必要があります.

4

5 に答える 5

2

一般に、データベースは 2 つの大きなカテゴリに分けることができます。

  1. OLTP システム

    オンライン トランザクション処理システムは、通常、データの読み取りに比べて多くの更新を行うなど、書き込みを集中的に行います。このシステムは通常、データ キャプチャや管理など、あらゆる範囲のビジネス ユーザーが使用する日常的なアプリケーションです。これらのデータベースは通常、極端に正規化され、特定の領域でパフォーマンスを向上させるために意気消沈します。

  2. OLAP/DSS システム:

    オンライン分析処理は、通常はシステムのような大規模なデータ ウェアハウスであるデータベースです。データ マイニング、データ キューブなどの分析アクティビティをサポートするために使用されます。通常、情報は OLTP よりも限定された一連のユーザーによって使用されます。これらのデータベースは通常、非常に非正規化されています。

これらの簡単な説明と主な違いについては、こちらをお読みください。 OLTP と OLAP

あなたのポイントについては、その問題を簡単に解決するINSERT/UPDATE/DELETEMySQLステートメントについて読んでください。これは、ほとんどのデータベース システムで操作ON DUPLICATE KEY UPDATEと呼ばれます。MERGE

なぜあなたがJOINSについて心配しているのか理解できません。数百万 (500 000 000+) 行のテーブルがあり、サイズが大きい他のテーブルと結合し、クエリは非常に高速に実行されました。したがって、結合を排除するようにデータベースを設計することはお勧めできません。

私の提案は次のとおりです。

OLTP システムを設計する場合は、可能な限り正規化してから、必要に応じて非正規化してパフォーマンスを向上させます。OLAP システムの場合は、スター スキーマなどを見て、最初に正規化する必要さえありません。ところで、ほとんどの OLAP システムは通常、OLTP システムをデータ ソースとして使用します。

于 2013-08-20T00:56:54.957 に答える
0

非正規化されたデータは、非常に基本的なレベルで作業するのが非常に苦痛です。ジョージアに住んでいる人の数を集計したい場合はどうすればよいでしょうか。非正規化された構造では、ind_1_state = GA または ind_2_state = GA の場所をカウントする必要があります。

これはそれほど悪くはないと思いますが、正規化が提供するクエリの容易さを見た人にとっては、非常に苦痛です.

より複雑なクエリの基盤を確立する正規化。これがないと、より豊富なデータ分析を実装することがますます難しくなります。

正規化は、データベースの整合性と一貫性の基礎も提供します。特定のもの (州の略語) がすべて 1 つの場所 (1 つの列) にある場合、それらの値を簡単に確認して制約し、存在しないコードを許可しないようにすることができます。

正規化の理論的根拠は延々と続きますが、いくつかの簡単な問題を解決できれば幸いです。

于 2013-08-20T01:42:24.160 に答える