Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In general I agree with you:</p> <ul> <li>XML is widely deployed, there's tonnes of tools to bring the logbook into shape.</li> <li>It's flexible, you can add additional attributes later without breaking old ``scripts''</li> <li>It's file based, one document, one file, use the filesystem to organise logbook ``pages''</li> <li>It's file based and plain text, tools like find, grep, diff (at a push) can help you in urgent cases</li> <li>It's <em>your own</em> solution, you're free to track any information you need, and if you deem it essential to associate sunlight hours with the parameters, do it.</li> </ul> <p>That being said, I should add the storage format depends on the typical use case, if you need to find out why every monday after a full moon the optimiser cannot find any solutions, it will be hard (well, harder) to come up with the necessary XPath/XQuery hackery to do that <em>because</em> of the non-normativity of your structure.</p> <p>Well all the downsides I can think of:</p> <ul> <li>It's verbose, XML documents in my area tend to be more like 20 to 40 GBs whereas the info probably could be represented in more like 500 MB.</li> <li>It's slow (depends on how you use it), RDBMs or even nosql solutions employ techniques like indexing to make <em>reading</em> faster.</li> <li>It's flexible, that's also a downside: If you happen to add two new attributes per day you will end up with nothing but a marked up free text, it will need thorough polishing if you want to import it into structure-focussed systems (SQL, csv, json, ...)</li> <li>It's <em>your own</em> solution, you have to write it and maintain it</li> </ul> <p>As for the second bit: <code>git describe --always HEAD</code></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload