Metoda výpisu dat skrze PHP/MySQL ve webové aplikaci

Ahoj, prosil bych o nějaké usměrnění, jak pracovat s webovou aplikací PHP/MySQL ohledně výpisu většího množství dat v databázi. Jsou to desítky tisíc záznamů o malých opravách/zakázkách. Nemám problém to naprogramovat, ale zajímá mě i použitelnost do budoucna a to, jak to dělají zkušenější a lepší. Logika je taková, že základní informace o zakázkách jsou uloženy v jedné tabulce: id, id_klienta, id_ predmetu, id_dokladu, číslo opravy, termíny, poznámky, atd. Ve druhé tabulce jsou informace o předmětech, tzn. vytváří se tam profily těch předmětů jako takových třeba i pro vytvoření vazby do budoucna, atd. id, typ zařízení, nějaké sériové číslo, popis, atd. Ve třetí tabulce jsou související informace o zákazníkovi, tzn. vytváří se tam adresář zákazníku: id, jméno, kontakty, poznámky, atd. Ve čtvrté tabulce jsou zase doklady za platby, atd. id, id_zakazky, cislo doklady, cena, popis, datumy, stav platby, atd. Ještě jsou tam také třeba nějaké další, ale podstata je z tohoto už asi jasná. Jak na to nejlépe procesně pro výpis zakázek v interním systému? Určitě volím nějaké stránkování výpisu zakázek třeba po 20 záznamech a máme možnost filtrace třeba podle data, čísel zakázek, atd. Takže i s desítkami tisíc záznamů nám to šlape docela svižně. Mám ale obavy, že by to tak nemuselo zůstat. Je proto lepší vytvořit jeden nějaký šílený x-násobně vnořený SELECT dotaz a dát si s tím tu práci a vytáhnout data takto a nebo by se mělo jít spíš tou cestou, že si vytáhnu nejdříve záznamy z první tabulky zakázek a budu si ukládat do proměnné IDčka těch navazbených záznamů jako zákazníků, předmětů a dokladů. Pak bude druhý dotaz na získání přesně těch předmětů, jejichž IDčka jsem vytáhnul v prvním dotazu o zakázkách. Pak bude třetí dotaz na získání přesně těch zákazníků, jejichž IDčka jsem vytáhnul v prvním dotazu o zakázkách a tak dále a tak dále... Takže v prvním dotazu tahám vlastně všechno, ale v těch dalších vždy jen konkrétních 20 záznamů na základě WHERE_IN. Je tohle logická cesta, jak projít záznamy v systému a vypsat záznamy v modulu Zakázky? Máte nějaký tip, jak tohle schéma zlepšit? Pak ještě méně podstatný dotaz a to, zda když mám u záznamu typu zakázka uloženo ID na doklad, tak zda bych to měl mít i opačně, tzn. že u dokladu budu mít ID zakázky ke které patří a nebo jsou tyhle oboustranné vazby blbost. Moc Vám děkuju.

Šílený select ti při velkém množství dat (desítky milionů řádků) může nad mysql zlobit, dělat selecty s where in pro každou tabulku vyprodukuje přes indexy dotazy s konstantním časem, ale budeš bojovat s filtrováním podle zanořené tabulky nebo s řazením. Začni tedy s velkým selectem a buď připraven, že budeš muset v budoucnu dělat optimalizaci na více samostatných selectů, to je ale paradoxně pracnější.Vše přes co spojuješ a vyhledáváš bys měl mít pod indexy.Pak ještě méně podstatný dotaz a to, zda když mám u záznamu typu zakázka uloženo ID na doklad, tak zda bych to měl mít i opačně, tzn. že u dokladu budu mít ID zakázky ke které patří a nebo jsou tyhle oboustranné vazby blbost.Pokud používáš foreign key v innodb enginu, tak tohle platí vždy, klíče jsou v obou tabulkách. Nemá smysl v mysql na tohle použít myisam, ale použíj innodb, absence indexů v košatých spojovaných tabulkách je bolestivá, riziko ztráty tady ještě více. Obecně pokud se ptáš, jak data spojovat (tj. 1:1, 1:N, N:1, M:N), zároveň se ptej podle čeho budeš ty data hledat, tj. budeš hledat a filtrovat zákazníky podle dokladů?Ta struktura tabulek je taková dost naivní, ale jde vidět, že o tom nějak přemýšlíš. Jako základ dobrý, nemám tady prostor ti to překopat a odůvodnit. Drž se 3. normální formy, může to odstranit problémy s nekvalitou dat v budoucnu.

Napsal franta.hosek;1653610

zajímá mě i použitelnost do budoucna a to, jak to dělají zkušenější a lepší.

jednoduche - nehladaj problem tam kde nie je. ked to bude problem, spravi sa novy navrh a data sa premigruju. hotovo. riesit neexistujuce problemy je najrychlejsia cesta ako spalit clovekohodiny a peniaze v tom najhorsiom moznom case.Why Premature Optimization Is the Root of All Evil

Ta struktura tabulek je taková dost naivní, ale jde vidět, že o tom nějak přemýšlíš. Jako základ dobrý, nemám tady prostor ti to překopat a odůvodnit. Drž se 3. normální formy, může to odstranit problémy s nekvalitou dat v budoucnu.

Ty jo, chápu, že je to hodně času a práce s vysvětlováním. Ale kdyby někdo alespoň naznačil v čem ta struktura může být naivní, budu rád :)

Napsal franta.hosek;1653682

Ty jo, chápu, že je to hodně času a práce s vysvětlováním. Ale kdyby někdo alespoň naznačil v čem ta struktura může být naivní, budu rád :)

nemyslel jsem to jako urážku a doufám, že jsi to tak nepochopil. Možná to někdy rozepíšu, ale mám teď jiné věci, který věnuji čas.Krátce, jakýkoliv sloupec, kde máš množné číslo si zaslouží samostatnou entitu/tabulku (termínky, poznámky, kontakty atd.). Z praxe vím, že je velice užitečné sledovat historii v čase, tj. kdy došlo k oslovení, zaznamenávat nějakou proběhlou komunikaci. Platba často probíhá jako záloha, chybí mi na to políčka. Stejně tak potřebuješ mít kam řešit reklamace oprav. Nevidím tam pak komunikační tabulky, např. abys měl evidenci, kdy jsi zákazníkovi napsal, co se kdy změnilo, kdy jsi co připsal.Pak mohu předpokládat, že budeš chtít do databáze ukládat i fotky předmětu při přebírání, případně dokumentaci při opravě a pak při odevzdání. Poté zpravidla u podobných systémů chceš mít evidenci změn v čase, takže třeba transakční historii a tu pak deduplikuješ na poslední verzi, nebo aspoň máš denormalizovanou tabulku se změnami, to je dobré i pro tebe, při vývoji často uděláš chyby, je dobré mít možnost aspoň ručně původní data vytáhnout.To je jen taková střelba bez znalosti domény a vůbec toho co děláš. Jdeš na to dobře, o tabulkách jsi asi přemýšlel, ale jde vidět, že ti tam chybí zpětná vazba z provozu, podobný systém jsi asi ještě nedělal, očekávej tedy že struktura tabulek může být živá a snaž se co nejdřív začít nějaké testování a získat zpětnou vazbu.

Tomasi, ani ja jsem to nepochopil jako urazku. Naopak me to nakoplo vic hloubat, co jsi to svou formulaci o naivnim navrhu mohl myslet. Ale chapu, ze jsi to v podstate myslel tak, ze navrh te struktury je z pohledu navrhu spravne, ale je za tebe nedostatecny. To znamena, ze kdyz prijde treba reklamace na probehlou opravu, tak by system mel mit nejakou schopnost sparovat udaje o te predchozi oprave s tou aktualni, ktera navazuje formou reklamace. A na to jsi postradal tabulku. Proto se odkazujes na ty zkusenosti z provozu, atd.Zaroven ti u pripadu treba chybela historie? To znamena, pokud nekdo provede v zakazce zmenu, tak aby se provedena zmena ulozila, ale zaroven nekde zustal ulozeny puvodni zaznam v databazi, pripadne jinak exportovany do nejakeho archivu a dalo se na to zpetne podivat?Pochopil jsem tohle dobre?

Ano, z pohledu rozdělení tabulek to vypadá jako správný návrh, jen vidím, že nemusí dostačovat.Chápeš to správně, ukládat si někam historii změn je velice užitečné a někdy i žádané, nechceš mít prostě změnitelný stav na jediném místě, při jakémkoliv problémů nebo chybě ztratíš data, to je bolestné a drahé.