Hacker Newsnew | past | comments | ask | show | jobs | submit | gustavoamigo's commentslogin

From what you are saying, it was not a rescue mission then? But Trump administration is trying to frame as it were. Is that it?


The Crew-10 was not a rescue mission because they just rotated with Crew-9 which carried the Starliner Astronauts back. Crew-9 could be called a rescue mission because they took back the Starliner Astronauts. But Rescue makes it sound more urgent and dedicated than it actually is. They would have flown anyways, just with more crew.


That is exactly what it is. That mission has been scheduled for more than 6 months (though the exact date changed a couple of times for technical reasons).


The decision to make this political and partisan came from the Trump administration, the response to that is obviously political and it is natural that it would come from someone that is not a Trump supporter.


I agree with start with a monolith and a shared database. I’ve done that in the past quite successfully. I would just add that if scaling becomes an issue, I wouldn’t consider sharding my first option, it’s more of a last resort. I would prefer scaling vertically the shared database and optimizing it as much as possible. Also, another strategy I’ve adopted was avoiding doing `JOIN` or `ORDER BY`, as they stress your database precious CPU and IO. `JOIN` also adds coupling between tables, which I find hard to refactor once done.


I don't understand how do you avoid JOIN and ORDER BY?

Well, with ORDER BY, if your result set is not huge, sure, you can just sort it on the client side. Although sorting 100 rows on database side isn't expensive. But if you need, say, latest 500 records out of million (very frequent use-case), you have to sort it on the database side. Also with proper indices, database sometimes can avoid any explicit sort.

Do you just prefer to duplicate everything in every table instead of JOINing them? I did some denormalization to improve performance, but that was more like the last thing I would do, if there's no other recourse, because it makes it very possible that database will contain logically inconsistent data and it causes lots of headache. Fixing bugs in software is easier. Fixing bugs in data is hard and requires lots of analytic work and sometimes manual work.


I think a better maxim would be to never have an un-indexed ORDER BY or JOIN.

A big part of what many "nosql" databases that prioritize scale are doing is simply preventing you from ever running an adhoc un-indexed query.


Creating a startup is a huge risk taking endeavour, if there are factors in your life that might distract you from this like how you are going to pay mortgage or will I have time to be with my kids/wife, probably you shouldn't do it. Also, keep in mind that there are few possible outcomes to a startup - 1) it succeeds and you get rich, 2) it fails miserably and you are left with a huge debt that you might never be able to pay in a lifetime (this risk is real, I've seen it), 3) it fails, but you get away no debt, 4) it kind of succeeds, but it becomes a boring existential company that barely pays your bills and no one is interested in buying it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: