问题标签 [database-design]

我很少（每月/每季度）使用 Microsoft SQL Server 2005 数据库视图生成数百个 Crystal Reports 报告。这些视图是否在我不阅读它们的所有时间都在浪费 CPU 周期和 RAM？我应该改用存储过程、临时表还是短期普通表，因为我很少从视图中读取数据？

我不是 DBA，所以我不知道数据库服务器内部的幕后情况。

是否有可能有太多的数据库视图？什么是最佳实践？

有谁知道论文/书籍/等。数据库的文档模式？例如，一个常见的经验法则是每个表都应该有一个主键，并且该键应该没有信息内容。所以我想知道是否有人写过关于设计关系数据库的设计模式的书或发表过论文？

@盖乌斯，

这就是数据库设计者需要权衡的问题——数据库结构的可能稳定性是多少？给定一个足够长的视野，没有什么是稳定的。或者反过来说，只要视野足够长，一切都会发生变化。代理键（理论上）不应该改变它的含义，因为它从一开始就没有意义。

我想在那个特定的设计场景中要考虑的另一件事是谁会看到主键？如果主键是最终用户实际需要参考的东西，那么让它成为他们可以理解的东西是有意义的。但是我想不出最终用户需要查看主键的许多情况。通常存在主键以允许数据库引擎加速某些操作。

我最初提出这个问题的想法是找到由比我更有经验的数据库设计人员编写的数据库设计设计模式，以便避免一些容易避免的错误。如果有人曾经编写过数据库设计反模式，那将会很有趣。

例子

我有Person,SpecialPerson和User. Person他们SpecialPerson只是人——他们在网站上没有用户名或密码，但他们存储在数据库中以保存记录。用户拥有与在网站注册时相同的所有数据，Person并且可能SpecialPerson拥有用户名和密码。

你会如何解决这个问题？您是否有一个Person表来存储一个人的所有常见数据，并使用一个键来查找他们的数据SpecialPerson（如果他们是特殊的人）和 User（如果他们是用户），反之亦然？

有人对 Web 应用程序的数据库设计有任何提示/建议吗？当/如果我正在开发的应用程序起飞并开始大量使用时，这种东西可以在未来为我节省大量时间/精力。

更具体地说，该应用程序是一个策略游戏（基于浏览器，仅文本），主要涉及玩家发出“订单”，这些“订单”将存储在数据库中并稍后处理，结果也存储在那里（历史“订单”和相应的结果可能会变得相当大）。

编辑以添加更多详细信息（根据要求）：

平台：Django

数据库引擎：我正在考虑使用 MySQL（除非使用另一个有很大的优势）

架构：我现在只有一些 Django 模型，这里发布的细节太多了。如果我开始发布模式，这会变得过于具体，我正在寻找一般提示。例如，考虑我发出稍后将处理的“订单”并返回我必须存储以显示某种“历史”的结果。在这种情况下，最好为“历史”创建一个单独的表，还是只使用一个汇总“订单”和结果的表？我想我可以缓存“历史”表，但这会占用数据库中的更多空间以及更多的数据库操作，因为我必须不断地创建新行，而不仅仅是在聚合表中更改它们。

在创建数据库结构时，有哪些好的指导方针或确定数据库应该规范化到何种程度的好方法？您是否应该创建一个未规范化的数据库并随着项目的进行将其拆分？您是否应该根据性能需要创建它并完全规范化并组合表？

您将如何设计数据库以支持以下标记功能：

• 项目可以有大量的标签
• 搜索使用给定标签集标记的所有项目必须快速（项目必须具有所有标签，因此它是 AND 搜索，而不是 OR 搜索）
• 创建/写入项目可能会更慢以实现快速查找/读取

理想情况下，使用（至少）一组 n 个给定标签标记的所有项目的查找应该使用单个 SQL 语句完成。由于要搜索的标签数量以及任何项目上的标签数量都是未知的并且可能很高，因此使用 JOIN 是不切实际的。

有任何想法吗？

感谢到目前为止的所有答案。

但是，如果我没记错的话，给出的答案显示了如何对标签进行 OR 搜索。（选择具有一个或多个 n 标记的所有项目）。我正在寻找有效的 AND 搜索。（选择具有 ALL n 标签的所有项目 - 可能还有更多。）

我正在设计一个联系人管理系统，并遇到了一个有趣的问题，即以一致的方式对地理位置进行建模。我希望能够记录与特定人相关的位置（工作、学校、家庭等的邮寄地址）。我的想法是创建一个区域设置表，如下所示：

自治位置（例如国家，例如美国）是其父级的区域设置（ID、LocationName、ParentID） 。通过这种方式，我可以任意深度嵌套“政治单位”（国家 > 州 > 城市或国家 > 州 > 城市 > 大学）。一些查询必然涉及递归。

我将不胜感激任何其他建议，或者可能是关于我可能会在此类计划中遇到的可预测问题的建议。

varchar(255)、varchar(256)、nvarchar(255)、nvarchar(256)、nvarchar(max) 等？

256 似乎是一个不错的、圆形的、节省空间的数字。但我见过 255 用了很多。为什么？

varchar 和 nvarchar 有什么区别？

我正在创建一个 ASP.NET 网站，其中所有页面都挂在数据库驱动的树层次结构上。页面通常呈现 HTML 内容。但是，有些人会执行编程。

例子：

1. “联系我们”表格
2. 报告生成器

我应该如何表示/引用数据库中的编程？我应该有一个 Web 用户控件 (.ascx) 名称的 varchar 值吗？还是 Web 窗体 (.aspx) 名称？还有什么？还是应该只是我的应用程序中字典中的整数或其他此类 ID？

我可以用这种结构制作一个 ASP.NET 站点地图提供程序吗？

在此处查看更多信息：哪个是我导航的最佳数据库架构？

我正在创建一个网站，其中所有页面都挂在数据库驱动的树层次结构上。

除了一个节点外，所有节点都有一个父节点。节点可能具有基于角色的读取权限。某些节点可能有特殊规则（例如：不在导航菜单中显示）。

节点可能表示到其他节点的链接（如 Windows 中的快捷方式）。节点通常代表页面。

页面呈现 HTML 内容或执行编程。某些页面可能是子树的根（备用母版页和样式表）。

请帮助我在 Microsoft SQL Server 中设置我的节点数据库以供 Linq to SQL 使用。

我有三个想法：

1. 许多具有几乎为零的 nullalbe 字段的轻量级表。

   

2. 具有大量 nullalbe 字段的重量级节点表。

   

3. 两者中最好的（或最坏的）：许多轻量级表的大量空外键。

   

您认为哪个最能代表数据？哪个最容易与 Linq to SQL 一起使用？

如何将我的数据完整性规则保存在数据库中？我如何在我的编程中最好地执行它们？

• 节点必须是（但不能同时是）链接或页面。

• 页面必须是（但不能同时是）html 或代码。

• 链接可能不是根目录、html 或代码。

我可以制作具有这种结构的 ASP.NET 站点地图提供程序吗？我是不是该？

更新：我问了一个更一般的问题：

在 SQL 中处理一对一关系的最佳方法是什么？

相关问题：
如何在我的数据库中实施数据完整性规则？