Most of what people in the real world are doing with spreadsheets would be better done with a database, but spreadsheets are more approachable so they use them instead. Making SQL a requirement for MBA programs would make business much better in the long run. (there are more things a MBA program could teach than there is time so I'm not advocating that they actually do this)
I’ve often wondered if just being able to change the “type” that applies to rows within a spreadsheet would be useful.
A general use string type being the current default, there’d be lots of benefited use cases to locking down rows (heading rows aside) as having to be safe format, or a number etc.
In Excel have you tried selecting a row and select the Text or the Number type from the ribbon "Types" drop-down (oddly named the "Number" section of the Home ribbon tab because it was classically the "Number" tab of the Format Cells dialog, which still exists if you click the expando button on the ribbon section)? (I find it easier to select columns and set types by columns, but I don't know what your spreadsheets look like.) It doesn't "lock" the type and an editor can still change the type for an individual cell, but you can still set (and save) better default expectations.
(Text is the safe string format that isn't as "magic" as General, the default. It's also the type you get if you use the " prefix in General.)
It's interesting to note here that the weird "magic" of Excel's default General "type" is pretty directly VisiCalc's fault because they had similar types but wanted to keep entry "simple" and decided to just guess types as people wrote cells with a handful of special character prefixes to override types. That legacy will likely forever live on. Excel could name General "VisiCalc Backward Compatibility" and it wouldn't entirely be wrong.
My experience has been that teaching MBAs SQL just leads to MBAs desiring to execute Access-designed SQL statements (with horrifying execution plans) on Production database servers and expect to see the results in Access. That way lies its own madness.
They are different tools. Spreadsheets allow for much faster iteration than SQL.
Following some strict "best practices" when using spreadsheets gets you 80% of the way there. The other 20% is functionality that doesn't exist yet, but can be done.
For sure, but business runs on spreadsheets and most of them are places where SQL is clearly a better fit. Complex iteration is faster in SQL as well, though for simple problem sets spreadsheets are faster.
