在修改表的时候会得到下面的提示，修改表需要删除后重建。 解决办法 在 SQL Server Management Studio 中选择 Tools > Options 然后选择左侧的设计（Designers）下面有一个选项是当对表进行调整的时候，如果需要重建表，操作将会被禁止的选项。     将上面的选项取消选择后，再执行操作就可以了。 发生这个问题的主要原因就是因为在创建表的时候对表进行重建了，在工具的默认情况下，这个操作是禁止的。 https://www.ossez.com/t/sql-server/627

postgresql.conf中的这个参数（max_fsm_pages）用于告诉 PostgreSQL申请多大的内存空间用于保存数据文件的free space信息，按我的简单理解，如果在一个表中删除了一些记录，PostgreSQL会把这一改动记录在"Free Space Map"中，下次如果再往表里插记录时，根据Free Space Map中的信息，就能利用以前删记录而腾出来的磁盘空间。 不过Free Space Map是存在于内存中，大小毕竟是有限的，对于大量数据的删除＋插入，要么指定一个较大的max_fsm_pages,要么及时进行vacuum以整理表中的碎片，否则，PostgreSQL只有把新插入的记录添加到文件的末尾，造成文件越来越大。 我的一个程序就是意外地因为磁盘空间满了而中止的，它每次要往一个表里插500多万条记录，这之前先要delete同样条数的一批记录，可最后还是占满了整个硬盘。 我觉得PostgreSQL的这种工作方式有它的一个好处，就是如果内存足够大，可以指定一个很大的Free Space Map，对于OLTP 型的应用，可能会大幅提高性能（猜测，没有验证过），另外用户可以自已选择在合适的时候进行vacuum或vacuum full，如果你确信一个表只会往里插记录（如记录操作日志），对这个表就可以永远不进行vacuum full，是不是很灵活？ 不过，使用vacuum full大量移动数据毕竟是件很耗时的工作，在此期间数据库性能会严重下降，大概这就是“灵活”的代价了。在这方面，Oracle的Block->;Extent->;Segment这种复杂的机制可能更有效一些吧。 据说PostgreSQL将引入表空间的概念了，值得期待啊！ 至于Free Space Map设多大，上面的文章教了个办法，照着做就行了，只是需要弄明白，这毕竟是一个“Map”，如果打算删掉300M的记录，Free Space Map并不需要申请300M喔 。   https://www.ossez.com/t/pgsql-max-fsm-pages/500

如果我们在系统中配置下面的连接参数： spring.datasource.url=jdbc:hsqldb:file:~/db/cwiki-us-jpetstore 我们怎么知道 hsqldb 数据库的存储路径在哪里？   请参考下面的解答： 在 Windows 系统中，如果你登录的用户名为 yhu 的话。 那么这个数据库文件在 ：C:\Users\yhu\db 中存储。