FAQ |
Kalender |
![]() |
#1 | ||
|
|||
Mycket flitig postare
|
Hej!
Genererar rapportdata från ett bokningssystem. Tänkte generera datan och lagra den i db, och sedan generera rapporter utifrån denna data. Informationen skapas som en stdclass (i PHP) som sedan serialiseras (med serialize) och lagras i ett BLOB-fält i databasen. Uppenbarligen räckte inte BLOB-fältet till så strängen var 65535 bytes och en del info saknades. Hittade sedan fälttypen MEDIUMBLOB och LONGBLOB som verkar kunna lagra större mängder data. (MEDIUMBLOB = 16 MB?, LONGBLOB = 4 GB?) Är det dumt att lagra denna typ av info i db:n? Skall kunna generera rapporter i flera format (HTML, PDF m.fl.). Ps: obehandlad data finns även i en annan tabell, tillsammans med data från tidigare rapporter så jag skulle teoretiskt kunna generera rapporterna igen utifrån detta, men känns lite osäkert, och onödigt att behandla informationen igen. Ds. |
||
![]() |
![]() |
![]() |
#2 | |||
|
||||
Bara ett inlägg till!
|
Stora data bör du lagra som filer istället. Det går både snabbare att läsa in, och går att undvika att läsa in hela filen i minnet på en gång (det senasre gäller såklart inte när du kör serialize).
|
|||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Mycket flitig postare
|
Är det smartare att generera en komplett PDF med en gång än att lagra data och generera vid behov?
Är lite osäker på skrivrättigheterna i den mappen jag vill använda. Är rädd för att den kan variera mellan installationer. Därav vill jag lagra i DB. Dock överväger jag fil-alternativet... Funderar som sagt nu på att generera PDF direkt, och skippa HTML (alternativt generera HTML från "rådata"). Känns det bättre? INFO: Har tre tabeller: pos_receipts - lagrar alla kvitton med betalsätt, belopp mm. pos_receipts_data - lagrar alla artiklar på resp. kvitto pos_reports - lagrar alla genererade rapporter, just nu med ett blob-fält men som förmodligen (enligt ovan) kommer bytas till ett filnamn-fält. När rapporten skapas hämtas data från pos_receipts och pos_receipts_data, sammanställs och behandlas för att skapa innehåll till rapporten. Sedan flyttas informationen till en _history-tabell och ursprungstabellen rensas. |
||
![]() |
![]() |
![]() |
#4 | ||
|
|||
Mycket flitig postare
|
Citat:
Som användare vill jag gärna ha ett HTML-alternativ så man slipper öppna PDF-läsare. PDF är bra för att kunna arkivera och skriva ut t.ex. fakturor, men jag tycker fortfarande att det är bra att kunna se en HTML-version av fakturan när man är inloggad hos leverantören. Är det någon vits att mellanlagra rådata om allt ändå finns i pos_receipts + pos_receipts_data? |
||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Klarade millennium-buggen
|
BLOB är till för binärdata, TEXT är till för textdata (skillnaden är att BLOB är skiftlägeskänsligt och TEXT är inte det (vid förfrågningar)).
När du kör serialize() så blir resultatet TEXT. Håller med emilv, att lagra det i filer istället. Det blir en rejäl skillnad. Om du är orolig för skrivrättigheter så testa tempname()*, vars funktion är att skapa en temporär fil. Citat:
|
||
![]() |
![]() |
![]() |
#6 | ||
|
|||
Mycket flitig postare
|
Citat:
![]() Har nu konstaterat att jag behöver både HTML och PDF. Bytte databasfältet till MEDIUMBLOB och den renderar HTML och PDF utefter denna data när man frågar efter sidan. Känner att det är bättre om PDF-en lagras som fil. Dock osäker på hur jag skall lösa det. Jag bygger en komponent i Joomla och det funkar som sagt bra. Jag kan välja att visa "sidan" som html eller PDF och får då en rendering i valt format. Har nu två frågeställningar: 1. Generera PDF Joomla's inbyggda PDF-generator är funkar sådär, men jag har nu lyckats få en snygg PDF med den info jag behöver. Problemet här är att PDF-klassen inte har möjlighet att spara PDF:en. Bara göra en output. Skulle visserligen kuna köra ob_start och ob_get_clean och sedan spara det men det känns inte rätt... 2. Generera HTML Som BjörnJ skriver så är det trevligt att kunna få upp en HTML-version av rapporten. Dock vet jag inte hur jag skall lagra detta. Skall jag generera HTML för just rapporten i sig, spara till en fil, och sedan när man begär sidan lägger den på "template", alltså sidhuvud, meny, sidfot osv. Eller är det bättre att lagra rapport-datan i en fil och generera HTML efter den när man vill visa sidan? 3. MVC-problematiken ![]() Joomla kör ju en variant av MVC Min controller anropas med action/task "makeReport" som då hämtar min ReportModel, vilken sammanställer data, lagrar rapport_id, datum osv. i databasen och slutligen skickar controllern besökaren vidare till en ny url där PDF eller HTML renderas. Nu vet jag inte hur jag skall slå ihop detta rent MVC-mässigt eftersom jag skall både sammanställa data, skapa PDF, skapa HTML och spara dessa för att slutligen vidarebefordra användaren till HTML-versionens url. Min tanke: (pseudo-kod) Kod:
Controller - Hämta ReportModel - kör ReportModel->makeReport ReportModel - Hämta data och sammanställ den - Lagra rapportinfo i db - returnera rapport-ID till controller Controller - Hämta ReportViewPDF - Peta in data från ReportModel - ob_start - Generera rapporten - ob_get_clean - Spara PDF:en - Hämta ReportViewHTML - Peta in data fårn ReportModel - ob_start - Generera rapporten - ob_get_clean - Spara HTML - skicka användaren till "View"-skriptet med HTML-versionen Är detta rätt tänkt? |
||
![]() |
![]() |
![]() |
#7 | ||
|
|||
Medlem
|
Jag förstår inte varför du måste spara "rapportdata" (men det kanske finns en bra anledning), går det inte att generera den data du behöver från MySQL just när rapporten ska skapas utan att spara "mellandata". Så har jag gjort när jag byggt bokningssystem...
1) Kolla på FPDF (http://www.fpdf.org/) , den klarar av precis vad du vill. |
||
![]() |
![]() |
![]() |
#8 | ||
|
|||
Mycket flitig postare
|
Hej igen!
Plockar fram den här tråden igen. Nu funkar min rapport som så att den genererar all data, skapar en HTML och en PDF och lagrar som filer. Dock upptäckte jag nu att "vem som helst" kan läsa dessa rapporter då de ligger i en "tillgänglig" mapp på webbservern. Då kom jag på den "briljanta"(?) idén att lägga en PHP-header i HTML- och PDF-filen som kollar om användaren är inloggad innan den skrivs ut. Känns som det belastar mindre att bara kolla inloggningen än att generera hela rapporten om och om igen. Lagrar dem som "Rapport_23.pdf.php" nu istället... Kanske jag ska gå tillbaks till att generera rapporten on-the-fly istället. Känns lite halvbra iom att det är en "dagsrapport" för en kassa. Jaja, det löser sig nog ![]() |
||
![]() |
![]() |
Svara |
Ämnesverktyg | |
Visningsalternativ | |
|
|