quizotic · HackerTrans

quizotic

no profile record

Submissions

Ask HN: What Happened to Sqlfiddle?

1 pointsby quizotic6 anni fa2 comments

comments

6 anni fadiscuss

Thank you for the pointer to DB fiddle!

6 anni fadiscuss

Bridgewater is famous for valuing a culture of almost brutal honesty and fierce internecine warring over ideas. It argues this combination is vital to reaching the deep understanding that is critical to the success of its investments. While Bridgewater has experimented with leadership transitions multiple times, changing directions and reversing course seems consistent and faithful to its internal DNA. Life doesn't always go in neat straight lines. Forcing a simple story line isn't always best.

7 anni fadiscuss

This seems so much more clear to read, with less typing.

7 anni fadiscuss

Do you do that by memory? Or do you have some text indexing tool that helps?

7 anni fadiscuss

This is Dan Abadi we're talking about. More importantly, the points he makes are important, clear and true. If that causes heartburn for Vendor A and pride for Vendor B, that's secondary. The primary goal is to help users of distributed database systems understand the kind of trouble they can encounter with anything less than strict serializability.

NB: there are important applications where correctness in specific situations is not paramount. Double-click and ad-serving companies in general are more concerned about speed and throughput and are generally willing to have approximate correctness. Strict serializability isn't a universal value, but it's good to know about when you DO care about the kinds of anomalies Dan illustrates.

7 anni fadiscuss

Does anyone remember Larry Harris and "Natural" back in the 1980s?

7 anni fadiscuss

The only problem with singular nouns for table names is that they occasionally conflict with SQL keywords. The canonical example of this is from the TPC-H benchmark which has tables named REGION, NATION, SUPPLIER, CUSTOMER, PART, PARTSUPP, LINEITEM ... AND ORDERS <- plural because ORDER is a SQL keyword.

I like the singular guidance for all the reasons given. I like the consistency guidance. But the real world sometimes gets in the way.

7 anni fadiscuss

So true. And so deliciously snarky. Confession: I'm guilty of far greater stupidity. I've asked "Ship of Theseus" questions when interviewing candidates for object database companies, and conservation puzzles, like tessellating a chessboard missing diagonal corners with dominoes. Because "Thank goodness I hired coders who can discuss philosophical identity problems". At least people who can reverse a b tree on a whiteboard can code an algorithm.

7 anni fadiscuss

Don't C++ 20 modules solve this problem?

7 anni fadiscuss

Do you have any insight into the reason for the unequal access? Is it that poorer or uninsured patients cannot afford non-emergency healthcare? Is it that they are too far away? Is it education/knowledge/social - belief that they shouldn't go to a doctor for "nothing". Are they "too busy".

Also, are there any studies to show that populations in other countries use their medical systems more frequently across the board, or that they use more frequent preventative visits?

You mention the problem with obesity and its co-morbidities. Are there any studies or plots that show health outcomes (lifespan, infant mortality, maternal mortality) as a function of % of population who are obese? I wonder if poor health is linearly correlated with obesity, without regard to healthcare spending...

7 anni fadiscuss

Agree you need all of these things and more... but if you could do this above the microservice level, as a piece of K8S or whatever the MSA, then you might have an advance over RDBMS.

The result would be the same features/guaranteed you have with current DBMS, but you get independent deployability, elastic scalability, redundant availability, and other advantages of microservices that are missing with traditional DBMS.

7 anni fadiscuss

If you never need to coordinate two or more microservices, then sure. But that means you're dealing with a monolith. In the original article, you could combine Orders and Users into a single microservice. That would resolve all the issues that are raised ... except that you might want reference the Users in a different context. At that point, you either have to split Users into their own microservice, or duplicate the User information. Either way, you're backed into consistency issues.

Part of the promise of microservice is that they're small modular independent components that you can connect and combine into higher-level services.

If you need to read information and write information to two or more microservices, then you have transaction issues. If you need to relate information across two microservices, you have reference integrity issues. Just comes with the terrain.

7 anni fadiscuss

There's a bit of an emperor's clothes problem with microservices. If microservices are never combined together, they are essentially monoliths under a cooler name. But as soon as you combine them, you run into the same problems that are solved by traditional shared database systems. Here are two: cross-microservice referential integrity, and cross-microservice transaction coordination, but there are plenty more.

Take the Orders/Customers example of the article. Assume the Customers microservice has some notion of identity, and that the Orders microservice contains a "foreign" reference to Customers identity. If the microservices are truly independent and autonomous, then the Customer microservice should be able to change its scheme for Customer identities, or a delete a Customer. But then what happens to the Orders that reference that now old and outdated Customer identity? If changing the Customer microservice breaks the Orders microservice, then what's the point of the separate encapsulation? Traditional shared database systems have ways to deal with this kind of referential integrity. As far as I can tell, this issue is ignored by microservice architectures. As is the larger issue of cross-microservice constraints (of which referential integrity is just one instance).

The thing that really gets my goat is the lack of cross-microservice transaction coordination. In its place, we get all sorts of hand-waving about "eventual consistency" and "compensating transactions". Growl. Eventual consistency has a meaning that's related to distributed/replicated storage and the CAP theorem. Maybe its principles can apply to microservices, but the onus is on the microservice proponents to actually connect those dots. And most importantly, eventual consistency is implemented and supported by the DBMS, not by application developers. The thought that each microservice will independently implement the transactional guarantees of consistency and isolation should fill everyone with dread. That job should belong to the overarching system, not to individual microservices. It's too hard to get right.

So for now, shared database in microservicew is not an anti-pattern. It may be the only workable pattern. When microservice frameworks grow up and offer the capabilities of shared database systems to microservice developers, then we can talk about anti-patterns.

8 anni fadiscuss

Is there any protection to be had by a corporate shell game? Suppose I put my technology assets in one corporation, my revenue and monetary assets in a 2nd corporation, and my customer facing presence in a 3rd corporation. The patent trolls descend on the customer facing presence, which has no substantial technology or monetary assets. If it goes into bankruptcy, I lose brand, but can restart elsewhere and preserve my tech and monetary assets ?

8 anni fadiscuss

Not getting this at all! How does it help find competitive websites?

8 anni fadiscuss

So I just had an experience of being forced into "vertical slice" development (not quite the same as architecture, but still). This seemed initially as crazy as erecting a multi-story building in vertical slices. But it turned out to have some advantages, and I might do it again by choice.

At the risk of stating the obvious, at the end of the day, it's the use cases and user stories that matter, and in my experience, these almost always evolve over the life of a project. Designing from the ground up often ends up supporting potential requirements that never become real. As the project grows and matures, it becomes hard to trace whether some capability in a lower layer is critical or unneeded, so the tendency is to keep everything. This can become an albatross.

The virtue of vertical development, is that it's easier to do all the work and only the work that is required.

Theoretically, the flip side is that it's easy to avoid thinking up front about the big picture, and easy to promote stove-piping with all of its disadvantages.

My guess is that either the traditional or the vertical approach involves eventual refactoring, and that the first leads to bloat in unused capability while the second leads to bloat in duplicated capability. But the bloat comes later in the project with the vertical approach. In the early phases of a project, the vertical approach may lead to leaner, more malleable systems, with faster delivery and user interaction.

Bottom line for me, is that vertical development didn't fail (I thought it would), and had some surprising benefits.

8 anni fadiscuss

Glad to hear about the FDWs ... but wouldn't foreign keys be your friend here? What else would you need, really, to layer this on an existing DB?

8 anni fadiscuss

Well ... I kinda like the query syntax's ability to traverse relationships, nest objects/sub-headings, and apply filters at the level of projected expressions!

This has been done before of course, but I'm not sure I've seen this combination of syntax on an RDB before. It's certainly easier to read and write that a bunch of outer joins.

What would be nice to know is whether this can work on top of an existing PG database, providing easier syntax.

While their last example makes _sense_:

  open_prs := User.<assignee[IS PullRequest] {  
      title
  } FILTER .status = 'Open'

I don't find it easy to read/understand. If the [bracketed expression] acts as a filter, why not:

  open_prs := User.<assignee[IS PullRequest AND 
                            .status='open'].title

which preserves the nice dot-chaining for link traversal.

8 anni fadiscuss

404?

9 anni fadiscuss

Beautiful. Data Flow + Functional. Love the idea and can't wait to try it out!