carlps

I'm not intimately familiar with either side, but I see it as: - Costco buys x amount of product at y price from seller and then sells it in its store. - Amazon provides a platform for sellers to sell with a cut going back to Amazon.

There is a fundamental difference between being a retailer and providing a retail platform.

All Costco would really have access to is how much they've bought and how that has performed for them. Meanwhile Amazon is providing a platform for companies with a policy that they will only use their data to help them, which is what is allegedly not happening.

I don't think anyone is going to argue with making complicated things simple. But from my experience, if it's complicated in SQL it's going to be a nightmare in the ORM. Generally, complicated SQL means that the underlying data was not modeled to solve the use case. Exactly as you mentioned, trying to simplify things in the ORM layer will be on a use case by use case level.

> And I don’t think the consumers of the GraphQL API should think about efficiency. They should just specify what data they need and then the backend is responsible for figuring out how to query the data model efficiently.

That is the point of the SQL language. It's declarative. You define what you want your data to look like and the query planner handles the actual fetching of the information in the most efficient way it can. Obviously it's not perfect and you still have to have someone who knows what they're doing to define schemas that make sense and indexes where appropriate, but that is a separate job from defining what data is needed.

No, I don't think it is. Early itunes was a media player and music store I could use to catalog my own music as well as license theirs. Spotify is a streaming music service with a free ads based model or paid monthly subscription to get access to most commercially released music. How is that anything like Pitch vs PowerPoint templates?

I'm curious how the model handles text data. Does it use the actual input text from the source db to generate new synthetic data? If I have a column of a bunch of sensitive text that I need sanitized, how will that appear in the output? What is the risk of leaking something sensitive?

The cons are inumerable. We've been down that road before and the whole world of business intelligence and enterprise data warehousing came out of it. When every functional unit has their own db, how do you answer questions of the business as a whole? How do you deal with data that multiple functional areas need? On top of that, managing a lot of small silos requires a lot more work and resources then the alternative.

Eventually you're going to want to bring that data all together and now you have to have data architects and engineers developing etl solutions and then your resulting data warehouse is going to be that singular database you were trying to avoid from the start, with all the overhead of building it and maintaining it on top of all the maintenance of the source silos.

See https://en.wikipedia.org/wiki/Data_warehouse

There's something beautiful about normalizing the storage of denormalized schemas.

I have a very similar background. My degrees are in Business Computer Systems and we had SQL hammered into us. We learned how to program with Java and .NET, but all from a very high level. It wasn't until a couple years into my career after school that I started learning DS+A fundamentals on my own. It blew my mind. I agree that there should be more of a mid-point available.

I think the excel issue is a problem with excel, not csv. Why can't excel preserve the format of the file?

Except the inaudible sounds are used for marketing purposes. Most companies aren't going to want to just close that door.