Forcing multiple tables to have the same columns in a database

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. T开发者_开发问答his 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!

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.

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.