none
XML COMO ARMAZENAMENTO DE DADOS. RRS feed

  • Pergunta

  • Tenho um hardware que criei onde ele me envia por conexão serial a seguinte informação (ID, STATUS, MEDIÇÃO). Estas informações são recebidas a cada 1 minuto e mostradas na tela para o usuário, podendo ser usadas em relatórios customizados por data e hora da medição. Estou trabalhando com windows form C#. Minhas peguntas são:

    - Posso armazenar estes dados em XML ao invés de usar banco de dados?

    - Por se tratar de um sistema de monitoramento em tempo real estarei armazenando os seguintes dados recebidos dos equipamentos (ID_EQUIP; STATUS_EQUIP; VALOR_MEDIÇÃO; DATA_MEDIÇÃO; HORA_MEDIÇÃO) Se tratando de horas e horas de armazenamento(Até anos), é viável ter um arquivo tão grande?



    terça-feira, 11 de agosto de 2015 19:14

Respostas

  • Nao.. Eu diria que seria muito arriscado. Outra coisa, XML é um formato poluido, ideal para pequenas quantidades de dados. 

    Eu sugiro voce usar o SQLite. É uma banco de dados nao gerenciado com a mesma estrutura de comandos (DDL e DML) do SQL Server.

    Nada precisa ser instalado, basta adicionar uma dll ao projeto e usar os comandos. 

    aqui um exemplo em c#

    http://blog.tigrangasparian.com/2012/02/09/getting-started-with-sqlite-in-c-part-one/

    Basicamente voce tem um SQL server portatil.

    Aqui uma lista de vantagen do SQLite sobre arquivos texto (xml ou csv)

    Advantages of SQLite Database over File Storage

    • If you have data related with each other, file will not allow you to relate them. At that time SQLite will help you.
    • If you wan to query your data, store the data in structured manner you wil prefer SQLite
    • SQLite has higher performance
    • SQLite database can also be queried and the data retrieval is much more robust.
    • The android.database and android.database.sqlite packages offer a higher-performance alternative where source compatibility is not an issue.
    • Android-databases created in Android are visible only to the application that created them
    • There is no file parsing and generating code to write and debug.
    • Content can be accessed and updated using powerful SQL queries, greatly reducing the complexity of the application code.
    • Extending the file format for new capabilities in later releases is a simple as adding new tables or new columns to existing tables.
    • Diverse content which might otherwise be stored as a "pile-of-files" can be encapsulated into a single disk file.
    • The content can be viewed using third-party tools.
    • The application file is portable across all operating systems, 32-bit and 64-bit and big- and little-endian architectures.
    • The application only has to load as much data as it needs, rather than reading the entire application file and holding a complete parse in memory. Startup time and memory consumption are reduced.
    • Small edits only overwrite the parts of the file that change, not the entire file, thus improving performance and reducing wear on SSD drives.
    • Content is updated continuously and atomically so that there is no work lost in the event of a power failure or crash.
    • Applications can leverage the full-text search and RTREE capabilities that are built into SQLite.
    • Performance problems can often be resolved using CREATE INDEX rather than redesigning, rewriting, and retesting application code.
    • A federation of programs, perhaps written in different programming languages, can all access the same application file with no compatibility concerns.
    • Multiple processes can attach to the same application file and can read and write without interfering with each another.
    • Cross-session undo/redo can be implemented using triggers.
    • In many common cases, loading content from an SQLite database is faster than loading content out of individual files. See Internal Versus External BLOBs for additional information.
    • Content stored in an SQLite database is more likely to be recoverable decades in the future, long after all traces of the original application have been lost. Data lives longer than code.

    att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 11 de agosto de 2015 19:40

Todas as Respostas

  • Nao.. Eu diria que seria muito arriscado. Outra coisa, XML é um formato poluido, ideal para pequenas quantidades de dados. 

    Eu sugiro voce usar o SQLite. É uma banco de dados nao gerenciado com a mesma estrutura de comandos (DDL e DML) do SQL Server.

    Nada precisa ser instalado, basta adicionar uma dll ao projeto e usar os comandos. 

    aqui um exemplo em c#

    http://blog.tigrangasparian.com/2012/02/09/getting-started-with-sqlite-in-c-part-one/

    Basicamente voce tem um SQL server portatil.

    Aqui uma lista de vantagen do SQLite sobre arquivos texto (xml ou csv)

    Advantages of SQLite Database over File Storage

    • If you have data related with each other, file will not allow you to relate them. At that time SQLite will help you.
    • If you wan to query your data, store the data in structured manner you wil prefer SQLite
    • SQLite has higher performance
    • SQLite database can also be queried and the data retrieval is much more robust.
    • The android.database and android.database.sqlite packages offer a higher-performance alternative where source compatibility is not an issue.
    • Android-databases created in Android are visible only to the application that created them
    • There is no file parsing and generating code to write and debug.
    • Content can be accessed and updated using powerful SQL queries, greatly reducing the complexity of the application code.
    • Extending the file format for new capabilities in later releases is a simple as adding new tables or new columns to existing tables.
    • Diverse content which might otherwise be stored as a "pile-of-files" can be encapsulated into a single disk file.
    • The content can be viewed using third-party tools.
    • The application file is portable across all operating systems, 32-bit and 64-bit and big- and little-endian architectures.
    • The application only has to load as much data as it needs, rather than reading the entire application file and holding a complete parse in memory. Startup time and memory consumption are reduced.
    • Small edits only overwrite the parts of the file that change, not the entire file, thus improving performance and reducing wear on SSD drives.
    • Content is updated continuously and atomically so that there is no work lost in the event of a power failure or crash.
    • Applications can leverage the full-text search and RTREE capabilities that are built into SQLite.
    • Performance problems can often be resolved using CREATE INDEX rather than redesigning, rewriting, and retesting application code.
    • A federation of programs, perhaps written in different programming languages, can all access the same application file with no compatibility concerns.
    • Multiple processes can attach to the same application file and can read and write without interfering with each another.
    • Cross-session undo/redo can be implemented using triggers.
    • In many common cases, loading content from an SQLite database is faster than loading content out of individual files. See Internal Versus External BLOBs for additional information.
    • Content stored in an SQLite database is more likely to be recoverable decades in the future, long after all traces of the original application have been lost. Data lives longer than code.

    att


    William John Adam Trindade
    Analyste-programmeur
    ----------------------------------------------------------


    terça-feira, 11 de agosto de 2015 19:40
  • Obrigado William;

                              Vou testar aqui, valeu pela dica...!

    quinta-feira, 13 de agosto de 2015 11:05