4 ms·
Databases only have a fraction of the capabilities of a spreadsheet. That's not a reasonable response. There’s nothing you can do in a spreadsheet that an RDBM
by EvanAnderson 4y ago
Databases only have a fraction of the capabilities of a spreadsheet. That's not a reasonable response.
There’s nothing you can do in a spreadsheet that an RDBMS can’t do.
Programmers often object to spreadsheets because they’re too “brittle”. I don’t think it’s an unreasonable objection.
Most spreadsheet users don’t exhibit the rigor necessary to impose a schema on their spreadsheet-based data, nor to use features like named ranges to abstract away the physical location of data in the spreadsheet from its semantic meaning. Data validation is an afterthought, too. Spreadsheets invite silent errors when rows or columns are inserted or removed, data is copied/pasted, etc. It takes more effort, in my experience, to keep the formulae in a spreadsheet working in the face of modifications versus a database.
A database explicitly separates the data from logic (at least, typically— getting into queries that act conditionally based kn queried data blurs that line a bit) and provides a strong schema and enforced validation at the time data is added or modified. You’re not going to get wrong answers from a database query because somebody added a row at the bottom of a range that isn’t covered by a SUM(), for example.
- beenpola 4y ago...I logged back into my lurker account just because of how annoying this was- I use Google Sheets all the time to do data visualization and analysis work because it just works, and because I can share my results with other people, and let them explore the data in a format that they understand. There's a reason lots of MBA types get issued high-performance, high RAM machines- because asking them to learn SQL or whatever AND asking them to learn how data structures and query syntax work instead of just doing things a little more slowly and throwing more performance at Excel makes a lot of sense. Not saying it's perfect, but please don't hate on Excel et al because they aren't the perfect world way of doing things.
- Dylan16807 4y agoAnd even if you do teach them proper database queries, that doesn't give you a nice editable view of multiple interlinked queries and parameters, with output organized into charts and graphs. The best option down that road isn't switching to a database program, it's using a spreadsheet program that can do SQL.
- EvanAnderson 4y agoSpreadsheets are great for ad hoc work. I think they’re intuitive and agile. I use them for that purpose too. All the time. Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings. In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers. Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases.
- Dylan16807 4y ago> Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings. > In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers. You shouldn't use a notepad of SQL statements for processes either! Once certain things are figured out and planned around for repeated use, they need to be transformed into a proper maintainable form, probably involving careful code with error detection. But that's not a spreadsheet vs. SQL issue. If SQL causes fewer problems it's probably because someone that knows SQL is more likely to have programming knowledge/discipline, not something about SQL itself. > Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases. It's great to use a JOIN when it's appropriate. But a lot of the time there's still no real need for a database, and you want all the other tools a spreadsheet has. Or there is a good case for a database, but the best answer is having some queries that feed the spreadsheet.