StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
14700226
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
4
CommunityOwnedDate
CreationDate
2013-02-05T04:27:39.103
FavoriteCount
0
LastActivityDate
2014-05-12T06:24:08.950
LastEditDate
2014-05-12T06:24:08.950
LastEditorUserId
1734130
OwnerUserId
1734130
ParentId
14699829
PostTypeId
2
Score
18
ViewCount
0
LastEditorDisplayName
text
Body
There is one excellent format that meets all your criteria: <blockquote> <h1>SQLite!</h1> </blockquote> Please read <a href="http://www.sqlite.org/appfileformat.html" rel="nofollow">article</a> about using SQLite as an application file format. Also, please <a href="http://youtu.be/jN_YdMdjVpU" rel="nofollow">watch Google Tech Talk</a> by D. Richard Hipp (SQLite author) about this very topic. Now, lets see how SQLite meets your requirements: <blockquote> The format is a "standard" </blockquote> SQLite has become format of choice for most mobile environments, and for many desktop apps (Firefox, Thunderbird, Google Chrome, Adobe Reader, you name it). <blockquote> Easily integrates with C++ </blockquote> SQLite has <a href="http://www.sqlite.org/cintro.html" rel="nofollow">standard C interface</a>, which is only one source file and one header file. There are <a href="http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers" rel="nofollow">C++ wrappers too</a>. <blockquote> Supports tabular input (2d, n-dimensional) </blockquote> SQLite table is as tabular as you could possibly imagine. To represent say 3-dimensional data, create table with columns <code>x,y,z,value</code> and store your data as a set of rows like this: <pre><code>x1,y1,z1,value1 x2,y2,z2,value2 ... </code></pre> <blockquote> Supports POD types </blockquote> I assume by POD you meant Plain Old Data, or BLOB. SQLite lets you store BLOB fields as is. <blockquote> Can expand as more inputs are required, binds well to variables </blockquote> This is where it really shines. <blockquote> Parsing speed is not terribly important </blockquote> But SQLite speed is superb. In fact, parsing is basically transparent. <blockquote> Ideally, as easy to write (reflect) as it is to read </blockquote> Just use <code>INSERT</code> to write and <code>SELECT</code> to read - what could be easier? <blockquote> Works well on Windows and Linux </blockquote> You bet, and all other platforms as well. <blockquote> Supports compositing (one file referencing another file to read) </blockquote> You can ATTACH one database to another. <blockquote> Human Readable </blockquote> Not in binary, but there are many excellent SQLite browsers/editors out there. I like <a href="http://www.sqliteexpert.com" rel="nofollow">SQLite Expert Personal</a> on Windows and <a href="http://sqliteman.com" rel="nofollow">sqliteman</a> on Linux. There is also <a href="https://addons.mozilla.org/en-us/firefox/addon/sqlite-manager/" rel="nofollow">SQLite editor plugin for Firefox</a>. <hr> <blockquote> There are other advantages that SQLite gives you for free: </blockquote> <ul> <li>Data is indexable which makes it very fast to search. You just cannot do this using XML, JSON or any other text-only formats.</li> <li>Data can be edited partially, even when amount of data is very large. You do not have to rewrite few gigabytes just to edit one value.</li> <li>SQLite is fully transactional: it guarantees that your data is consistent at all times. Even if your application (or whole computer) crashes, your data will be automatically restored to last known consistent state on next first attempt to connect to the database.</li> <li>SQLite stores your data verbatim: you do not need to worry about escaping junk characters in your data (including zero bytes embedded in your strings) - simply always use <a href="http://en.wikipedia.org/wiki/Prepared_statement" rel="nofollow">prepared statements</a>, that's all it takes to make it transparent. This can be big and annoying problem when dealing with text data formats, XML in particular.</li> <li>SQLite stores all strings in Unicode: <code>UTF-8</code> (default) or <code>UTF-16</code>. In other words, you do not need to worry about text encodings or international support for your data format.</li> <li>SQLite allows you to process data in small chunks (row by row in fact), thus it works well in low memory conditions. This can be a problem for any text based formats, because often they need to load all text into memory to parse it. Granted, there are few efficient stream-based XML parsers out there, but in general any XML parser will be quite memory greedy compared to SQLite.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PO"Best" Input File Formats for C++?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USmvp
UserOwnerUserId
1. USmvp
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.