Bookmarking doesn’t work for me, too limited, and starts a horrible trend of duplicating them. So they are useless for tab history managment. Also, the linear tab history is not very useful… same problem, the entries get duped eventually. I often don’t want to restore the tabs from the last day whatever, but restore an specific set of tabs. Some times even multiple sets, and switch between these.
I really would like an Firefox feature, where the tabs would be part of a “tab history tree”. Opening a link in a tab would add it as a “sub-tab” of the parent tab. In history.
So when a doing a search or refining one many times, this would end-up linking all the opened tabs to the originating tab. A new tree of tabs could be started by just opening an empty tab, and a “tab organizer UI” should allow to move/group that into an existing tab tree if needed. (The tab-bar UI doesn’t need to visualize the tree-of-tabs. The tabs would be just auto-organized this way in the history)
I think this would allow to clear all of the currently open tabs in any window, but the tabs could still be neatly restored from the history on per-tree basis in any window. Restoring a tab-tree would allow to continue making refinements to it, or clone it. Currently multi-window tab restoring in FF is kinda borked, and only the last window’s open tabs are restored automatically.
It’s normal to denormalize data in a relational database. Having a lot of joins can be expensive and non-performant. So it makes sense to use a common structure like JSON for storing the demoralized data. It’s concise, and still human readable and human writable.
Why should I spin up a NoSQL solution when 99% of my data is relational?
Having a lot of joins can be expensive and non-performant.
Only if you don’t know how to do indexing properly. Normalized data is more performant (less duplication of data, less memory and bandwidth is being used) if you know how to index.
It may have been true decades ago that denormalized tables were more performant, I don’t know. But today it’s far more common that the phrase “denormalized tables are more performant” is something that’s said by someone that sucks at indexing and/or is just being lazy.
But I do put JSON into tables sometimes when the data is going to be very inconsistent between different items and there’s no need to index any of the values in there. Like if different vendors provide different kinds of information about their products, I need to store it somewhere, so just serialize it and put it in there to be read by a program that has abstraction layers to deal with it. It’s never going to perform well if I do a query on it, but if all that’s needed is to display details on one item at a time, it’s fine.
Want to fetch a page of posts AND their tags in normalized SQL? Either do a left join and repeat all the post values for every tag or do two round-trip queries and manually join them in code.
If you have the tags in a JSON blob on the post object, you just fetch and decide that.
The alternative is not super exciting though. My experience with NoSQL has been pretty shit so far. Might change this year as the company I’m at has a perfect case for migrating to NoSQL but I’ve been waiting for over a year for things to move forward…
Also, I had a few cases where storing JSON was super appropriate : we had a form and we wanted to store the answers. It made no sense to create tables and shit, since the form itself could change over time! Having JSON was an elegant way to store the answers. Being able to actually query the JSON via Oracle SQL was like dark magic, and my instincts were all screaming at the obvious trap, but I was rather impressed by the ability.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.