Mejores prácticas para estructuras de archivos personalizadas

Question

Actualmente tengo bastante curiosidad sobre cómo otros programadores organizan los datos en archivos. ¿Alguien puede recomendar buenos artículos o libros sobre las 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, los serializa, codifica a xml, y por qué hace esto?

¿Hay algún secreto que me haya perdido?

Answer 1

Generalmente, vaya con lo más simple que pueda funcionar, al menos al principio. Considere, p. Ej., UNIX, donde la mayoría de los archivos de configuración no son más que campos delimitados por una hoja o campos delimitados con otro carácter (como / etc / passwd, que usa 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 en una forma visualizable en un navegador. De lo contrario, generalmente es muy pesado (tamaño del código, complejidad) para lo que obtienes de él.

Answer 2

No importa el formato que elijas, recuerda guardar dentro algún tipo de número de versión (estoy bastante seguro de que tendrás 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.

Utilizo muchos formatos diferentes, según la situación, por ejemplo:

• archivo de texto sin formato (delimitado) para almacenar conjuntos de datos para el análisis de Matlab y R
• archivos binarios: para almacenar estructuras de tamaño fijo (con el tamaño dinámico, el acceso aleatorio se dificulta sin mantener un conjunto separado de compensaciones para los elementos). Uno de los aspectos positivos es el rendimiento y la 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 proporcionar a otros usuarios (junto con XSD). El otro lado puede escribir una transformación XSLT agradable o consumir los datos de otra manera (por supuesto, podrían hacer lo mismo con texto sin formato o datos binarios dada la descripción del formato)

Answer 3

A menos que tenga requisitos únicos, use algo para lo que ya exista una biblioteca madura, para evitar escribir su propio código de análisis. Eso significa XML / JSON, etc., como la gente ha dicho.

Otro buen ejemplo son 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. Por lo general, el formato es binario, pero también puede usar su clase TextFormat para escribir 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 formato de archivo antiguo y solo deja los nuevos campos en blanco. No es exactamente para lo que se diseñaron los protobufs, pero crean un formato de archivo binario fácil y eficiente para mensajes personalizados, y el código se genera para usted.

También vea Thrift de Facebook, ahora en la incubadora de Apache.

Answer 4

A medida que pasaron los años, me encontré cada vez más a favor de los textos, a menos que simplemente estén 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ñas piezas de información dentro de un archivo grande, esta no es una opción, pero lo más probable es que describa una base de datos.

Se necesitaría una situación inusual en este punto para hacerme ir 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 estás usando 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. Tendría que considerar sus opciones frente a las respuestas a varias preguntas:

• ¿Cuántos datos necesita almacenar? ¿Necesita optimizar para una representación compacta?
• ¿Es crítico el rendimiento de las lecturas / escrituras? ¿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?
• ¿Se van a utilizar estos datos 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 anchos fijos o variables?

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

Answer 7

Hay tantas posibilidades, pero la más pragmática tiene que ser XML

• Hay bibliotecas XML decentes para casi todas las plataformas de desarrollo
• La mayoría de las plataformas permiten la serialización de objetos con un par de líneas de código, por lo que XML es fácil de implementar
• La mayoría de las plataformas tienen un lector de memoria y / o transmisión, por lo que puede manejar archivos realmente grandes sin demasiado uso de memoria
• La mayoría de las plataformas proporcionan un transformador XSLT, por lo que puede mover archivos de un formato a otro, incluso de XML a no XML
• También hay una extensión de indexación para XML para manejar archivos realmente grandes
• XML tiene XSD para 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, simplemente descargue el XML final. Esta técnica se utiliza en Microsoft Office, etc.
• XML sigue siendo legible para humanos
• XML es un estándar común