Mejores prácticas para estructuras de archivos personalizados

Question

Actualmente tengo bastante curiosidad sobre cómo otros programadores organizan los datos en archivos. ¿Alguien puede recomendar buenos artículos o libros sobre mejores prácticas para crear estructuras de archivos?

Por ejemplo, si ha creado su propia pieza de software para cualquier propósito, ¿deja los datos guardados como texto sin formato, lo serializa, codifica a xml y por qué lo hace?

¿Hay algún secreto que me haya perdido?

Answer 1

Generalmente, vaya con la cosa más simple que pueda funcionar, al menos al principio. Considere, por ejemplo, UNIX, donde la mayoría de los archivos de configuración no son más que campos delimitados por espacios en blanco, o campos delimitados con otro carácter (como/etc/passwd, que utiliza delimitadores ":" porque el campo GCOS puede contener espacios en blanco)

Si sus datos necesitan mucha más estructura, pregúntese "¿qué herramientas puedo usar fácilmente?" Python y Ruby tienen JSON y YAML, por ejemplo.

XML es básicamente útil si ya tiene muchas cosas basadas en XML, O espera transformar el XML a un formulario desplegable en un navegador. De lo contrario, suele ser muy pesado (tamaño del código, complejidad) por lo que obtienes de él.

Answer 2

Independientemente del formato que elija, recuerde almacenar algún tipo de número de versión (estoy bastante seguro de que tendrá que introducir algunos cambios).

El formato depende en gran medida de la aplicación y la cantidad de datos. Para algunas aplicaciones, XML es apropiado, para otras aplicaciones las estructuras de tamaño fijo almacenadas en un archivo binario son buenas.

Yo uso muchos formatos diferentes, dependiendo de la situación, por ejemplo:

• archivo de texto sin formato (delimitado) para almacenar conjuntos de datos para el análisis Matlab y R
• archivos binarios - para almacenar estructuras de tamaño fijo (con tamaño dinámico, el acceso aleatorio se vuelve difícil sin mantener una serie separada de compensaciones para los elementos). Una de las ventajas es que tiene rendimiento y eficiencia de espacio (¿por qué la mayoría de las bases de datos almacenan datos en formato binario?), Pero no es muy bueno para los seres humanos trabajar con ellos. Recuerde de la endianess.
• XML: generalmente para datos de configuración o datos que deseo dar a otras aplicaciones de usuarios (junto con XSD). El otro lado puede escribir agradable transformación XSLT o consumir los datos de otra manera (por supuesto que podría hacer lo mismo con el texto sin formato o datos binarios dada la descripción del formato)

Answer 3

A menos que tenga requisitos únicos, utilizar algo para lo cual ya hay una biblioteca madura, por lo que puede evitar escribir su propio código de análisis. Eso significa XML/JSON, etc., como dicen las personas.

Otra buena es los buffers de protocolo de Google (http://code.google.com/p/protobuf). Allí escribe una definición de mensaje común y el compilador de búfer de protocolo genera objetos para completar, serializar y deserializar los datos por usted. Normalmente, el formato es binario, pero puede usar su clase TextFormat para escribir también texto plano similar a JSON. Lo bueno de protobufs es que el código de versión se genera para usted. En la versión 2 de su formato de archivo, todo lo que tiene que hacer es agregar campos al archivo de definición .proto. La nueva versión puede leer el antiguo formato de archivo y simplemente deja los nuevos campos en blanco. No es exactamente para lo que se diseñaron los protobufs, pero hacen un formato de archivo binario fácil y eficiente para mensajes personalizados, y el código se genera para usted.

Ver también Facebook Thrift, ahora en la incubadora Apache.

Answer 4

A medida que han pasado los años, me he encontrado cada vez más a favor del texto a menos que simplemente esté fuera de discusión. Las CPU son lo suficientemente rápidas ahora que podemos decodificarlas lo suficientemente rápido.

Obviamente, cuando tiene que actualizar con frecuencia pequeños fragmentos de información dentro de un archivo grande, esta no es una opción, pero eso probablemente describe una base de datos.

En este punto, sería una situación inusual hacer que vaya con algo más que una de estas dos opciones.

Answer 5

+1 para XML. Tiene un poco de sobrecarga, pero es fácil de analizar, leer y depurar. Puede ser estricto si usa un esquema. Fácil de transformar con XSLT, y muy portátil (en cable o simplemente en un pendrive :)

Answer 6

Esto realmente depende de la situación particular. Debería considerar sus opciones en función de las respuestas a varias preguntas:

• ¿Cuántos datos necesita almacenar? ¿Necesita optimizar para una representación compacta?
• ¿El rendimiento de las lecturas/escrituras es crítico? ¿Necesita optimizar el acceso al disco y la serialización y deserialización de bajo impacto?
• ¿Necesita acceso aleatorio dentro del archivo? ¿Necesita optimizar la estructura para buscar dentro de los datos?
• ¿Esta información va a ser utilizada en diferentes sistemas, posiblemente con diferentes codificaciones de caracteres? ¿Necesita optimizar para la portabilidad?

La naturaleza de los datos en sí tendrá un impacto. ¿Es una estructura de lista plana? ¿Es un árbol? ¿Es un gráfico cíclico? Son los registros de anchuras fijas o variables?

Una vez que se conocen las respuestas a estas preguntas, puede seleccionar entre sus opciones, manteniéndola lo más simple posible. A menudo, las opciones populares (XML, CSV, YAML) se adaptarán a sus propósitos. De lo contrario, tendrá que desarrollar su propio formato y sus propios procedimientos de escritura y lectura.

Answer 7

Hay tantas posibilidades, pero el más pragmático tiene que ser XML

• Hay bibliotecas XML dignas para la plataforma de casi todos los de desarrollo
• mayoría de las plataformas permiten objeto gráfico serialización con un par de líneas de código , por lo XML es indoloro para implementar
• mayoría de las plataformas tienen una memoria y/o lector de streaming, por lo que puede manejar archivos muy grandes y sin el uso de memoria demasiado
• la mayoría proporcionan una plataforma tranformer XSLT, para que pueda moverse fil es de un formato a otro, incluso de XML a no XML
• Hay extensión de la indexación de XML para manejar archivos muy grandes también
• XML tiene XSD de validar el formato antes de intentar leerlo
• XML es capaz de representar cualquier objeto simple o complejo
• Si le preocupa el tamaño del archivo, solo comprima el XML final.Esta técnica se utiliza en Microsoft Office, etc
• XML sigue siendo legible
• XML es un estándar común