3

正規化されたデータベースをトラバースできる堅牢なphp関数を作成しようとしています。私のmySQLデータベースには次の列名を持つ6つのテーブルがあり(主キーと外部キー、および簡単にするためにいくつかの限定されたテーブル列のみが含まれています)、それらがどのように関連しているかを確認できます。

tableA:
partID(主キー)

tableABJunction
itemID(外部キー)
partID(外部キー)

tableB
itemID(主キー)itemName

sales
customerID(外部キー)
itemID(外部キー)

partDate
itemID(外部キー)

customer
customerID(主キー)nameFirst nameLast

次のようなクエリを生成する必要がある場合:itemID = 12を注文した顧客の名前は何ですか?最初に、itemID = 12であるすべてのcustomerIDについて販売データベースからクエリを実行し、次にcustomerテーブルにクエリを実行して名前と名前を見つける必要があります。場合によっては、John Smithという名前の顧客に関連するすべての情報を要求するクエリに基づいて、6つのテーブルすべてからデータを返さなければならないクエリを実行する必要があります。考えられるすべてのタイプの検索に対してクエリを作成することなく、このさまざまなクエリを処理する関数を作成する簡単な方法はありますか?

現在、私のアプローチは、AJAXを介して以下をphpに渡すことです。web_conditionArray(提供されたデータの列名と値が含まれています。nameFirst=>'John'、nameLast =>'Smith'など)。web_resultArray(要求しているテーブル名と列が含まれています:sales =>'itemID、itemName')。

このアプローチで私が抱えている問題は、すべてのmySQLデータテーブルとその外部キーとの関係を保存する方法です。これにより、私のphpプログラムは、すべてのテーブルをリンクして、提供されたデータから取得する正しいクエリを実行する方法を認識します。あるテーブルから別のテーブルで要求されたデータへ。これを解決するための提案やより良い方法はありますか?最初は二重リンクリストを考えていましたが、tableBがsalesテーブルとpartDateテーブルにリンクするフォークがあるため、テーブルからテーブルへのフローは線形ではありません。

私は小説を書かずにこの状況を説明する際にできるだけ具体的にしようとしました。ただし、質問をさらに絞り込むために追加情報が必要な場合はお知らせください。

4

2 に答える 2

1

まず、私の答えは地獄に反対票を投じられる可能性が高いことを知ってください(この方法論はその正しさにもかかわらず常に反対票を投じられているため)。DBAは、複雑なクエリをSQLステートメントで実行できるという理由だけで、(サーバーサイドがすべてのクライアントサイドをサーバーサイドで実行する必要があると考える方法や、クライアントサイドがレイアウトをで実行する必要があると考える方法など)信じてほしいと考えています。 CSSではなくクライアント側)。いいえ。複雑なクエリは、特定の非日常的な理由でオンデマンドのデータ取得を考え出す必要があるコマンドラインに座っている人々のためのものです。処理速度については、SELECTing、UPDATEing、およびDELETEingは常にPKサーバー側で実行する必要があります。

正当に大きなテーブルのセットがあるようです。

それが大きく、速度が主な関心事であると仮定すると(開発時間ではなく)、主キーのみを使用し、他のインデックスは使用しないでください。インデックスが多いほど、DBAが実際に比較するときに、データベースによってそれらのインデックスのインデックスを再作成する必要があります。サーバー側の方が高速です。

主キーには多少の手間がかかりますが、データ型と長さを超えて最も重要なことです。たとえば、、、などの非FKの独立したテーブルにtableAtableBcustomerおそらくai INTPKが必要です(一般に、コンピューターは整数で考えることを忘れないでください)が、複数のFKを持つテーブルには、おそらくaiINTがなく、代わりに複合PKが必要です。バリアントの少ないSELECTFKを最初に使用します。たとえば、私のサイトでは、投票総数をuserIDとlinkIDごとにリンクに保存しています。ユーザーがログインしている場合、ユーザーはリンクに何票を投じたかを知る必要があります。そのため、userIDは変更される可能性が低く、そのテーブルの私のPKで最初になります。これをオンデマンドのデータベース側またはサーバー側で数えることは、パフォーマンスの悪夢でした。

ほんの数行のコードで、速度が大幅に向上します。PHPを介してPKで並べ替えると、レイテンシが50%削減されます。sをphpに吸収JOINすると、レイテンシスパイクの発生率が低下します。オンデマンドのMySQL計算がないため、サイトが麻痺するのを防ぐことができます。

SQLステートメントがサーバー側言語の代わりにSQLステートメントを使用する必要があるという結果を得ることができるという教義から離れると(C ++が最速です)、パフォーマンスが急上昇します。

難読化しようとしているテーブルをより具体的にすることができれば、私はより具体的にすることができますが、おそらくあなたはその考えを理解するでしょう。

AJAXはゲームを変更し、リフォーカスを強制しました。レイアウト用のCSS; クライアント側プログラミング用のjs。サーバー側の処理...サーバー側の処理。一瞬より長く続くすべてを保存するためのデータベース。

反対票を持ってきてください!笑

于 2013-01-12T06:20:00.433 に答える
1

テーブルの構造を見ると、テーブル間の関係を計算するロジックを構築し、クエリを動的に構築することは可能だと思いますが、特定のデータベースのクエリを手動で構築するよりもはるかに手間がかかるようです。テーブルにはさらに多くのフィールドが含まれていると思いますが、最も重要なものだけが含まれており、すべての主キーと外部キーが確実に含まれていると思います。

これに基づいて、データベースには、パーツ、アイテム、顧客の3つの情報オブジェクトしかありません。したがって、システムを機能させるために、手動で作成された12を超えるクエリは必要ありません。クエリを単純化して情報オブジェクト全体を処理し、後でPHPレイヤーを使用してそれらをフィルタリングする必要があります。

したがって、クエリロジックを次のように減らします。

"Fetch me all [Parts, Items or Customers] (and possibly also all [Parts, Items or Customers]) related to [Part, Item or Custromer] (and possibly [Part, Item or Customer])"

これにより、次のクエリが発生します。

  • 部品のすべての顧客
  • アイテムのすべての顧客
  • パーツとアイテムのすべての顧客
  • パーツのすべてのアイテム
  • 顧客のためのすべてのアイテム
  • 部品と顧客のすべてのアイテム
  • アイテムのすべてのパーツ
  • 顧客のためのすべての部品
  • 顧客とアイテムのすべての部品
  • アイテムのすべての部品と顧客
  • パーツのすべての顧客とアイテム
  • 顧客のためのすべてのアイテムと部品

(これは論理的な関係の完全なリストです-いくつかは実際には意味をなさないかもしれません、それはあなたの人生を楽にします)

したがって、PHPスクリプトは次のタスクを実行する必要があります。

  • クエリの基準に必要なオブジェクトを特定します。これは、提供されたフィールドに基づいています。
  • WHERE渡されたフィールドから基準オブジェクトの主キーを識別するクエリの句を作成します。
  • 要求されたフィールドに基づいて、クエリの結果に必要なオブジェクトを特定します。
  • 条件に基づいてクエリを選択し、オブジェクトを返し、構築されたWHERE句を挿入します。
  • クエリを実行し、要求されたオブジェクトに関して利用可能なすべての情報を抽出します
  • 結果をフィルタリングし、必要な情報のみを抽出します
  • 最終結果を返します。
于 2013-01-12T07:15:53.420 に答える