On Mon, 13 Jan 2020 10:37:57 -0800 Jens Alfke <j...@mooseyard.com> wrote:
> > On Jan 12, 2020, at 4:12 PM, James K. Lowden > > <jklow...@schemamania.org> wrote: > > > > What is the motivation behind this advice? It's completely > > unnecessary. > > Thanks for your opinion, James! I disagree. > ... > IMHO there are too many of them to do the usual SQL thing > and add every header of every message to a table ? that multiples the > number of inserts and deletes by an order of magnitude. Hi Jens, I asked for your rationale; thanks for your answer. So, basically, a nomalized design requires too much use of INSERT? You're making an efficiency argument here, or maybe ease-of-implementation assertion. For me, inserting one header row or 20 is the same coding effort (still need a loop). I think transaction throughput would be about the same if COMMIT is applied only to whole messages. The OP wanted some basic design advice; he didn't say a simple, straightforward design was too much work or too slow. He in fact said, > > > local small NNTP server Given that, ISTM that textbook SQL 101 advice is in order. JSON should wait until your assumptions are tested. > > For all the complexity JSON adds to the design, it adds exactly no > > power: precisely the same effects can be achieved without it. > > Well sure, but you could say the same thing about indexes, couldn't > you? No. Perhaps I should have been more explicit about what "complexity" I was talking about. I'm saying you've added a user-visible aspect, JSON, to the logical database design for him to cope with, but in no way made the database capable of representing something it otherwise couldn't. Indexes are the opposite: invisible affordances that don't affect the database's logical design. > Encoding headers as JSON is pretty simple if you've got a JSON > encoder handy Perhaps. It's still introducing an extraneous technology to the user's problem domain. > > I see no advantage to introducing JSON to a system with no external > > use for it. > > Hm, a number of database companies (such as my employer, Couchbase) > and their customers would disagree with you :) Please don't take this personally, because I don't intend insult. For years I worked on databases before Couchbase existed, and for which using Couchbase even today would be considered a joke. DBMSs are used for all kinds of purposes by people well trained and not, to good effect and bad. The number who don't understand the basic theory of what they're working with far exceeds those that do. Half of them are below average, and the average isn't very high. I'm sure you'll understand if popular opinion doesn't impress me. I get why you would do it your way. In your estimation, given your particular skills, you feel it would be easier to use the JSON API. I didn't want to leave unchallenged the impression "6 one, half-dozen the other" impression that bring that into the mix is just a matter of taste. Simpler systems are better, I'm sure you'd agree. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
