Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113

    [C] File ad accesso casuale e file ad accesso sequenziale

    Ciao,
    qualcuno sa dirmi la differenza sostanziale tra un file ad accesso sequenziale ed un file ad accesso casuale ?

  2. #2
    Non mi risulta che il C in sé parli mai di file ad accesso casuale/sequenziale... Puoi chiarire esattamente il contesto dei termini in questione? Perché a seconda del contesto i termini in questione si possono riferire ad almeno due concetti piuttosto diversi (file organizzati a record a lunghezza fissa vs file con record di testo a lunghezza variabile, oppure file in cui ci si muove liberamente via fseek vs file in cui si può solo leggere/scrivere in maniera sequenziale).
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #3
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113
    Si tratta dell'elaborazione dei file. Tipo una differenza che ho capito è che i record di un file ad accesso casuale non hanno la stessa lunghezza mentre i recordo di un file ad accesso casuale hanno tutti la stessa lunghezza..ma è solo questa la differenza e cosa comporta ?
    Grazie

  4. #4
    In un file ad accesso casuale (e quindi con record di lunghezza fissa) muoversi al record desiderato è istantaneo: basta fare una fseek alla posizione numero_record*dimensioni_record; al contrario, se i record non hanno lunghezza fissa, per sapere dov'è il record successivo devi leggere il primo record, determinare quanto è lungo e passare a quello successivo, e via così fino al record che ti interessa - ovvero, in un caso puoi muoverti nel file liberamente in tempo costante, nell'altro il seek ad un record specifico è O(n).

    Joel Spolsky in questo articolo fa un esempio che credo chiarisca abbastanza bene la differenza:
    Last week I wrote that you can't implement the SQL statement SELECT author FROM books fast when your data is stored in XML. Just in case everybody didn't understand what I was talking about, and now that we've been rolling around in the CPU all day, this assertion might make more sense.

    How does a relational database implement SELECT author FROM books? In a relational database, every row in a table (e.g. the books table) is exactly the same length in bytes, and every fields is always at a fixed offset from the beginning of the row. So, for example, if each record in the books table is 100 bytes long, and the author field is at offset 23, then there are authors stored at byte 23, 123, 223, 323, etc. What is the code to move to the next record in the result of this query? Basically, it's this:
    codice:
    pointer += 100;
    One CPU instruction. Faaaaaaaaaast.

    Now lets look at the books table in XML.
    codice:
    <?xml blah blah>
    <books>
         <book>
              <title>UI Design for Programmers</title>
              <author>Joel Spolsky</author>
         </book>
         <book>
              <title>The Chop Suey Club</title>
              <author>Bruce Weber</author>
         </book>
    </books>
    Quick question. What is the code to move to the next record?

    Uh...

    At this point a good programmer would say, well, let's parse the XML into a tree in memory so that we can operate on it reasonably quickly. The amount of work that has to be done here by the CPU to SELECT author FROM books will bore you absolutely to tears. As every compiler writer knows, lexing and parsing are the slowest part of compiling. Suffice it to say that it involves a lot of string stuff, which we discovered is slow, and a lot of memory allocation stuff, which we discovered is slow, as we lex, parse, and build an abstract syntax tree in memory. That assumes that you have enough memory to load the whole thing at once. With relational databases, the performance of moving from record to record is fixed and is, in fact, one CPU instruction. That's very much by design. And thanks to memory mapped files you only have to load the pages of disk that you are actually going to use. With XML, if you preparse, the performance of moving from record to record is fixed but there's a huge startup time, and if you don't preparse, the performance of moving from record to record varies based on the length of the record before it and is still hundreds of CPU instructions long.

    What this means to me is that you can't use XML if you need performance and have lots of data. If you have a little bit of data, or if what you're doing doesn't have to be fast, XML is a fine format. And if you really want the best of both worlds, you have to come up with a way to store metadata next to your XML, something like Pascal strings' byte count, which give you hints about where things are in the file so that you don't have to parse and scan for them. But of course then you can't use text editors to edit the file because that messes up the metadata, so it's not really XML anymore.
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #5
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113
    ok ti ringrazio

  6. #6
    Amaro C++, il gusto pieno dell'undefined behavior.

  7. #7
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113
    Quindi, questo significa che le struct posso utilizzarle solo in un file ad accesso casuale?

    P.S. Come mai non mi arrivano più le notifiche delle risposte sulla mia email ?
    Ultima modifica di sizeof; 07-10-2013 a 16:29

  8. #8
    Non necessariamente: puoi usare le struct all'interno del tuo programma e serializzarle su file in un formato non a lunghezza fissa - ad esempio, in un formato testuale, o, in altri casi, può essere necessario scrivere su file struct a lunghezza variabile.
    Inoltre, è sempre possibile leggere in maniera sequenziale un intero file ad accesso casuale (=leggo tutti i record uno dopo l'altro).
    Amaro C++, il gusto pieno dell'undefined behavior.

  9. #9
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113
    io devo creare un file e scriverci dei dati in una struct. poi devo aprire il file in lettura ed ordinarli secondo un campo chiave e successivamente fare una ricerca secondo un campo che mi permetta di visualizzare l'intero recordo della struct del campo cercato..provo ad utlizzare un file ad accesso sequenziale.il problema è che se creo il file in scrittura all'inizio dell'esecuzione del programma..non vado ogni volta a cancellare quelli già inseriti?

  10. #10
    Utente di HTML.it
    Registrato dal
    Sep 2013
    Messaggi
    113
    Quote Originariamente inviata da sizeof Visualizza il messaggio
    io devo creare un file e scriverci dei dati in una struct. poi devo aprire il file in lettura ed ordinarli secondo un campo chiave e successivamente fare una ricerca secondo un campo che mi permetta di visualizzare l'intero recordo della struct del campo cercato..provo ad utlizzare un file ad accesso sequenziale.il problema è che se creo il file in scrittura all'inizio dell'esecuzione del programma..non vado ogni volta a cancellare quelli già inseriti?

    Mi spiego meglio: devo gestire i dati relativi ad una sala ricevimenti per i matrimoni.
    le informazioni sono su un file "eventi.dat" (che non ho e quindi devo creare con i dati).
    il file contiene strutture (variabile matrimonio) con COGNOME SPOSO, COGNOME SPOSA, DATA, NUMERO INVITATI.
    ora devo:
    1) ordinare in senso decrescente tutti i dati in base al numero degli invitati.
    2) devo poter ricavare il cognome degli sposi in base alla data di matrimonio (ricerca dicotomica).
    Entrame queste operazioni devono essere fatte in memoria centrale e poi tutto deve essere rimesso sullo stesso file

    Mi conviene utilizzare un file ad accesso sequenziale o casuale???
    Ultima modifica di sizeof; 07-10-2013 a 16:57

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.