I'm certainly no Drupal expert, but I've schemed and built a few databases before, so am puzzled by the structure of a database a 3rd party team is working on that I had Sequel Pro'd into to add some dummy content. I presume the structure wouldn't be apparent if one were to use Drupal's back end GUI, but I don't have creds, just ftp, and ssh access.
I was a bit horrified to see not the single table I would have expected for, say, an Organization, with columns for ID, Name, Address, Email, Zip Code, etc. etc.
Instead, there is a table for each bit of data. That is, a separate table for Name, for Address, for Email, for Zip Code, etc. etc.
That seems, from a logical standpoint, amazingly inefficient. E.g., when an Organization page loads, each bit of data that loads for that org is called from a different table and aggregated, rather than by way of a call to a single table, and all data pulled from one row.
Am I clueless (yes but...) or is this some db structure peculiarity unique to Drupal?
Yes. Drupal stores field content in individual tables so that it will be maximally flexible (for example, if you wanted to re-use those fields on other content types besides "organization" later), it is already in a multi-join table. The tradeoff is performance, which Drupal makes up for with caching and such (for example when that Organization node is loaded, it caches it so that if it's loaded again in that page request it doesn't need to read from those tables again, for example). Since it's a powerful CMS that lets you build and re-build and reorganize how you store your content and fields, it stores the data more flexibly.