Citar:

En este caso es un ejemplo pequeño, pero imagina que quieres ir a una parte concreta de un archivo de texto mucho más grande sin tener que leer el contenido anterior.

Vamos a ver: eso no se puede y además es imposible.
¿Cómo puede el ordenador saber si una línea es la tercera sin haber leído la primera y la segunda? Lo que distingue el cambio de línea es el ascii 10. Si no lee las letras una a una ¿cómo va a saber dónde está el tercer ascii 10?.
Los ficheros de texto son, por definición, ficheros secuenciales. Se empiezan por el principio y se leen hasta el final (o hasta que le digamos, pero desde el principio).
No confundáis la capacidad del lenguaje de leer un fichero entero a través de un comando, función o método (como file.load) con no haber leído el fichero de texto desde el principio.
A lo largo de la evolución de la informática se han inventado varias maneras de acortar éso de la lectura secuencial, los "ficheros secuenciales-indexados" y los "ficheros de acceso aleatorio", con los que nos peleábamos en los años 70 y 80.
Todo eso está hoy día superado y volver a utilizar ficheros de texto los como sistema de almacenamiento de datos es un atraso, volver atrás el tiempo, vamos.
Supongo que los "nuevos en la plaza" (y me refiero a aquellos que habéis empezado con la informática ya en el siglo XX!) nunca os habéis planteado, por ejemplo, los siguiente: ¿Qué capacidad de lectura tienen las cabezas de mi disco duro? Porque habréis de saber que el disco no lee las letras que le digas, sino todo lo que puede leer según su capacidad, el formato del disco duro (tamaño del bloque, cluster, número de cabezas, etc.)
Eso quiere decir que siempre que leáis algo, aunque sea un fichero de una letra, el disco va a meter en RAM, digamos 4kb (por decir algo que 4 kb es un tamaño de bloque muy común), luego será el sistema quien discrimine los caracteres concretos que necesitas.
En otras palabras: Para ficheros pequeños (pongamos menos de 4kb) lo mismo da leerlo entero que leer una línea: El sistema te va a cargar en ram todo el fichero. Dada la velociad de manejo de los datos en RAM no hay diferencia apreciable en el tratamiento posterior de esas 4 kb, sea secuencial o sea indexado.
Desde ese punto de vista, cualquiera de las soluciones dadas es válidas.

Para ficheros grandes tenéis las bases de datos. Que se inventaron para eso.

Saludos.

Shordi:

Estoy de acuerdo contigo. Pero la teoría hay que conocerla. Si comienzas a conocer los ficheros de texto y a practicar con ellos, en mi caso,
me  resulta bastante agradable aprender a buscar dentro de ellos, a combinarlos con el uso de estructura de datos.
Además estas aprendiendo a usar métodos que realmente eso te lo va hacer SQL a su manera. Mientras estas haciéndolo
con instrucciones del lenguaje que estas aprendiendo.

Tu sabes que cuando se aprende algo en la programación se debe conocer un poco antes como se hacen las cosas de una manera más
compleja (sin complicarse demasiado) y luego dar las facilidades. Es importante que sepamos que eso existe y ha existido.
Y es muy importante saber trabajar con los archivos de texto. Lo fundamental es afrontar un problema de distintas maneras.
Cuantas mas conozcas mejor.

Como es lógico luego conoces las bases de datos y te das cuenta que lo de antes era más antiguo y que se inventaron para tal fin.
Todo conocimiento y practica en la programación es útil. Ya sea por aprender un tema o practicar y ganar mas experiencia.

Es que no cuentas nada de tus peleas con los archivos de texto en tus épocas pasadas!.  
¿ Llegaste a trabajar en el curro con ellos o ya directamente usabas bases de datos ?

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Es que no cuentas nada de tus peleas con los archivos de texto en tus épocas pasadas!.  
¿ Llegaste a trabajar en el curro con ellos o ya directamente usabas bases de datos ?

Llegué, llegué... entre los años 1985 y 1993, que la empresa adquirió un Unix Sistem V con Oracle 6, lo único parecido a una base de datos eran los archivos .DBF que manejaba el famosísimo paquete dBase II (y III y IV, claro) que ya tenían índices asociados y demás. Sqlite, Access y compañía son los herederos de aquellos sistemas de escritorio en los PC, pero en el ordenador "serio" no disponíamos de tales inventos.
Los archivos secuenciales (léase archivos ASCII  puros y duros, sin acentos, minúsculas ni demás) eran los más comunes para el traspaso de información.
Para el manejo de datos teníamos la posibilidad de utilizar archivos secuenciales-indexados, cuya velocidad de acceso era maravillosa comparado con el secuencial, pero que había que planificar muy bien (qué índice y de qué tipo, qué tamaño de zona de índices y qué tamaño de zona de expansión, etc. etc) y compactar periódicamente si no querías sorpresas desagradables.
Paralelos a ellos teníamos los archivos de acceso aleatorio, mucho más rápidos, pero más peligrosos en caso de desastre en la zona de índices por cuanto no se podía recuperar el contenido de ninguna manera racional.
Mi primer gran desastre informático se produjo con éste último tipo de ficheros. En los manuales de la empresa había una discordancia, en el algoritmo de búsqueda de registro (estamos hablando del viejo y querido COBOL), Si la búsqueda no funcionaba, en el manual de COBOL decía que se retornaba "999999" y en el del sistema decía que "000000". Yo, novato perdido, en una rutina puse una cosa y en otra puse la otra.
El resultado fue un error "disimulado". El programa en cuestión, un censo electoral con 25.000 personas que imprimí en una impresora de líneas a lo largo de casi 9 horas seguidas, la gente salía aparentemente en su localidad y su mesa de votación, pero en realidad salían en el pueblo de al lado (alfabéticamente hablando).
El día de las elecciones me querían quemar en la hoguera... pero como yo era el único "informático" (dos meses de experiencia en el mundo de los teclados) que tenían no tuvieron más remedio que seguir aguantándome.
Corría el verano del año 1.986 y ha pasado muuuucha agua bajo los puentes desde entonces...

Shordi:

Tus vivencias con la programación son bastante interesantes.

De Dbase me acuerdo. Entre las bases de datos que dimos en el curso, fue primero Dbase y luego Access.
Pues si que te dio guerra los secuenciales indexados, así que los compactabais para copias de seguridad, ¿ eran enormes ?.

Y los de acceso aleatorio mucho peor..

Ya me imagino el de tamaño que tendría el archivo de texto con 25k personas.
Supongo que hoy en día ya no te dará tanta guerra con las bases de datos.

Tiene que ser pero gracioso gracioso insertar un registro en un archivo tan grande y que todos los registros haya que moverlos
y na menos que en texto puro. Y con aquellas máquinas de antes. La pera!.

Cuantos cafés te tomarías. Con la cosa que el proceso llevaba su tiempo.
Y que no fallase nada!.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

así que los compactabais para copias de seguridad,

No los ficheros secuenciales indexados se compactaban por su propia naturaleza. El esquema era (por poner un ejemplo y hablando de memoria) Asignabas un tamaño al fichero global (aquellos sistemas operativos -UniOS F4- no admitían ficheros auto-expandibles y había que asignarles tamaño máximo en creación) y luego lo dividías en, más o menos, 75% para datos, 20% para expansión y 5% para índices. los índices contenían las direcciones físicas de los registros dentro del fichero y la zona de expansión era donde se almacenaban las inserciones y modificaciones. El problema era que si el fichero tenía mucho movimiento, la zona de expansión se iba llenando y la velocidad se perdía. Entonces se compactaba el fichero y vuelta a empezar. Los aleatorios no había que modificarlos. Yo los prefería...
En cuanto a las copias de seguridad se hacían con una unidad de cinta magnética, con unos carretes de cinta del tamaño de platos soperos de 1.200 pies y como dos centímetros de ancho. La metías en la lectora y la sujetabas con un trocito de papel celo. Luego podías ver cómo las cabezas lectoras iban pasando de un registro a otro. Eran tan lentas que dedicaba un día entero, los viernes, a hacer las copias de unas... (da vergüenza decirlo) 20 Mb de datos.

¡Qué viejo soy, aquí, contando las batallitas del abuelo Cebolleta! (Ya sabéis "... iba yo al mando de mis doscientos Cipayos..." ¿O tampoco conocisteis a la familia Cebolleta, con Don Rosendo a la cabeza?

Shell escribió: [Ver mensaje]

...imagina que quieres ir a una parte concreta de un archivo de texto mucho más grande sin tener que leer el contenido anterior.

El nuestro amigo habla de ficheros de texto. Pongamos el caso que este fichero tiene 1000 rayas y yo quiero leer solo la raya n. 900:

 

Vuott:

No creo que sea muy lógico, el dato esta en la linea 900...
Es algo complejo. No creo que sea una manera correcta de buscar algo en un archivo de texto.
Sería más fácil decir, búscame todas las lineas que comiencen con Nombre. ¿ verdad ?.

Jorge:

Pues si que era complejo el archivo.  

Citar:

¡Qué viejo soy, aquí, contando las batallitas del abuelo Cebolleta! (Ya sabéis "... iba yo al mando de mis doscientos Cipayos..." ¿O tampoco conocisteis a la familia Cebolleta, con Don Rosendo a la cabeza?

Claro que si.
¿ A que no has visto la peli "El gran Vazquez" ?. A ver a que personaje de Trece Rue del Percebe te suena.


Link


Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Pues no, no la he visto (soy un poco alérgico al Segura...) pero a lo mejor me animo, mira tú.

vuott:


Muy curioso....se podría  montar una función:



(no lo he probado pero deberia de funcionar)...

De todos modos,  como dice Shordi:

Citar:

Para ficheros grandes tenéis las bases de datos. Que se inventaron para eso.

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

siguen planteando soluciones donde se recorre el archivo desde principio a fin.

shordi no comparto tu opinión de que es imposible.

en si este tema es para expertos en programación, para los que escribieron los comandos para crear, editar y guarda archivos, yo solo como novato que soy cuestiono a esos programadores el motivo de que no se pueda acceder directamente a una linea. sin recorrer el archivo de principio a fin.

así como se crea un array con cero elementos o un array con X  elementos asi debería ser la creación de un archivo, con una linea o con X lineas guardando en su interior cuantas lineas tiene el archivo y por lo tanto se podría acceder directamente a una linea para que el carro famoso vaya directamente, me encantaría conocer el código fuente de file.save o mas internamente como es el proceso.

mi pregunta es si se lograra acceder a los archivos directamente a una linea x, seria aun siendo mas convenientes las actuales base de datos???

cuales serias las velocidades de acceso de unos y otros?

===================
Software libre, programación libre, vida libre es la Public function Libertad()as Invendible
Proyectos: VisorRV1960,Taller2015,Tanteador
https://sourceforge.net/u/v3ctor-full/profile/
Blog: http://novatocodegambas.blogspot.com.uy/