|   | ![]() |
|
One thing you can't do from the explorer
is modify datatypes, specify primary keys, add rules and defaults, etc. For this you
will need to go to the table editor.
The table editor gives you a lot of information in a single place. The columns tab shows you a list of the columns, datatypes, and nullability. The DDL tab will display the DDL that will be use to create that table. The indexes tab gives you the ability to create indexes for the table as well as view existing indexes. The foreign keys tab displays all foreign keys along with the parent - child relationship. The definition tab is a free form text box where you can specify a definition for the table. This is generated as a table comment for those DBMSes that support it. The note tab gives you the ability to add notes to the table that will be generated in any reports. You can also include HTML tags which are picked up and passed to the Intranet Publisher. The fianl tab allows you to specify a location (filegroup, extent, segment, data block, etc.) to place the table on. You can also add, modify, or delete columns. (Please see the note above concerning the explorer for deleting columns.) Reordering the columns can be accomplished here, but there is a much simpler way that will be discussed later. The table editor is actually a split screen. You normally don't see the bottom half of the screen. Double clicking on one of the rows or clicking the add, edit, or delete buttons will display the rest of the editor as shown below.
From here you can specify the datatype, nullability, default, rule, constraint, primary key, and a domain. I won't get into domains in deatil here, but will instead reserve those for another article. These are something you want to research and utilize in your design. They provide a lot of power and make changes very simple. A domain consists of a column name and datatype. Optionally, you can include a rule/check constraint or default. These are not the same as user defined datatypes and offer significantly more power. The definition on the bottom part functions the same as the definition tab on the top of the dialog. This gives you the ability to include a definition that is generated as a column comment for those DBMSes that support it. I mentioned previously that there was a much easier way to move columns around than using the table editor. This is displayed in the image below.
At first glance you might not see much difference between this screen shot and a previous one of the main workspace. If you look on the second toolbar, you will notice that I am currently using the little "hand" tool. If you look at the Invoices table, you will see that the Address column is highlighted. Further, you will see an underline beneath the TerritoryID in the EmployeeTerritories table. What I did here was very simple. I selected my little "hand" tool, clicked the Address column and dragged it to the EmployeeTerritories table. When I release the mouse, the Address column will be moved from the Invoices table to the EmployeeTerritories table. You can also do the same thing within a table. This is by far the easiest method for rearranging tables of any tool I have come across. What do the other data modeling tools make you do in order to move a column from one table to another? Simple. They don't. You have to add the column to one table and delete it from another. ER/Studio is the only one that allows drag and drop movement of columns between tables. Not only does it allow drag and drop movement, but it goes that extra step as well. Suppose you also wanted an Address column in the EmployeeTerritories table that is a duplicate of the one in the Invoices table. The other modeling tools would make you manually add it. ER/Studio allows you to do this via a simple Ctrl+drag. This is by far the easiest and safest method, because you don't have to worry about missing any setting such as rules, defaults, datatypes, etc. |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.