Kom ihåg mig?

Lagra mycket data i MySQL som LONGBLOB

Ämnesverktyg Visningsalternativ
Oläst 2009-12-15, 21:09 #1
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
Standard 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.
qson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2009-12-15, 21:35 #2
emilvs avatar
emilv emilv är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Feb 2004
Inlägg: 1 564
emilv emilv är inte uppkopplad
Bara ett inlägg till!
emilvs avatar
 
Reg.datum: Feb 2004
Inlägg: 1 564
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).
emilv är inte uppkopplad   Svara med citatSvara med citat
Oläst 2009-12-15, 22:53 #3
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
Ä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.
qson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2009-12-15, 23:35 #4
BjörnJ BjörnJ är inte uppkopplad
Mycket flitig postare
 
Reg.datum: May 2009
Inlägg: 971
BjörnJ BjörnJ är inte uppkopplad
Mycket flitig postare
 
Reg.datum: May 2009
Inlägg: 971
Citat:
Ursprungligen postat av qson Visa inlägg
Funderar som sagt nu på att generera PDF direkt, och skippa HTML (alternativt generera HTML från "rådata").
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?
BjörnJ är inte uppkopplad   Svara med citatSvara med citat
Oläst 2009-12-15, 23:51 #5
Jonas Jonas är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Feb 2004
Inlägg: 3 364
Jonas Jonas är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Feb 2004
Inlägg: 3 364
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:
* Creates a file with a unique filename, with access permission set to 0600, in the specified directory. If the directory does not exist, tempnam() may generate a file in the system's temporary directory, and return the name of that.
Jonas är inte uppkopplad   Svara med citatSvara med citat
Oläst 2009-12-28, 20:23 #6
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
Citat:
Ursprungligen postat av Jonas Visa inlägg
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
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
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?
qson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-01-02, 16:03 #7
mersault mersault är inte uppkopplad
Medlem
 
Reg.datum: Apr 2006
Inlägg: 119
mersault mersault är inte uppkopplad
Medlem
 
Reg.datum: Apr 2006
Inlägg: 119
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.
mersault är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-01-09, 13:15 #8
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
qson qson är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Sep 2006
Inlägg: 513
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
qson är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 
Ämnesverktyg
Visningsalternativ

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 17:50.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017