FWIW, I made an app way back in 2002 that uses CGI.pm’s “Save” function to save a CGI object. CGI.pm uses a simple "name=value” per line format that I store in files in directories for specific users as a simple database. It’s still in use. It’s very fast, easy to work with, and very reliable.
But, CouchDB is a pretty giant upgrade by comparison so I'm using it with PouchDB.js for upgrades to that app now. I still use Perl and CGI.pm for server side chores though, like user setup, because it’s still a great server side tool. -- Bill Stephenson > On Jul 22, 2019, at 9:20 AM, Joel Wallis Jucá <joelwal...@gmail.com> wrote: > > Hello Rene, > > Have you ever tried YAML? If you're planning to manage the data manually > through a text editor, YAML will provide a DX (Developer Experience) way > better than JSON. It works great for simple websites (Jekyll uses something > similar, called Data Files <https://jekyllrb.com/docs/datafiles/>). > > Em dom, 21 de jul de 2019 às 18:00, Martin Broerse <martin.broe...@gmail.com> > escreveu: > >> Hi Rene, >> >> I actually don't see what you want advice on but I can say 2 things about >> it. >> >> - Use CouchDB with keys like >> `rss_2_YYYY-MM-DD-hh-mm-ss-CATEGORY_SUBMENU_PATH` or >> `rss_2_CATEGORY_SUBMENU_PATH-YYYY-MM-DD-hh-mm-ss` depending on what you >> want to find with mango queries and use as value your JSON data in a >> `data >> `root key. like this >> >> https://my.couchcluster.com/bloggr/post_2_9F4D597F-037B-0037-8F64-917B1DDBA611 >> to be able to switch to relational-pouch >> <https://github.com/pouchdb-community/relational-pouch> later. >> - Use a MIT, Apache or similar License but not GPL or LGPL if you want >> companies to use it. We have a policy at our company not to use and >> invest >> in GPL licensed code. >> >> Play with Mango queries direct from Fauxton to see the advantage of using >> rss_2_ like this >> >> ``` >> { >> "selector": { >> "data": { >> "key1": "s|string" >> }, >> "_id": { >> "$gt": "rss_2_", >> "$lt": "rss_3" >> } >> } >> } >> >> ``` >> >> - Martin >> >> On Sun, 21 Jul 2019 at 18:50, Rene Veerman <seductivea...@gmail.com> >> wrote: >> >>> Hi. >>> >>> I like JSON a lot better than the SQL data model, >>> but now that i've been using it for a few years, >>> i find myself combining file system storage of lots of JSON files in many >>> sub-folders into a web app, >>> like news gathering with commandline PHP per N minutes from 280+ RSS >> online >>> sources, >>> into a PHP web-app that loads the latest news, via a web-powered PHP >>> filesystem search of the latest new-items JSON files, stored on a >>> filesystem thats got folders like >>> ./YYYY/MM/DD/hh/mm/ss/CATEGORY_SUBMENU_PATH leading to JSON files. >>> >>> so now i want something more flexible. something that can give me a >>> web-based treeview of data spanning many JSON-like files (in more >>> complicated ways than my news app) and even into other file formats >> stored >>> somewhere on the filesystem of some server. >>> >>> i plan to license this right from the start under a LGPL typed license, >>> because i believe input from other developers is key to making a DB >> system >>> that is not only easy to use, but also very efficient to run. >>> >>> i'd like the code to stay pure PHP, not even using the object oriented >>> functionality of PHP, just plain properly named functions and their >> return >>> values. >>> >>> i'll name this DB architecture FolderDB, and to prevent web-apps from >>> forcing the server to reload (and decode!) many .jsone files upon a >> simple >>> request to change something in some referenced .jsone file, i plan to >> run a >>> single PHP server daemon that will respond to a yet to be written >>> ASCII/UNICODE protocol. >>> >>> the file format itself, has to differ from JSON somewhat i think, and i >>> also believe we can lose some of the overhead. >>> i post this all here to hear your opinion, especially when it points to >>> insurmountable problems related to my designs. >>> >>> i'm also interested to learn about how to add cloud redundancy to this DB >>> architecture, preferably with tiered backup servers, or at least be >>> prepared for such expansions of the DB architecture later on. >>> >>> here's the string based format that i came up with so far : >>> >>> JSON-Extended file format (ASCII / UNICODE) >>> >>> ------------------ >>> { >>> key1 : s|string value, >>> key2 : 2, >>> key3 : 3.4, >>> key4a : t, >>> key4b : f, >>> key5 : [ >>> numbered array >>> ], >>> key6 : { >>> named array >>> }, >>> key7 : url|/siteData/bla/bla/file.jsone, >>> key8 : key|key7/someKeyInsideFileBehindURLofKey7_key1/key1a, >>> key9 : >>> >>> >> url|/siteMedia/backgrounds/someFile.png||thumb|/siteMedia/backgrounds/thumbs/someFile.png, >>> key10 : >>> >>> >> url|/siteData/bla2/bla2a/file.odt||thumb|/siteData/bla2/bla2a/file.odt.thumb.png||thumbGenerator|URL >>> } >>> ------------------ >>> >>> key4a = true >>> key4b = false >>> >>> key1 would need it's value escaped, using \| and \, >>> >> > > > -- > Joel Wallis Jucá > about.me/joelwallis
