Okay, invoking Word vs LaTex automatically makes your argument a straw man. I would have compared word to e.g. Adobe InDesign.
It has been my experience that while almost everybody can create a passable document in Word, something technical/government-ish with 500 pages and all of the publishing accouterments that come with a document of size, purpose, and complexity, you're getting into specialist territory, and almost all of the DTP specialists I know start by importing Word files in to InDesign.
"It should be something that any clerk can handle and that doesn't become obsolete."
This is an important statement. in that it is a reasonable goal, but nearly impossible.
Even using word, once one gets past a simple document, and starts having TOC, index, etc. and is "four five-inch binders" full of pages, then not just ANY CLERK will be able to maintain the document.
I had a class called "Introduction to file processing" that was basically "here's how you manage your data files," and taought us about the evolution from sequential access, to ISAM, to VSAM. Ended up working in RDMBS/SQL but it was a fascinating class - despite the assignments being in FORTRAN.
You appear to be assuming that the limit is applied while fetching tuples, rather than while filtering the tuple set after fetch.
It occurs to me that if you handle LIMIT during fetch, you'll add complexity the fetch, and might only see run time gains in the cases where the number of desired rows is small.
If a column contains unique data it should be marked as such in whatever way your RDBMS requires (e.g. UNIQUE constraint and/or UNIQUE index)
flash cookies are less well known to people. Even the casual "privacy conscious" web user tend to be unaware that flash drop its own flash cookies that don't clear with the browsers "clear cookies" function.
No. Without any indication that the value in that column is unique the query engine must read the entire table in order to insure that it has found every row that meets the search criteria.
I'm not familiar with the volume of data that balance collected at signup. But I am familiar with the volume of info in the PCI's "Know Your Customer" initiative. I i'm going to speculate wildly that balanced got to know their customers during onboarding, rather than waiting until after they started processing payments.
Additionally, I think that a company's level of trust with their customers involves some 'coefficient of risk' regarding potential losses to chargebacks against a low or non-existent reserve. I find the topic interesting, especially the consequences at a federal level if you guess wrong and the "customer" turns out to be laundering money.
Probably by becoming a highly-trusted, low-risk customer. Payment balance float is all about holding some money in reserve in case of chargebacks. The better your stats are, the less money a processor will insist on holding in reserve.