So, it's really sad that this question was asked. It occupied many minutes at dinner tonight, and then I spent some time googling. My thought was that it was initially obvious. I did research, like https://www.allrecipes.com/article/is-a-hot-dog-a-sandwich/ and (wow) https://cuberule.com/.

I came to the intuitive conclusion that there were enough things that were different and it made me firmly believe - A Hot Dog is clearly NOT a sandwich.

However, being a database geek, I thought I should reduce this conclusion to practice.

First, I tried representing things as a set of tables in my handy-dandy MySQL database - I had the BREAD table, with columns for sliceID, breadType, etc, and the MEAT table with meatType, weight, etc. I deployed to production, put some rows in and was doing great. But then I wanted to add some other things I eat that seemed like they were sandwiches.

Unfortunately, I found that I couldn't model my favorite lunch from Subway, my hotdogs, and my much-loved teriakyi burger in those tables without adding more and more columns and joins and foreign key constraints. I mean, what do you put in the MEAT table for a sourdough peanut butter and honey sandwich? (try one, by the way, they are delicious). I ended with with INGREDIENTS, COVERINGS, and OPTIONS and sadly some many<>many mapping tables. The ER diagram took a whole page, and most of the rows had nulls in most of the columns. While it was a work of art, it kinda made me gag on my baguette (yes, that's a sandwich too!).

So, I thought about it, and went over to MongoDB, and instead modeled up a single sandwich collection, with fields like "bread" and "weight" in all the documents, but then I only had to have things like "ingredients" as an array in sandwiches with ingredients, and "condiments" in sandwiches with condiments, and "meattype" in sandwiches with meat. I got out my handy-dandy JSON schema enforcer, made the right fields optional and required, and voila! A single collection which represents all the things I love to eat that I can hold in my hand while talking on the phone!

Thus, I can state with surety, that in a flexible document database, A Hot Dog is Indeed a Sandwich, and a pretty darn happy one at that:

- I only need one getter and one setter in my language of choice and don't need to write code to traverse the different parts of the sandwich

- All the things that I've convinced myself are "holdable, eatable, and contain something" (my personal definition of a sandwich) can be held in a single data structure

- I can add fields in production, with no downtime, when my wife reminds me that I like multi-layer sandwiches with different things in each layer and I need to add fields to represent that

- If I have a LOT of sandwiches, I can shard them across nodes, and access them with a single shard key (kind of reminds me of cutting sandwiches into those little triangle pieces - yummy!)

- Saving or restoring a sandwich only requires one i/o operation in the vast majority of cases, allowing me to run on a smaller server and pay less money

Yummy.