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

A database for 2022

tailscale.com

Post reply on HN
Print view View original

271–280 of 336 posts

Re: A database for 2022

#271

Post by pphysch »

klysm wrote: post #264
unfocussed_mike wrote: post #218

Earlier quoted context omitted.

Yep. IMHO MySQL becoming boring (fast, pretty reliable, non-compliant quirks being ironed out, decent backup tool availability, credible admin tools, JSON and CTE support) is one of the most important long term trends on the internet. Along with the parallel evolution of PHP.

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy.

All the PHP+MySQL I've worked with has been horribly bespoke and brittle.

Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver.

Want to refactor the database schema? Difficulty: Impossible, because raw SQL strings are scattered everywhere, including on other systems.

Want to add/modify a new internal CRUD form? Gonna be several hours of work to RE what the last guy did to keep things consistent, while tiptoeing into the SQL to not break anything. With a proper framework, this is a 5 minute task and a few LOC into the "admin interface".

It works, and you can do a lot with just a few php files and a basic Linux system, but there are downsides.

Re: A database for 2022

#272

Post by stavros »

0des wrote: post #152
reilly3000 wrote: post #146

Earlier quoted context omitted.

If anything, this ^^^ is how you win the long game. History will surface itself when you make assertions. Gracefully revocability scales.

At least he's not the Dropbox guy

The Dropbox guy admitted he was wrong too, but we won't let him live it down. At least we don't remember his name.

Re: A database for 2022

#273

Post by stavros »

0des wrote: post #268
ignoramous wrote: post #198

Earlier quoted context omitted.

to quote u/InGoodFaith (news.ycombinator.com/item?id=29555814): > Wouldn't also be HN without the misinterpretation of BrandonM's response. Here is dang's comment about that topic/meme: https://news.ycombinator.com/item?id=29178442

As someone who was there to witness it when it happened, that is not the impression I got at all, and I think Dang may have taken the more humble interpretation in that remark.

You don't need to have been there, though, as anyone can read the perfectly-preserved exchange even now.

Re: A database for 2022

#276

Post by isbvhodnvemrwvn »

dangoor wrote: post #249
isbvhodnvemrwvn wrote: post #203

Earlier quoted context omitted.

Not quite, I got bitten by weak type system more than once.

Enough people have had this complaint that sqlite has added STRICT tables: https://www.sqlite.org/stricttables.html

Oh, finally! I haven't heard about it. Thank you!

Re: A database for 2022

#277

Post by lillecarl »

eyelidlessness wrote: post #88
brycelarkin wrote: post #43

It looks like you guys use AWS. Why not just use RDS if you don’t want to deal with database management?

Disclaimer: I hate doing ops, but I’ve been in a position to actively hate doing it fairly regularly for several years of my career. My perspective is as a person who doesn’t want to deal with any of this kind of stuff. So I’ve probably failed to acquire knowledge which would make it less frictionful for me, purely from lack of interest. RDS has some significant downsides which I would personally consider no go if I…

Idk, I just use the Terraform module and set the Helm values on whatever should consume the db with whatever I get back from the module then call it a day. Then again, I'm not scaling big at all.

Re: A database for 2022

#278

Post by reilly3000 »

belter wrote: post #269
emteycz wrote: post #236

Earlier quoted context omitted.

Why can't a company use cloud? It's not like there's Amazonbox client I could install now and get the same service. Dropbox never was about the storage itself, IMHO - it was about the ease of usage. There were enough options to get storage - cloud or non-cloud - when it came out, but none of them had the easy folder-based sync and sharing (public folder) of Dropbox.

It's not if the company uses cloud or not. It's if they are solving the hard problems or instead, outsourcing the technical challenges to their cloud provider while charging the user a non justifiable premium for the intuitive user interface :-) So it's about the eventual value add and the business case. The challenging part is to provide the back-end. Get massive storage, with proper checksum integrity, at a cost ef…

And for what its worth, systems like minio have emerged due to that commercial innovation. AWS has made a lot of investment in that system and will earn perpetual annuities from it, but by creating a defacto protocol we now get many choices that use its API. Its interesting because AWS never was benevolent with their S3 code, they just created a novel and rigorous offering that became worthy of emulation. Dropbox really hasn't done any equivalent contribution. If anything, the open source projects that have emerged to offer self-hosted alternatives to it are more feature-complete and extensible- such as nextcloud/owncloud, pydio, syncthing, etc.

side note: I'm filled with regret for every document that I authored on Dropbox Paper. It didn't last for long, but there was a time that it was the official wiki for a company I worked at. Its not impossible to export, but never with full-fidelity.

Re: A database for 2022

#279

Post by stavros »

I love this. If it works, keep it until shortly before it stops working. The older I get the more love I have for simple solutions that are easy to work with (and change when you've grown out of them).

These days I wince when I hear of overcomplicated solutions for an MVP that "will scale" at a nebulous point in the future, while we're going to be paying the complexity penalty every day for a benefit that may never come.

Re: A database for 2022

#280

Post by tptacek »

jeffffff wrote: post #265
tptacek wrote: post #158

Earlier quoted context omitted.

You should start by learning more about the product, and then tell them they should use Aurora for all their backing store.

Quoted post unavailable.

You don't know what this database is --- upthread, you said you don't even know what the product is. All you appear to know is that they should be using something like RDS. Isn't that a weird position to take?
Post reply on HN