Σχεδιαση βασης με πολλα join, ειναι σωστο;

[παπι]

μπαλ μπλα μπλα μπλα.

Και που λες εφτασα να εχω αυτο το query

public function getactiveorders()
	{
		if($this->ion_auth->logged_in())
		{
			$output = array();
			$res = $this->db
				->select('orders.id,orders.ts_create,orders.ts_promise,orders.state,orders.ts_done,addresses.lat,addresses.lng,addresses.fullAddress,customers.name,customers.phone')
				
				->from('orders')
				->where('orders.state','store')
				->join('customers','orders.id_customer = customers.id')
				->join('addresses','customers.id_addresses = addresses.id')
				
				->get()
				->result();
			
			foreach($res as $row)
			{
				
				$output[] = array(
					'fullAddress' => $row->fullAddress,
					'location' => array('lat' => floatval($row->lat),'lng' =>  floatval($row->lng)),
					'name' => $row->name,
					'status' => $row->state,
					'id' => $row->id
					);
				
			}
			
			echo json_encode($output);
		}
	}

Αυτο ειναι καλο ή κακο; Δηλαδη το κριτηριο μπανει στο πινακα orders, απο εκει παω με fk στο customers και απο κει με fk στο addresses. Θα ηταν κλαυτερα να βαλω fk orders -> addresses ή δεν υπαρχει προβλημα;

[defacer]

Όλα καλά, τυπικό σενάριο, και 2 joins... δεν είναι πολλά. 

[Lanike71]

Εγώ προτιμώ το κλασικό, άρα Α.

[παπι]

Βασικα το αλλαξα και εβαλα fk order -> address, οχι για τα join που ετσι και αλλιως μενουν ως εχουν. Αλλα επειδη υπαρχει λογικο λαθος στο οτι customer == address. Θα βγαλω και το fk customer -> address και θα βαλω αλλο πινακα που θα εχει fk address fk customer. Βασικα ο νεος πινακας θα πρεπει να εχει fk; ή απλα idx customer_idx address_idx χωρις να ειναι fk. Η ουσια ειναι να κανεις ενα select customer id και να δεις ποιες addresses εχει.

 

edit; μου ηθελα και plain php... θα φευγανε οι χριστοπαναγιες απο τον νεο κοσμος κια θα φτανανε μεχρι την βουλα

[Xvipes]

Όλα καλά, τυπικό σενάριο, και 2 joins... δεν είναι πολλά. 

$supplierList = $objSupplier->getCustomSql("SELECT * FROM `ordItem` AS a
INNER JOIN memberΑff AS b ON a.memAffId = b.memId
INNER JOIN prodCache AS c ON a.prodId = c.prodId
INNER JOIN memb AS d ON d.memId = b.memId
INNER JOIN suppl AS e ON e.supId = a.supId 
WHERE (dateSelected BETWEEN ".$dateFrom." AND ".$dateTo.")  AND affType='api'
ORDER BY a.memberAffId ASC");

Πότε πρέπει να ανησυχήσει κάποιος?

Ρωτάω γιατί με απασχολεί και εμένα αυτές τις μέρες ότι έχω φτάσει στο παραπάνω σημείο.

 

Όταν εξ αρχής δεν ήξερες ότι θα γίνει έτσι το project τι σου μένει να κάνεις? Redesign όλη τη βάση?

 

p.s ελπίζω να μην έκανα hijack, για δείγμα τον έβαλα τον κώδικα. Για τον τίτλο του thread ρωτάω και εγώ

[ParhsG]

Οι σχεσιακές βάσεις χοντρικά βασίζονται στις σχέσεις (σχεσιακή άλγεβρα). Αυτή είναι η δουλειά τους να κάνουν join κτλ. Αν αρχίσουν τα προβλήματα τότε έχει νόημα να κάνεις βελτιστοποιήσεις κτλ. 

[tasanton]

Και denormalization σε αρκετές περιπτώσεις....

[DeltaLover]

Συμφωνώντας με τους προλαλήσαντες, νομίζω ότι το συγκεκριμένο snippet είναι απόλυτα αποδεκτό τόσο από την καθαρά "λογική" του πλευρά καθώς αποτελεί σαφή περίπτωση της First Normal Form όσο επίσης και όσον αφορά τo performance (εννοείται ότι έχεις δημιουργήσει τα σχετικά indexes) .  

 

Hint: Δες αν μπορείς να χρησιμοποίσεις Memoization για να μετριάσεις το db traffic. 

[antonisid]

Μιας και αναφέρθηκε το θέμα της απόδοσης, τελευταία έχω περιορίσει σημαντικά τα joins σε πίνακες. 3 queries πχ ένα για τον κάθε πίνακα, έχουν καλύτερο performance απ ότι 1 query με 3 joins.

[pmav99]

@antonisid

Δεν ισχύει σε κάθε περίπτωση αυτό. Αν ή βάση σου είναι απομακρυσμένη το bottleneck είναι το network. Γενικά πρέπει να το βλέπεις case by case υπολογίζοντας όλες τις παραμέτρους κάθε φορά.

 

Επίσης για να έχει νόημα ή σύγκριση πρέπει να κάνεις profiling στον κώδικά και όχι στα queries. Γιατί δεν είναι σίγουρο ότι ο συνολικός χρόνος/χρήση RAM/whatever θα είναι μικρότερα.

 

υγ. Εννοείται ότι όταν μιλάμε για joins έχουν γίνει τα απαραίτητα indexes και ότι το scheme είναι σωστά σχεδιασμένο.

[antonisid]

@antonisid

Δεν ισχύει σε κάθε περίπτωση αυτό. Αν ή βάση σου είναι απομακρυσμένη το bottleneck είναι το network. Γενικά πρέπει να το βλέπεις case by case υπολογίζοντας όλες τις παραμέτρους κάθε φορά.

 

Επίσης για να έχει νόημα ή σύγκριση πρέπει να κάνεις profiling στον κώδικά και όχι στα queries. Γιατί δεν είναι σίγουρο ότι ο συνολικός χρόνος/χρήση RAM/whatever θα είναι μικρότερα.

 

υγ. Εννοείται ότι όταν μιλάμε για joins έχουν γίνει τα απαραίτητα indexes και ότι το scheme είναι σωστά σχεδιασμένο.

 

Συμφωνώ σε όλα! Γι αυτό είπα άλλωστε ότι τα έχω περιορίσει, καθώς εξαρτάται την περίπτωση.

[nikos_90]

μπαλ μπλα μπλα μπλα.

Και που λες εφτασα να εχω αυτο το query

public function getactiveorders()
	{
		if($this->ion_auth->logged_in())
		{
			$output = array();
			$res = $this->db
				->select('orders.id,orders.ts_create,orders.ts_promise,orders.state,orders.ts_done,addresses.lat,addresses.lng,addresses.fullAddress,customers.name,customers.phone')
				
				->from('orders')
				->where('orders.state','store')
				->join('customers','orders.id_customer = customers.id')
				->join('addresses','customers.id_addresses = addresses.id')
				
				->get()
				->result();
			
			foreach($res as $row)
			{
				
				$output[] = array(
					'fullAddress' => $row->fullAddress,
					'location' => array('lat' => floatval($row->lat),'lng' =>  floatval($row->lng)),
					'name' => $row->name,
					'status' => $row->state,
					'id' => $row->id
					);
				
			}
			
			echo json_encode($output);
		}
	}

Αυτο ειναι καλο ή κακο; Δηλαδη το κριτηριο μπανει στο πινακα orders, απο εκει παω με fk στο customers και απο κει με fk στο addresses. Θα ηταν κλαυτερα να βαλω fk orders -> addresses ή δεν υπαρχει προβλημα;

 

 

Code igniter ε?

Δοκιμασε να χρησιμοποιησεις doctrine, νομιζω εχουν βγαλει library και για codeigniter