The next generation of spreadsheets will be a database
infoworld.com
infoworld.com
Really, I think it misses the point. Databases are about storing data, and admit a wide array of front ends, and there are plenty of tools now to use spreadsheets as a front-end for databases (most spreadsheets have basic tools for this built in, and more advanced ones are available.)
Spreadsheets are about viewing/manipulating data, and can both natively store data (in what is, necessarily, a database, though perhaps not a relational one) or connect to foreign sources for it.
"The next generation of spreadsheets will be a database" is a silly statement, for that reason: its possible the next generation of spreadsheets may have a particular kind of database (say, relational) as a native, internal storage system and expose tools for working with it. Or the next popular database front end -- the next Access -- may be a general purpose spreadsheet with the right tools.
And maybe spreadsheets, as a viewing and interaction tool, will be replaced with something with a different more mobile/touch-friendly UI paradigm, as the article seems to suggest (but doesn't really present much of a case for -- making vague suggestions about how spreadsheets don't work on touch [that remind me of the kind of hyperbolic descriptions of why current solutions don't work typical of infomercials] without any suggestion of what concrete elements would work better is not making that case.)
That said, airtable does look pretty cool. As someone terminally addicted to Excel, and looking at Microsoft's recent responsiveness to market dynamics, it makes me wonder whether if this was a major market opportunity, they could create a special "realtional DB tab" in excel and capture 90% of the functionality. Interesting to watch.
Agreed with you on the next gen of spreadsheets, being more powerful spreadsheets. The OP is playing their book: sure, Airtable can do list-taking - and I use Evernote for that - but it sure ain't going to replace Excel.
Joel Spolsky also has a great essay about this: http://www.joelonsoftware.com/items/2012/01/06.html
"What was I talking about? Oh yeah... most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations."
Excel is used for a great many things, lists, calculations, analysis, charts, storage, and all of the possible mixtures of the two.
Normal people use spreadsheets. These spreadsheets then grow into monsters.
What's needed is an invisible migration path so that people use what they understand but have somewhere to grow when they start abusing formulae to do what a real RDMS would do naturally.
It's essentially a UX problem - to all extents and purposes a database == a spreadsheet with multiple sheets - as soon as you start defining relationships between the sheets.
"My company, Airtable, was founded to address this need."
Here's an example of another article from the New Tech Forum: http://www.infoworld.com/article/2607260/database/how-databa...
As soon as you add relationships, such as 1-to-many, the average end user is lost. Not just struggling a little, but completely bamboozled. As programmers we often forget that even something as simple as that is a road block for almost all end users. Teaching users about relationships is a dead end, about 90% will never get it. Especially when they are trying to learn about it from a website product.
Instead I think 'airtable' would be better placed marketing to web developers and IT departments. Every company I have worked at has requests from other departments wanting a simple database. Most companies are full of these simple internal databases. A tool that allows us to quickly (~1 day) setup a solution and then get rid of the request would be a boon. You should be targeting web developers and IT professionals with your solution.
Wikipedia's actually got a good article on it: https://en.wikipedia.org/wiki/Javelin_Software
But consider this: if they hadn't mistimed their IPO to be the day after the Crash of 1987, they could easily have been the dominant paradigm in spreadsheets and small databases.
Unlike models in a spreadsheet, Javelin models are built on objects called variables, not on data in cells of a report. For example, a time series, or any variable, is an object in itself, not a collection of cells which happen to appear in a row or column. Variables have many attributes, including complete awareness of their connections to all other variables, data references, and text and image notes. Calculations are performed on these objects, as opposed to a range of cells, so adding two time series automatically aligns them in calendar time, or in a user-defined time frame.
Maybe it's just not well-explained by the Wikipedia authors, or it makes more sense if you see it ...
So creating a spreadsheet that is not as easy in order to support real database like functionality is going to end up the same way...
We kind of work around spreadsheet limitations now by having a separate google sheet hold source data in various tabs (one for each relational table), then importing data from that sheet into the working spreadsheets (where we do enrichment and analysis) using various lookup and query functions. It's precisely as fragile as the attention span of the most easily distracted team member.
I can't really be more specific unfortunately - NDAs etc.
It a hidden gem of many finance departments.
Sad. It looked like it could have been a game-changer.
It's like a spreadsheet, but more suitable for complex data
because it's hierarchical.
It's like a mind mapper, but more organized and compact.
It's like an outliner, but in more than one dimension.
It's like a text editor, but with structure.The big problem is unless you are very disciplined it is easy for a large spreadsheet to become unmaintanable. I've come across this a lot when I've been approached by people in my work place asking me to automate a spreadsheet for them. Inevitably someone will insert, delete or just move a column around and the whole fragile mess will come crashing down.
I've found when someone comes to me and says "I spend X amount of time every morning updating this spreadsheet can you automate it for me." The answer is almost always to migrate to a database.
Spreadsheets also seems to encourage people to lazily paste data in without much thought. I've seen some real nightmares - spreadsheets that are 100's of mb in size and contain almost a complete copy of portions of the company's database inside them, which take minutes to open and load.
Pasting data has some other disadvantages as well over time minor changes sneak in due to the mutable nature of cells in excel. Which leads to phone calls like "Can you check the figures for last FY Mike our Accountant is telling me X while Bill our Engineer is convinced it should be Y" eventually you find out Mike is getting his data out of a giant spreadsheet and one of the cells has 'inadvertantly' been modified so it no longer agrees with the source database. Eventually you learn to head off phone calls like this with "The number in the database is correct if you sourced it from anywhere else its likely to be wrong." But still frustrating to deal with.
As it is, I opened a json endpoint so that Zapier can scrape our orders and fill it into the next-blank-line in a google doc.
Is there a better way to satisfy this use case?
Should be a piece of cake, but you'd definitely want to throttle the rate though to prevent yourself from being throttled. :-)
Also, the API docs being automatically customised per-table is awesome.
I love Excel - I wonder how it was possible to analyse a business before it came along - and the primary reason is pivot tables. Pivot tables are an awesome tool.
It should be possible to replicate pivot table functionality using SQL semantics.