电子表格一直以来都是数据库的一个强有力（即使是相当直观的）类比。数据库具有表，这就像一个单独的电子表格。想象一个用于跟踪婚礼 RSVP 的电子表格。在顶部，列标题如姓名、姓氏、地址和出席？这些标题也是数据库表中的列。然后，该电子表格中的每个人实际上都是一行，这在数据库表中也是一行（或条目、项目，甚至元组，如果你真的很有学问）。
越来越普遍的是，这不再需要是一个类比。我们可以完全按照字面意思使用电子表格 UI 作为我们的实际数据库。这很有意义，因为它不仅仅是将数据库数据视为电子表格，而是将电子表格类似的功能作为应用程序中与数据库类似的功能同等重要的功能。
使用电子表格，重点可能是查看整体并以这种方式理解事物。浏览、排序、直接在 UI 中输入和编辑数据，以及创建有用的可视化输出。
使用数据库，你不会真正直接查看它——你会查询它并使用结果。数据输入和编辑是通过代码和 API 完成的。
这并不是说你不能直接查看数据库。像 Sequel Pro（以及许多其他！）这样的数据库工具提供了一个界面，用于以电子表格类似的格式查看表
令人高兴的是，电子表格和数据库的概念可以共存，同时提供两全其美。至少，在一定程度上。
我们之前在 CSS-Tricks 上讨论过 Airtable，它是一个非常好的例子。
Airtable 将它们称为基座，虽然你可以以各种有用的方式查看其中的数据（日历！图库！看板！），但主要的视图可能是电子表格。
如果你只使用 Airtable 作为电子表格，它仍然非常不错。UI 做得非常好。像过滤和排序这样的功能感觉是真正的同等重要功能，以至于其他电子表格技术没有做到这一点几乎让人觉得奇怪。甚至字段类型也感觉实用而现代。
此外，由于基座中存在各种不同的视图，以及更酷的是，它们提供的用于使视图更像仪表板的所有“块”，因此它是一个强大的工具。
但我想说的是，你也可以像数据库一样使用你的 Airtable 基座，因为你自动拥有对基座的读/写 API 访问权限。
我在我的文章 如何将 Airtable 用作前端开发人员 中更多地谈论了这一点。从读取数据的角度来看，这种 API 访问非常棒，可以做一些事情，例如 将其用作博客的数据源。Robin 提取数据来构建他自己的基于 React 的界面。我喜欢它有一个 GraphQL 界面，虽然它是第三方。
写入访问权限可以说更有用。我们在 CodePen 上使用它来进行类似 CRM 的工作，方法是将数据发送到一个包含所有我们需要的信息的 Airtable 基座中，然后直接使用 Airtable 来可视化事物并执行我们想要的操作。
Airtable 的替代方案？
曾经有 Fieldbook，但它 关闭了。
RowShare 看起来奇怪地相似（虽然功能稍微少一些），但它似乎没有 API，因此它并不完全适合这种跨越数据库/电子表格差距的需求。 更新：显然它 确实有 API，我只是无法在以注销用户身份浏览网站时找到任何链接。
Zoho Creator 确实有 API 和内置的有趣的可视化功能，这实际上看起来非常酷。看起来他们的一些营销是围绕着这样的理念：如果你需要构建一个 CRUD 应用程序，你可以使用它来完成，而无需任何编码——我认为他们认为这很有说服力。
Actiondesk 看起来很有趣，因为它属于对电子表格功能的现代化演绎。
虽然它与数据库相连，因为它看起来可以从 MySQL 或 PostgreSQL 这样的东西中提取数据，但它似乎没有类似数据库的读/写 API。
我们可以直接使用 Google 表格吗？
天空最大的电子表格工具当然是 Google 的电子表格，因为它非常好、免费且熟悉。它更像是 Excel 的浏览器移植版，所以我可能会争辩说，它与数字极客的传统联系比它对电子表格或数据存储工具的任何新颖尝试更密切。
Google 表格有 API。他们相当重视它，因为它已经是 v4 版本，并有 大量文档和指南。 查看一个关于从 Slack 向其写入数据的实用小教程。 据我所知，问题在于 API 奇怪、复杂且难以使用，就像表格本身一样。叫我胆小鬼吧，但是 这个快速入门 让人有点眼花缭乱。
如果要保持所有数据都在 Google 表格中并像数据库一样使用它，那么最引人注目的方法似乎是Sheetsu。
呃。Sheetsu 已死。Richard O’Dwyer 写信告诉我，他有一个替代服务：sheet2api。我将用它替换下面的屏幕截图和链接。
它处理连接/身份验证到表格，然后为你提供干净易懂的数据 API 端点。
此外，还有一些有趣的功能，比如为你提供一个表单 UI，以便可能比处理电子表格本身更容易（或更公开）地输入数据。
还有 Sheetrock.js，这是一个开源库，可以帮助访问表格的 API，但它已经好几年没有更新了，所以我不知道它的状态。
我并没有说这个想法完全取代了传统的数据库。
一方面，数据库的关系部分（例如 MySQL）是一个非常重要的方面，我认为电子表格并不总是能够很好地处理它。
假设你的数据库中有一个员工表，该表中的每一行都列出了他们工作的部门。
ID Name Department
-- -- --
1 Chris Coyier Front-End Developer
2 Barney Butterscotch Human Resources
在电子表格中，这些部门名称可能只是字符串。但在数据库中，在一定规模下，这可能并不明智。相反，你会拥有另一个部门表，并将两个表通过外键关联起来。这正是 这份经典解释文档 中所描述的。
要查找特定员工部门的名称，无需将员工部门的名称放入员工表中。相反，员工表包含一列，该列保存员工部门的部门 ID。这被称为部门表的外键。外键引用包含相应主键的表的特定行。
ID Name Department
-- -- --
1 Chris Coyier 1
2 Barney Butterscotch 2
ID Department Manager
-- -- --
1 Front-End Developers Akanya Borbio
2 Human Resources Susan Snowrinkle
公平地说，电子表格也可以具有关系功能（Airtable 就可以），但它可能不像某些数据库那样是基本的一级公民。
也许更重要的是，数据库很大程度上是开源技术，由庞大的技术生态系统支持。你可以在各种不同的托管平台和硬件上托管你的 PostgreSQL 或 MySQL 数据库（或者所有大型数据库玩家的数据库）。有各种用于监控、保护、优化和备份它的工具。此外，如果你接近突破数万行规模的临界点，我认为电子表格已经跟不上。
选择专有数据托管者主要是为了在一定程度上实现便利性和花哨的 UX。我非常喜欢它。
无需服务器或数据库维护。轻松的 IAM 和加密。在 Google 表格中复制 SaaS 数据非常有意义。Flatly.io 使 Google 表格和 Excel 在线易于用作数据仓库，无需编码。
(披露：我是创始人。)
实际上，将电子表格用作数据库与将数据库用作数据库之间没有任何区别（只要您只使用一个表）。猜猜电子表格如何存储数据？没错，在数据库中。因此您正在使用带有 API 和前端的数据库——这对于传统数据库来说也是如此。
但是，除了存储和检索数据之外，数据库还会为您做很多工作。例如，它们确保写入操作永远不会只执行部分（例如，由于崩溃），它们在后台拥有一个非常复杂系统来确保对经常搜索的表的智能缓存和对数据库的有效搜索，等等。
我真的看不到使用电子表格优于实际数据库的任何好处。
如果您使用电子表格，您仍在使用数据库——只是糟糕的数据库（出于目的）。
其次：如果您使用第三方电子表格服务，最好确保您与其提供商的联系充分保证了用户隐私（Google 表格无疑是不可行的）。
这可能意味着大多数免费电子表格服务都不可用，至少如果您想在欧盟提供您的服务（因此必须遵守 GDPR）或关心您的用户。
还有 Coda (https://coda.io/)。它看起来很有希望。我已经将其用于个人组织和小项目。
嗨，Chris——我是一名 MSSQL 开发人员——但令人惊讶的是，我不讨厌这个想法:) 我可以想象它在非通过界面更新的 web 应用程序中的数据中特别有用：参考表等。这将使非技术人员能够在需要时更轻松地更新此数据，而无需需要了解 SQL 的人来进行基本更新。好文章。
我从某种程度上从相反的角度来处理这个问题。我有一些大小合理的静态 CSV（200-6000 个条目），想知道我将它们变成数据库的临界点是什么，在线电子表格方法似乎是一个不错的选择。
对现有功能的出色概述。HubSpot cms 也有类似的东西 https://knowledge.hubspot.com/articles/kcs_article/cos-general/how-to-edit-hubdb-tables
Hubdb 的一个缺点是，您不能像在 Airtable 中那样使用表单填充行。
很棒的文章。看到人们如何使用替代的数据存储方法非常有趣。在约克大学，我们正在使用 Google 的 Fusion Tables（是的，即使它们是测试版产品！）作为快速替代方案来托管简单的表格数据。
如果有人有兴趣使用 Google 表格进行非常简单的数据存储，而无需处理身份验证问题，那么您可以使用我在这里编写的一个方便的实用程序以 JSON 格式读取数据：https://robkendal.co.uk/reading-google-sheets-data-using-javascript/
我使用解析和执行服务器上 PHP 的 SQL 语句的结果来配置和填充我自己的 javascript 电子表格解决方案。语句可能如下所示
SELECT id,ddc as DDC , ddcgroup as Beschreibung FROM $gf->table order by ddc;
然后将生成的行的集合和一堆元数据传递给客户端，以便在类似表格的电子表格中呈现，在那里我可以实时操作数据。
这非常方便。
是的！我一直致力于一项您可能喜欢的东西。它是一个自托管的电子表格 CMS/数据库编辑器，用于 MySql 数据库。有点像 MySql 和 Airtable 的混合体，但目标是保持简单。
我刚刚将其公开 https://github.com/jenstornell/squares 查看截图，您就会明白。它仍然处于雷区/测试版状态，但已经包含了大多数基本功能。
链接失效了:(
Databox 现在很火，猜猜他们的“最受欢迎”数据源集成是什么？:)
https://databox.com/google-sheets-integration
更挑剔地说，您可能会再次引用“员工”表，而不是在“部门”表中拥有经理姓名:)
我为我们公司的贸易展览建立了一个 HTML/PHP 网站，我使用 JSON 从发布的 Google 表格中提取数据，然后使用 CSS 进行样式设置……它在我的使用场景中运行良好。我认为我在 stackexchange.com 上的某个地方找到了最初的想法。
将电子表格用作数据库的替代方案似乎是一个糟糕的想法。在任何应用程序/网站中，您只需要一个表的情况很少见，如果您使用的是数据库，但使用电子表格表会确保您在任何表联接上的性能都很差，因为没有表索引的概念可以联接。同样，没有用于搜索的索引，因此这是另一个性能问题。
然后您会遇到其他性能问题，因为您对任何类型的列类型提示都非常有限。实际上，电子表格列完全有可能包含字符串、数字、日期、公式的混合，您无法以现实的方式设置列数据类型。
从功能上来说，您会失去事务，这可以确保任何修改查询作为一组完成，或者根本不完成，而不是部分修改，这会导致数据集中断。最后，您会失去构建在大多数数据库中的某些非常强大的功能；没有存储过程来帮助防止恶意查询，因此所有这些逻辑都需要在您的应用程序中复制。
电子表格可能有一些用作数据库的用途，但我似乎想不出一个。
新玩家：https://stackby.com/