Cita: Llevo un tiempo pensando en como hacerlo pero no se me ocurre. Mirar yo tengo un sistema de php con muchos campos, a modo de excel. Es decir, un formulario visualizado a modo de tabla con decenas de campos. Una vez pulso enviar esta info se introduce en mi base de datos, pero desconozco como archivar los registros. ¿Un registro por cada campo? por cada columna?... no tengo ni idea, jeje.
Es un problema de nivel de normalización de la información.
Muchas veces lo que no se percibe cuando no miras con la lógica de un DBA, es que cuando miras una enorme tabla de Excel, con toda la información integrada en la tabla, no sabes que en realidad puedes estar viendo
un reporte creado sobre la base de, digamos, 50 tablas diferentes.
Para poder darte un consejo, deberíamos saber cómo es la estructura de datos de la tabla.
Si lo que quieres es almacenarla sin más, y la información tal y como la muestras en un momento dado no sufrirá cambios en el futuro, simplemente la guardas como un archivo binario (campos BLOB), donde queda congelada como está.
Ahora bien, si lo que quieres es guardar algo que luego se debe consultar parcialmente, o modificar en determinados ítems, es mejor analizar la tabla para ver si posee estructuraciones que permitan realizar una normalización que sea funcional.
Poner simplemente la tabla como está, es un desperdicio de performance a futuro, porque es posible que esté ocupando mucho espacio de disco más de lo que realmente necesita (y por mucho puedo estar diciendo 10 a 1, o 1000 a 1).
Yo comenzaría desde el principio, para ver cómo desplegar la estructura en un conjunto de tablas, de modo que ese reporte se pueda recrear por medio de una consulta.
Así, al menos, es como suelen funcionar esas cosas.
Cita: Se me habia ocurrido en meterlo cada valor en un registro en mi base de datos, pero se me iban a crear miles de registros con poco informacion. Luego se me ha ocurrido en meter un registro con los valores divididos por puntos y comas: manzana;pera; . Pero en ese caso los usuarios no podrian meter ";".
Esto me da la pauta de que la información de esa tabla es normalizable.
En las bases de datos, un campo que pueda contener uno de varios valores se maneja normalmente como dos tablas diferentes, una de las cuales sólo contiene la FK apuntando a la otra (una de Fruta, por ejemplo). De ese modo los usuarios ven en el reporte la información textual, pero el dato se guarda como números (la clave).
Tambien puede pasar que en ese campo deba aparecer una lista de cosas (las frutas separadas por comas). En ese caso son tres tablas: La tabla base, la tabla de items de ese campo, y la tabla de frutas. El listado de valores separados por comas para esa celda de la tabla se obtiene del uso de una función (GROUP_CONCAT()), específicamente usada para eso, sobre la tabla de Fruta.
¿Por qué así y no las palabras? Porque el día de mañana, querrás buscar "peras", y algún bobo puso "pras", o "preas" por teclear mal, y jamás las encontrarás...
Esa es una de las razones por las que en las bases de datos se usan tablas para contener valores que nunca cambian. 
