Şu anda Kohana çerçeve üzerine inşa edilmiş, PHP ve MySQL kullanarak bir uygulama tasarlama ediyorum. Ben ORM yılında inşa edilmiş ve son derece yararlı olduğu kanıtlanmıştır yararlanarak ediyorum. Her şey gayet iyi çalışıyor, ama ben bazı sayfalarında yürütülüyor sorgu sayısı ile çok endişeliyim.

Setting
For example, there's a page on which you can view a category full of sections, which are in turn full of products. This is listed out in tabular format. Each product has (possibly) many attributes, flags, tier pricing breaks. This must all be represented in the table.

How many queries?
As far as queries are concerned: The category must query all the sections within it, and those sections must query all the products they contain. Not too bad, but each product must then query all it's product attributes, tier pricing, and flags. So, adding more products to a category increases the queries many times over (since I'm currently using the ORM primarily). Having a few hundred products in a section will result in a couple hundred queries. Small queries, but that is still not good.

So far...
All the keys are indexed. I can pull all of the information with a single query (see edit below), however, as you could imagine, this will result in a lot of redundant data spread out across multiple rows per each product, per each extra (e.g.) attribute, flag, etc.

Ben uygulamanın görüntüleme bölümü için ORM hendek açılması ve sorgu bina ya da çiğ SQL ile gidiş karşı değilim.

Bunun için çözüm aslında oldukça basit olabilir ve ben dürüst bir rahatlama olacağını, şu anda bunun sadece cahilim. Ya da belki de değil. Emin değilim. Benim açıklama herhangi bir sorunu anlamak için yeterli yeterli değilse, sadece sormak ve ben daha iyi bir örnek vermeye çalışacağım. (Edit: Better example given, see below

Although, a side note... One thing that may have some relevance though: while I always want to have the application designed most efficiently, this isn't a site that's going to be hit dozens or hundreds of times a day. It's more of an administrative application, which probably won't be in use by more than a few individuals at once. I can't foresee too much reloading, as most of the editing of data on the page is done through AJAX. So, should I care as much if on this page it's running a couple hundred queries (fluctuating with how many products are in the currently viewed section) are running each time this particular page is loaded? Just a side thought, even so if it is possible to solve the main aforementioned problem I would prefer that.

Thank you very much!

EDIT
Based on a couple answers, it seems I didn't explain myself adequately. So, let me post an example so you see what's going on. Before the example though, I should also make two clarifications: (1) there are also a couple many-to-many relationships, (2) and you could possibly liken what I'm looking for to that of a crosstab query.

Let's simplify and say we have 3 main tables: products (product_id, product_name, product_date_added) product_attributes (product_attribute_id, product_id, value) notifications (notification_id, notification_label)

And 1 pivot talbe: product_notifications (notification_id, product_id)

We're going to list all the products in a table. It's simple enough in the ORM to call all the products. So per each 'products' we list the product_name and product_date_added. However, we also need to list all the products attributes out. There are a 0 or more of these per product. We also have to show what notifications a product has, of which there are 0 or more as well. So at the moment, how it works is basically:

foreach ($products->find_all() as $product) //given that $products is an ORM object
{
   echo $product->product_id; //lets just pretend these are surrounded by html
   echo $product->product_name;
   foreach ($products->product_attributes->find_all() as $attribute)
   {
       echo $attribute->value;
   }
   foreach ($products->notifications->find_all() as $notification)
   {
       echo $notification->notification_label; 
   }
 }

This is oversimplified of course, but this is the principle I'm talking about. This works great already. However, as you can see, for each product it must query all of it's attributes to get the appropriate collection or rows. The find_all() function will return the query results of something along the lines of: SELECT product_attributes.* FROM product_attributes WHERE product_id = '#', and similarly for the notifications. And it makes these queries for each product.
So, for every product in the database, the number of queries is a few times that amount. So, although this works well, it does not scale well, as it may potentially result in hundreds of queries.

Ben çizgisinde, bir sorgudaki tüm verileri kapmak için bir sorgu gerçekleştirin:

SELECT p.*, pa.*, n.*
FROM products p
LEFT JOIN product_attributes pa ON pa.product_id = p.product_id
LEFT JOIN product_notifications pn ON pn.product_id = p.product_id
LEFT JOIN notifications n ON n.notification_id = pn.notification_id

(Tekrar basitleştirilmiş). Bu başına veriyi alır, ama her nitelik ve bildirim başına bir ürün, gereksiz bilgi ile ekstra bir satır iade edilecektir gelmiştir.

Örneğin, ben veritabanında iki ürün varsa; biri 1 nitelik ve 1 bayrak vardır ve diğer 3 özelliklerini ve 2 bayraklar vardır, o dönecektir:

product_id, product_name, product_date_added, product_attribute_id, value, notification_id, notification_label
1, My Product, 10/10/10, 1, Color: Red, 1, Add This Product
2, Busy Product, 10/11/10, 2, Color: Blue, 1, Add This Product
2, Busy Product, 10/11/10, 2, Color: Blue, 2, Update This Product
2, Busy Product, 10/11/10, 3, Style: New, 1, Add This Product
2, Busy Product, 10/11/10, 3, Style: New, 2, Update This Product

Bu gereksiz bilgilerin bir sürü söylemeye gerek yok. Ürün başına döndürülen satır sayısı bu kez sahip bildirimlerin sayıda niteliklerin sayı olacaktır.

ORM (ya da, sadece genel döngüde yeni sorgu oluşturma) verileri daha mantıklı ele alınması için izin veren, kendi nesnesine her satırda tüm bilgileri birleştirir. Bu kaya. Bir sorguda bilgileri çağırma sorguları muhtemelen yüzlerce ihtiyacını ortadan kaldırır, ama satırlar gereksiz verilerin çok oluşturur ve bu nedenle özlü setleri (tek / çok)-çok ilişki verilerini dönmez. Bu zor bir yer.

Maalesef bu kadar uzun değil, haha, titiz olmaya çalışıyorum, teşekkürler!