Lagra mycket data i MySQL som LONGBLOB
 

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.

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).

Ä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.

Eller generera både HTML och PDF?
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?

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.

Tar upp denna tråden igen ;)

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 :eek:
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)
Känns som det blir mycket kod i controllern, men det känns fel att lägga den i ReportModel eftersom den anropar flera Views för att rendera.
Är detta rätt tänkt?

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.

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 :D