HTML-formulär, 70+ fält, hantering?

Har du läst nått om de olika fälten du kan använda i MySQL och hur dem lagrar sin data på disken?
Om du inte gjort det så bör du göra det.

Det verkar ju fruktansvärt onödigt att ha en kolumn för varje fält om du redan innan vet 75% ändå inte kommer att fyllas i, jag skulle nog kika vidare på att peta in hela XML-dokumentet i en long text och bara spara det viktigaste i egna kolumner. Det är ju inget problem att bara läsa ut önskade delar av det som är sparat eftersom det dessutom redan är taggat...

Jag misstänker att XML-taggarna kommer orsaka mer overhead än att spara NULL i massor av kolumner. Gör ett snabbt test så får du svar på det. Skapa en tabell med 100 000 rader och 80 kolumner, och gör motsvarande för XML-strukturen. Gämför storlekarna på tabellerna.

Jag skulle analysera, gruppera och normalisera formuläret och göra en proper databasdesign. Bara för att formuläret känns som "70 fält" behöver inte databasdesignen bli så.
Jag ser tydliga objekt: Kund, Order, Orderrader, Produkt etc. Låt dessa objekt bli tabeller så har du en databas som är mycket lätt att hantera på alla sätt och vis.

Edit:
Provade göra den "dåliga" designen med 80 columner, alla varchar(50). Genererade 110 000 rader med 10 fält ifyllda med lite slumpmässigt skräp och resten av kolumnerna fick vara NULL.
Gjorde detta på SQL Server, men jag gissar att innodb lagrar information ungefär på samma sätt.

Mitt resultat, 110 000 rader 80 kolumner:
10.6 MB

Det jag vill säga med detta experiment är att utrymme inte är ditt problem. Om du gör en bra struktur så kommer det löna sig i längden. Det blir lättare att göra komplicerade sökningar, lättare att lägga till och ta bort information, lättare att ändra strukturen, lättare att ha konsistent data och så mycket mer!
Om du vill göra det lätt för dig genom att spara "dokument" i en databas, välj då en databas som är anpassad för det, exempelvis CouchDB eller liknande.

Gjorde lite test på vilka sätt som är snabbaste sättet att hämta sparad information från (tror det är ungefär samma att spara och storleken på disken, däremot verkar MySQL vara speciellt hårddiskkrävande (ca fyra gånger mer än JSON/Serialize(), medan två gånger så mycket som XML)).
Testet är gjort så att 2-1000 arrays (ca 10 tecken lång key samt 32 tecken långt value) sparas på respektive sätt, sen kollar jag hur lång tid det tar att ladda på respektive sätt.

Provade med MySQL, XML, JSON och Serialize(). Använder APC, samt så är databasen lokal (ännu sämre prestanda om den inte är det).

Du kan själv testa här:
http://jacce.dyndns.org/benchmarks/data/?result (du kan lista olika många values, genom att lägga till exempelvis &v=100-250 i URL:n).

EDIT: Enda anledningen jag skulle använda MySQL är om det är riktigt känslig data (som lösenord, annars räcker det nog med deny access i .htaccess), eller om du har ett fält med massa olika kolumner men du behöver bara hämta några få kolumner.
Kanske inte det bästa testet, men ger en fingervisning vilket sätt som är bäst att spara på. Rekommenderar JSON för mindre tabeller eller om du behöver kompatibilitet med andra språk, annars den PHP-specifika funktionen Serialize().