强制多个表在数据库中具有相同的列
简介：我对数据库相当陌生，目前有一个数据库有两个表用于检查器类型脚本。有没有办法确保两个表使用相同类型的列？该数据库位于 Sybase 中。
详细信息：第一个表基本上是脚本所做的每次检查的日志（假设一次运行中有 106 次检查，因此它将 [运行次数] x [检查次数 < ；106>]）。第二个表用于上次运行，因此在本例中，它将包含 106 行。然而，这不是一个恒定的数字，并且可能会增加。
我的问题是，有没有办法强制两个表具有公共列？我在 syscolumns 表中看到，有许多行专用于每个表，但由于它们是相同的，我可以以某种方式让表从同一源提取它们的“样式”（模式正确）参数吗？其中一个的更改会在另一个上进行吗？
谢谢！
Brief: I'm fairly new to databases and currently have one with two tables for a checker type script. Is there a way to ensure that both tables use the same types of columns? This database is in Sybase.
Detail: The first table is basically a log of every check ever made by the script (Let's say there are 106 checks in one run, so it would [No. of runs] x [No of checks <106>]). The second table is for the last run, so in this case, it would contain 106 rows. This is not a constant number however, and could increase.
My question is, is there a way to force both tables to have common columns? I see in the syscolumns table that there are a number of rows dedicated to each of these tables, but since they are the same, can I somehow have the tables pull their 'style' (is schema correct) parameters from the same source so any changes on one are made on the other?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您需要多个表具有完全相同的列结构，规范化表明数据可能全部属于一个表。
我知道通过对数据进行非规范化可以找到一些收益，但既然您承认您是数据库新手，我会尝试首先找到一种标准化方法。
If you need to have multiple tables with the exact same column structure, normalization suggests that the data probably all belongs within a single table.
I understand that there are some gains that can be found by denormalizing data, but since you admit you're new to databases, I'd try to find a way to normalize first.
管理多个列和数据类型之间关系的一种方法是使用用户定义的域。一些 DBMS 系统支持用户定义的域。其他人则不然
SQL 中的动词是“CREATE DOMAIN”。您可以在文档中查找具体信息。
然后，当您创建表并创建组成表的列时，您可以使用已创建的域，而不是指定数据类型和相关参数。当两列引用同一域时，保证它们具有相同的数据类型。它们还保证具有相同的大小，例如“char(7)”中的“7”。
以真正增强通过抽象简化数据管理的能力的方式创建域涉及学习和经验。你必须从某个地方开始。
One way to manage the relationship between multiple columns and datatypes is by using user defined domains. Some DBMS systems support user defined domains. Others don't
The verb in SQL is "CREATE DOMAIN". You can look up the specifics in your documentation.
Then, when you create tables, and you create the columns that make up tables, you use the domains you have created instead of specifying datatypes and related parameters. When two columns are referred to the same domain, they are guaranteed to have the same datatype. They are also guaranteed to have the same size, like the "7" in "char(7)".
Creating domains in a way that really enhances your ability to simplify data management by abstraction involves both learning and experience. You have to start somewhere.
你描述了一个奇怪的情况。一般来说，一旦表被设计和实现并且应用程序开始使用它们，它们就不会改变。当然，在正常业务过程中（即每天，甚至每周），它们很少发生变化。
在什么情况下您认为需要额外的列？如果这是一个反复出现的情况（我已经遇到过其中一些），您将编写一个程序来添加列，这将确保表保持同步。如果要“手动”更改表格，通常是由具有管理员级别权限的人员来完成，并且管理员可以做他们（可能是错误的）可能想做的任何事情，而不管原始设计者的意图如何。这里最好的防御方法是记录系统要求，并确保可能需要更新表格的任何人都知道这些要求并且可以使用它们。
You describe an odd situation. Generally, once tables have been designed and implemented and applications start using them, they are not changed. Certainly they very rarely get changed during the normal course of business (i.e. daily, or even weekly).
Under what circumstances do you see the need for additional columns? If it is a recurring situation (and I have had a few of these), you would write a program to add the columns, and that would ensure that the tables remain synchronized. If the tables are to be "manually" altered, that is usually done by a person with admin-level rights, and admins can do whatever they (perhaps mistakely) might want to do, regardless of the original designer's intent. Your best defense here would be to document the system requirements, and make sure that they are known of and available to anyone who might have to udpate the tables.