Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental database programming

sqlsync.dev

Post reply on HN
Print view View original

261–270 of 310 posts

Re: Accidental database programming

#261

Post by paulryanrogers »

lmm wrote: post #241
holoduke wrote: post #231

Earlier quoted context omitted.

What is exactly hard about sql? Every dev imho should know it. And sql syntax is good and proven too be long lasting. Maybe investing some time in actually learning it instead of bashing it will help you further.

> What is exactly hard about sql? - No non-nullable types (at the expression level). No way to express e.g. normal boolean logic - No real data structures (at the expression level), unless you count rows, which are not first-class values. Even collections aren't first-class - Very awkward control flow constructs. E.g. look at how you write recursive queries. Even if/else is weird. It's a classical Turing Tarpit: ever…

> no string concatenation operator

`||` is the SQL standard. IMO its biggest deficiency is a single NULL nullifies the whole thing. But at least that's consistent with how NULL behaves in many other cases.

Re: Accidental database programming

#262

Post by BackBlast »

presidentender wrote: post #226
BackBlast wrote: post #209

Earlier quoted context omitted.

So if the user owns all their own data, their "data view" is their data set. A To-Do system, a personal finance app, any kind of note-taking or personal record keeping fits this model. You create a database per user and the auth and sync are all self contained within that database. This system is multi-master, which means that any change on a client or on the server will be replicated to every other. There is no "aut…

Correct me if I'm wrong: we can avoid the idea of a master for this use case because we suppose that only a single client (also server, I guess) will write at a time?

One user can have multiple clients. This is frequently the case, many to most users have both a PC and a phone. Also when one allows reasonable sharing of the account with family, 5+ connected clients is common.

Re: Accidental database programming

#263

Post by BackBlast »

ako wrote: post #232
BackBlast wrote: post #209

Earlier quoted context omitted.

So if the user owns all their own data, their "data view" is their data set. A To-Do system, a personal finance app, any kind of note-taking or personal record keeping fits this model. You create a database per user and the auth and sync are all self contained within that database. This system is multi-master, which means that any change on a client or on the server will be replicated to every other. There is no "aut…

> When you want to create a set of data that crosses user boundaries, it gets complicated. So it sounds like this excludes most enterprise use cases?

If I'm generalizing. B2C products frequently fit but not always. B2B products generally don't but can in some circumstances.

Re: Accidental database programming

#265

Post by BackBlast »

asaddhamani wrote: post #221
BackBlast wrote: post #139

Earlier quoted context omitted.

I find that moving the full query system into the front end is where most front end devs really want to be. They want a full power query system for the data instead of continuous rounds of re-inventing the transport layer, REST, GraphQL, *RPC, etc. It's hard to adopt such a system in most traditional web shops with their specialized backend and frontend teams. You're pulling out the database, backend, transport, and…

Reminds me of Meteorjs. It would let you sync a subset of your data to the client and then the client could query it any which way it wanted. They called this “Minimongo”.

I've used Meteor. I thought it was a good system. It didn't have offline capability, at least not back when I used it. It really needed to be connected to work. But conceptually, yes, it had a very similar system.

Re: Accidental database programming

#266

Post by ok_dad »

Terr_ wrote: post #172
pdonis wrote: post #144

Earlier quoted context omitted.

What many people either can't or don't want to acknowledge is that ultimately whether or not you support live updates in parallel by multiple users, instead of locking so only one update can proceed at a time, is not a technical decision, it's a business decision: do the business rules that are appropriate for your application enable you to deal with concurrent live updates or not? Ultimately that comes down to wheth…

Indeed, many of the most painful technical problems are actually three business problems in a trenchcoat.

This is one of those phrases that should turn into a saying, and be passed around for hundreds of years.

Every hard problem I have today in my career involves getting business people to define their business problem properly in order to solve it with technology. Even the hardest code I've ever written was easy compared to some projects, simply due to the business issues lurking around the project. Last week I finished a script to download a CSV and save it to a SQL table (literally) that took 3 weeks because business folks couldn't get their act together on what they wanted. I finished another project in a few days which is currently the core of a previous employers energy efficiency controls product which was easy because the person defining it did it very well, and I had no questions, just work to perform.

Re: Accidental database programming

#268

Post by dustingetz »

theamk wrote: post #173
threatofrain wrote: post #85

Earlier quoted context omitted.

This isn't a problem of only websites. Should mobile and desktop ecosystems start making a big move for thin-client like the browser? Should a simple app like Apple Reminders or Google Tasks have the GUI pause if there are delays or connection issues?

> Should a simple app like Apple Reminders or Google Tasks have the GUI pause if there are delays or connection issues? Yes, they should, because I _need_ good feedback for connection issues. I have not used those two specific apps, but for other "online first" apps it's such a common problem. Open an app, type a note, switch back to a different app (or turn off your phone, or close laptop lid). Later on, you want to…

"design-by-PM"

Re: Accidental database programming

#269

Post by carlsverre »

superfrank wrote: post #220
duck wrote: post #216

Off-topic, but was these diagrams created by hand or is there an app that will make hand-drawn diagrams like this?

I don't know what program the author used, but I'd be surprised if he did them by hand. Excalidraw ( https://excalidraw.com/ ) will give a very similar feel.

Yup, I used excalidraw!

Re: Accidental database programming

#270

Post by cratermoon »

jchw wrote: post #201
cratermoon wrote: post #198

Earlier quoted context omitted.

Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum?

> Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum? This sounds like the set up for a "No? Me neither." punchline. Certainly one of the features of Flash is that it gave you fairly good consistency across computers, but honestly my perception of Flash wasn't that it was going to solve some grand web problem, but more "oooh look, shiny rollover buttons!" and…

> "oooh look, shiny rollover buttons!"

That's the interactivity aspect. At the time, it was the bees knees of UI capabilities.

Post reply on HN