Více dat v DB vs “větší logika” v PHP
- blaztar
- Member | 93
Ahoj,
chtěl jsem se optat na názor co je podle Vás lepší řešení, nejde přímo o Nette, ale snad neva.
Máme produkt TUŽKA, která je v kategorii ŠKOLNÍ VĚCI → PSACÍ POTŘEBY → TUŽKY.
- Uložím do db (produkt_id, menu_id) všechny kategorie kam ta tužka spadá (více záznamu v DB). Pak při výpisu třeba školních potřeb vytáhnu pouze produkty ze ŠKOLNÍCH VĚCÍ (jednoduší).
- Uložím do db pouze kategorii TUŽKY (méně záznamu v DB). Pak při výpisu třeba ŠKOLNÍCH VĚCÍ zjistím i všechny další kategorie co jsou pod a jaký tam jsou produkty a vypíšu to (složitější).
- Ještě nějaká lepší varianta? :)
Dejme tomu že máme v eshopu třeba 50 000 produktů jestli to má nějaký význam. :)
Mě přijde 1. varianta lepší, ale zajímal by mě Váš názor. :)
Last edited by blaztar (2016-08-23 09:47)
- Jan Tvrdík
- Nette guru | 2595
Problematika ukládání stromových dat má mnoho dobrých způsobů řešení. Dohledej si třeba něco o “closure table” (trochu to připomíná tvoji variantu 1) nebo o “traverzování kolem stromu” (anglicky “Modified Preorder Tree Traversal”).
- GEpic
- Member | 566
blaztar wrote:
Jo jasný, díky.
Takže neexistuje jedno dobré (lepší) řešení? :)
Záleží také na dalším způsobu práce s daty a také na programátorovi, který to bude realizovat – To, že je jedno řešení extra super neznamená, že ho každý programátor naprosto chápe, nebo s ním má zkušenosti z jiných projektů a ví na co dopředu při návrhu myslet. :)
Last edited by GEpic (2016-08-23 10:06)
- blaztar
- Member | 93
Jop. :) Takže možná jsem měl formulovat dotaz jinak.
Jak byste to řešily (řešíte) vy? :)
Nejde mi samo o nějaký popis výpisu a všeho okolo, ale jen přímo o danou situaci. Uložení kategorií pro daný jeden produkt.
V nějakým videu jsem viděl, že každý si někdy psal eshop a kdo říká že ně, píše ho do teď. :)
Last edited by blaztar (2016-08-23 10:11)
- GEpic
- Member | 566
Eshop na něčem “svém” jsem nikdy nerealizoval – není ani potřeba, nejsem “éšopař”, od toho tu jsou jiní.
Každopádně často se setkáváme s optimalizací databáze a v 99% případů mají negativní vliv na výkon špatně optimalizované / složité dotazy, kde se “chtělo šetřit” na počtu záznamů. Protože nikomu se nechce věřit, že s dnešním dostupným HW a SSD disky, 56548 jádrovými procesory a 1564645 GB RAM, ty databáze zvládnou miliony záznamů a přitom se ani nezapotí. :)
Last edited by GEpic (2016-08-23 10:17)
- Jan Tvrdík
- Nette guru | 2595
blaztar wrote: Nejde mi samo o nějaký popis výpisu a všeho okolo, ale jen přímo o danou situaci.
Tak to k tomu přistupuješ špatně. Nemůžeš navrhnout datovou strukturu bez toho, aniž bys věděl, jaké operací nad ní budeš primárně provádět.
Jak byste to řešily (řešíte) vy? :)
Napsal jsem ti dva dobré způsoby řešení.