新表与新模式
假设我有一个包含许多相关表的架构：用户、城市、项目、购买等。我现在希望数据库中有一个表，其中仅包含事件日志记录数据以供内部支持。日志表中的信息行是独立的，完全没有关系，并且与我的其他表无关。在现有架构中创建新表还是创建全新架构更好？一种方法优于另一种方法吗？是否存在与其中一项相关的成本？
Suppose I have a schema with many related tables: users, cities, items, purchases, etc. I now want a table in my database that contains solely event logging data for my internal support. The rows of information in the logging table are self-contained, not at all relational, and unrelated to my other tables. Is it better to create a new table in my existing schema, or to create an entirely new schema? Is one method preferred over the other? Is there a cost associated with one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，这一切都取决于数据库的大小。如果您正在管理数十个包含数百万行数据的表，那么您可能会更轻松地将这些日志记录表隔离并管理到它们自己的架构/数据库中。如果您只是管理一个小型应用程序，那么不用担心，将所有内容放入一个数据库/架构中。如果您的数据库很大或者您预计数据库会变得很大，那么请将它们分解。一旦它们被分解为单独的实体，您就可以使用各种强大的可用工具轻松管理多个数据库/模式之间的通信。
In my opinion it all depends on the size of your database. If you are managing dozens of tables with millions of rows of data then you will probably have an easier time isolating and managing these logging tables into their own schema/database. If you are just managing a small app then don't worry, put everything into one database/schema. If your database is large or your anticipate your database becoming large then break them out. Once they are broken into separate entities you can easily manage the communication between the multiple databases/schemas using all kinds of great available tools.
在我看来，如果数据不相关，那么它就属于不同的模式。与将所有内容都放在一个模式中相比，创建新模式可能会产生非常小的开销，但我认为不值得担心。
In my opinion, if the data is unrelated, it belongs in a different schema. There's likely to be a very small overhead associated with creating a new schema, as opposed to having everything in a single schema, but I wouldn't have thought it was worth worrying about.