问题标签 [ddl]

如果您正在执行事务的中途并执行 DDL 语句，例如截断表，则事务将提交。

我想知道这是否总是如此并且根据定义，或者是否有隐藏在某处的设置会回滚事务而不是提交。

谢谢。

编辑以澄清...

我不希望在截断后回滚。我只是想确认已经执行的语句绝对总是要在 DDL 之前提交。只是想确保没有人可以设置破坏我的代码的系统属性。

我理解在 DDL 之前和之后提交的必要性，但从概念上讲，我认为可以通过在 DDL 之前回滚和之后提交来实现相同的一致性要求。

在 SQLITE 中的多于 1 列上指定主键的语法是什么？

我有一个在 MS Visio 中创建的数据库模型图，我想将其导出到 DDL 文件以创建 MySQL 数据库。我已经安装了 MySQL ODBC 驱动程序，我可以成功地使用它来生成 DDL 文件，但我还是有一些问题。

Visio 在表名周围加上引号，这些表名也是保留字（如用户）。这是不行的，因为 MySQL 为此目的使用了反引号 (`) 而不是引号 (")。

MySQL ODBC 驱动程序还将 BLOB 数据类型更改为 LONGVARBINARY，因此在创建数据库时不能直接与 MySQL 一起使用。

有没有人有任何建议如何处理这两个问题？

我正在玩一些 JPA 的东西，更改映射以查看它们应该如何等。这是基本的实验。但是我找不到一个工具可以简单地读取我的实体然后为我生成表模式。我试图在 JBoss 工具中找到类似的东西，但 nada。Eclipse 集成将是一个巨大的优势，但我将采用命令行工具或 ant 任务。

有任何想法吗？

我正在尝试以编程方式将标识列添加到表Employees。不知道我的语法有什么问题。

我究竟做错了什么？我试图导出脚本，但 SQL Mgmt Studio 做了整个 Temp Table 重命名的事情。

更新：我认为第一条语句“关键字'COLUMN'附近的语法不正确”令人窒息。

例如，DbVisualizer 可用于连接数据库并根据现有表及其关系创建漂亮的图表。但在这种特定情况下，我没有实时数据库，但我有一堆 create table 和 alter 语句。

是否有任何工具可以从 SQL DDL 生成类似的图表？

我们以本问题末尾的格式将数据库定义存储为 XML。我遇到的问题是获取模式列表、这些模式中的表、这些表中的列（所有这些都带有相关信息）。我当前的代码（包含在示例 XML 下方）抓取所有内容，完全忽略嵌套，并且由于多个模式，多次返回每个表/列。

示例 XML：

C#代码：

关于如何保留嵌套结构的任何想法？我也无法处理可选的 XML 元素（例如表格注释或大小字段，它们不适用于所有数据类型）。

谢谢！

我正在开发一个使用 Oracle 内置身份验证机制来管理用户帐户和密码的应用程序。该应用程序还使用行级安全性。基本上，通过应用程序注册的每个用户都会获得一个 Oracle 用户名和密码，而不是“USERS”表中的典型条目。用户还会收到某些表格上的标签。这种类型的功能要求在许多情况下将 DML 和 DDL 语句的执行结合起来，但这会带来一个问题，因为 DDL 语句执行隐式提交。如果在 DDL 语句执行后发生错误，事务管理不会回滚所有内容。例如，当新用户向系统注册时，可能会发生以下情况：

1. 开始交易
2. 将人员详细信息插入表中。（即名字、姓氏等）-DML
3. 创建一个 oracle 帐户（创建由密码标识的用户 testuser；） -DDL 隐式提交。交易结束。
4. 新交易开始。
5. 执行更多 DML 语句（插入、更新等）。
6. 发生错误，事务只回滚到第 4 步。

我了解上述逻辑按设计工作，但我发现很难对此类功能进行单元测试并在数据访问层对其进行管理。我让数据库关闭或在单元测试期间发生错误，导致测试模式被本应回滚的测试数据污染。发生这种情况时擦除测试模式很容易，但我担心生产环境中的数据库故障。我正在寻找管理这个的策略。

这是一个 Java/Spring 应用程序。Spring 提供事务管理。

我使用表格GadgetData来存储应用程序中小工具的属性。小工具基本上是一种自定义控件，具有 80% 的常见属性，如高度、宽度、颜色、类型等。每种小工具类型都有一些属性集是它们独有的。所有这些数据都必须存储在数据库中。目前我只存储常见的属性。我应该使用什么设计方法来存储这些列是动态的数据。

1. 创建具有作为 Columns 的公共属性的表，并添加额外的 Text 类型的列，以 XML 格式存储每个小工具类型的所有唯一属性。
2. 创建一个表，其中包含所有小工具类型中的所有可能列。
3. 为每种类型的小工具创建单独的表。
4. 你还有什么更好的推荐方式吗？

（注意：小工具类型的数量甚至可能超过 100 和 ）

我有一个脚本，它生成 DDL 脚本来为规范化数据库定义物化视图。某些表具有指向特定数据库用户的“所有者”列，然后我可以为其创建视图，该视图将仅显示当前数据库用户创建的表的行。在某些情况下，从安全性和便利性的角度来看，这样的视图都是有益的——例如，只显示一个人自己的多项选择测验结果。

问题是，除了几张表之外，还有很多表我可以想象有人要求这样的视图，但想不出具体的用例。但是，我认为有时这种通用功能可能很有用，因为我不能总是预见所有用例。

我的问题是，我应该费心自动生成多少这些个性化视图？对于数百个表，这为构建、测试和基准测试过程增加了大量时间，尽管它们是自动化的。您会在可能永远不会使用的额外功能方面犯错，还是在仅提供那些已被要求/您知道将有用的视图方面犯错？