标签: database-design

dba.se 版本和programmers.se 版本的问题“反对或支持将应用程序逻辑置于数据库层的论据是什么？”的答案和评论。在某些工作场所中，DBA 和程序员之间的鸿沟非常具有启发性。

DBA 可以采取哪些不同的方式来更好地与程序员合作解决此类问题？

我们应该吗：

• 研究我们的程序员使用的工具和语言来了解他们面临的困难，尤其是在使用精心设计的数据库时？
• 鼓励程序员更好地了解数据库以及在数据库级别拥有业务逻辑的优势？
• 改变我们定义数据接口的方式——例如通过使用对程序员更友好的事务 API（例如，解决向后兼容性等问题）？

我有一个表，该表当前在一列中有重复的值。

我无法删除这些错误的重复项，但我想防止添加其他非唯一值。

我可以创建一个UNIQUE不检查现有合规性的吗？

我曾尝试使用NOCHECK但未成功。

在这种情况下，我有一个表格将许可信息与“公司名称”联系起来

编辑：具有相同“公司名称”的多行是错误数据，但我们目前无法删除或更新这些重复项。一种方法是让INSERTs 使用一个存储过程，该过程将因重复而失败......如果可以让 SQL 自行检查唯一性，那将是可取的。

此数据按公司名称查询。对于少数现有的重复项，这意味着返回并显示多行...虽然这是错误的，但在我们的用例中是可以接受的。目的是防止将来发生。从评论看来，我必须在存储过程中执行此逻辑。

我想在 Web 应用程序中实现“取消删除”功能，以便用户可以改变主意并恢复已删除的记录。关于如何实现这一点的想法？我考虑过的一些选项实际上是删除有问题的记录并将更改存储在单独的审计表中，或者不删除记录并使用布尔“已删除”列将其标记为已删除。后一种解决方案需要额外的应用程序逻辑来在正常情况下忽略“已删除”的记录，但会更容易在应用程序端实现恢复记录。

我很久以前在某个地方读过。这本书指出我们不应该允许在 SQL Server 中使用嵌套视图。我不确定我们不能这样做的原因，或者我可能记得不正确的陈述。

学生们

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

老师

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

学校

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
     vw_eligible_student s 
     ON s.SchoolID = sh.SchoolID
JOIN 
     vw_eligible_teacher t
     ON s.SchoolID = t.SchoolID

在我的工作场所，我调查了我们的一个内部数据库应用程序。我检查了对象，发现有两到三层的视图相互堆叠。所以这让我想起了我过去读过的东西。有人可以帮忙解释一下吗？

如果这样做不行，我想知道它仅限于 …

我们正在设计一个众所周知的读取量大的系统（每分钟读取数万次）。

• 有一个表names作为一种中央注册表。每行都有一个text字段representation和一个唯一的字段，key它是该字段的 MD5 哈希值representation。¹该表目前有数千万条记录，预计在应用程序的生命周期内会增长到数十亿条。
• 还有许多其他表（具有高度变化的模式和记录计数）引用该names表。这些表之一中的任何给定记录都保证有一个name_key，它在功能上是names表的外键。

_{1：顺便说一句，正如您所料，此表中的记录一旦写入便不可变。}

对于表以外的任何给定表names，最常见的查询将遵循以下模式：

SELECT list, of, fields 
FROM table 
WHERE name_key IN (md5a, md5b, md5c...);

我想优化读取性能。我怀疑我的第一站应该是最小化索引的大小（尽管我不介意在那里被证明是错误的）。

问题：和列
的最佳数据类型是什么？ 有理由使用over吗？或者？keyname_key
hex(32)bit(128)BTREEGIN

我有一个带有用户表和角色表的数据库模型。我想控制对多达 10 个不同元素的访问（权限）。可以将访问权限授予角色或单个用户。下面是用户、角色和项目的表定义：

CREATE TABLE users
(
  id serial NOT NULL PRIMARY KEY,
  username character varying UNIQUE,
  password character varying,
  first_name character varying,
  last_name character varying,
  ...
);

CREATE TABLE roles
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

CREATE TABLE element_1
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

...

现在我有两种不同的方式来设计版权。一个带有权限类型列的表或 10 个权限表 - 一个用于我想要控制访问的每个元素。

每个元素一个权限表与一个权限表的优缺点是什么？- 或者是更合适的方式来做到这一点？

常见字段的长度和数据类型最常见的最佳实践是什么，例如：

• 名
• 姓
• 地址
• 电子邮件
• 性别
• 状态
• 城市
• 国家
• 电话号码

等等....

我想在数据库中存在的列的名称中搜索字符串。

我正在处理一个维护项目，我处理的一些数据库有 150 多个表，所以我正在寻找一种快速的方法来做到这一点。

你有什么建议吗？

（这被建议从 StackOverflow 转发到这里）

当前有一个表 .. 并且需要开始向其中添加新的数据列。并非每条记录（即使在添加新数据列后继续处理新数据）都会有数据。所以我想知道这是否更适合新表，因为它实际上是某些数据行的扩展，并不适用于每一行。

换句话说，由于这些新数据元素会有很多未使用的列，所以这似乎更适合新表？

第一个表是页面浏览量的记录（目前有200万条记录）

- ID
- IP地址
- 查看次数
- created_at 时间戳
- 日期

对于每个 IP 地址，每天都会进行记录 - 并将连续的浏览量添加到每天的浏览次数中

附加字段将用于原点跟踪（即谷歌分析源/媒体/活动）

并非每次访问都会有这些信息。我会假设大约 10% 的行会有数据（因为它通常只归因于第一次访问）

数据的主要用途是确定人们来自哪里。这可能会被更频繁地使用（然后似乎适合单表）

感谢反馈 - 如果需要可以添加更多

有没有办法找出知道为表创建哪些索引的最佳方法？