我和我的朋友争论过数据库架构。
我们的应用程序读取一种csv文件，然后将数据（几乎200行）插入表中。 有时应用程序需要按文件名删除数据。
所以，我建议下面的表格模式 - ＆gt; [密钥]，[文本]，[文件名]
它能够插入带有文件名的数据，然后按文件名删除数据（从[TABLE]中删除，其中filename ='boolaboola'）。
但我的朋友， 他坚持“为什么不插入数据时创建和删除'TABLE'？”
他的表格架构是 - ＆gt; [关键]，[文字]
他的想法是 [当应用程序读取文件时，应用程序会创建一个名称为文件名的表。然后将数据插入新表中。 当我们需要按文件名删除数据时，只需删除表。]
即使我们的表不需要外键。
我无法同意这个想法。 根据我的经验，我觉得数据库架构是错误的...... 但我无法解释和说服我的朋友。
请帮帮我。 我错了吗？或者我怎样才能说服我的朋友？
答案 0 :(得分：2)
总的来说，我同意你的看法。更改数据库模式应该恕我直言，通常只有在软件更新时才会采取罕见的操作。我知道这是非常严格的'un-NoSQL'，但毕竟这是一个传统的关系数据库:)。
有关更具体的建议，有助于了解您打算如何使用此数据。将它存储在一个表中（可能是分区的，或者使用'filename'上的索引来提高性能，如果这是一个问题）更灵活：它允许您轻松地进行跨多个文件数据的分析。
此外，如果您以后想要使用某种O / R映射器或其他工具，通常会使您的表架构相当静态。
答案 1 :(得分：2)
仅仅是为了透视，来自现实世界的一个例子。不完全是一个“答案”，只是一个故事:)我决定发布它，因为有人说改变架构[即创建和删除表格]应该是一个罕见的行动“。没有给出令人满意的解释。
我目前正在为一家大公司开发一个大型应用程序。它由80％PL / SQL（Oracle）服务器端和20％浏览器GUI（Javascript，基于雅虎优秀的YUI3库）组成。仅GUI就具有> 140个单独的模块。
遗憾的是，应用程序的（较大的）服务器端部分没有中间件，它全部用PL / SQL编写。那是因为几年前它是一个小应用程序，这个架构很好，你从来没有资金写一个版本“2.0”（这意味着从头开始，抛弃1.0代码）。 （尽管如此，考虑到这些限制，它的编写得非常好，即使许多PL / SQL函数现在超过1000行甚至更多）。
因此，虽然您的Web应用程序中间件会定期跟踪会话和会话数据，但所有这些都必须在PL / SQL中手动完成 - 我们通过创建大量临时表来完成此操作。需要处理大量数据，而不是中间件缓存，我们使用表，会话数据以及某些功能。例如，当用户输入某些更高级别的“用例”时，我们会将（大量非常详细的）数据聚合到temp中。表，并在其余会话中从这些表中提供用户。那些更高级别的用例不需要细节，只需要聚合。
所以，创建和删除表......好吧，至少我们这样做，并且它工作正常。它没有一般技术原因支持或反对，这取决于您的真实世界情况。纯粹主义者可以抱怨我们缺乏他们想要的中间件，例如，在现实世界抱怨没有做任何事情。
我建议试着看一下更大的图景。你为什么反对动态创建表？原因是否真的具有技术性，然后尽可能多地用力（和狡猾）来捍卫你的位置。但是，我们经常使用技术。伙计们是waaaayyyyyyyy太宗教，拒绝承认（首先是对自己）。
当你发现自己永远争论（与另一个“技术人员”）而没有任何人能够说服另一个人时，这可能表明这个问题并不那么重要，因为根本没有明显和合理的答案:)宗教讨论总是比技术讨论长得多; - ）
动态创建和删除表是一种“合法”用例。仅暂时使用数据（而不是“永久”存储）并且仅针对该temp中的数据集运行查询。 table（如果它的交叉表存在对temp.table（s）的重要参数），那就去吧 - 如果它在宏观方案（你的应用程序和整体场景）中很方便。
PS：哦，顺便说一句，一般来说，没有办法对这里给出的场景说多少，作为一个论点的表现只有在它真的是一个问题时才会进入。 95％的情况并非如此，清单上的可维护性要高得多。
答案 2 :(得分：0)
删除表可以提高性能，因为表不必重新编制索引和其他数据库引擎开销;这大大提高了大数据的性能。但是，创建多个表会增加代码复杂性，因为您必须使用自己的索引来查找正确的查询表。