The birth of VS DATA’s Table Designer (by Mairead)


As a relatively new member to the VS Data team, I was unaware of the complete history behind our toolset until recently when my Dev Lead Casey Quayle, one of the founding members of our database tool suite, gave me a history lesson on the formation of our team and our tools [originally the Query Designer, Table Designer, and Database Diagrams] and what our vision was for those tools 10 years ago.

One of the surprising things that Casey informed me about was that originally our toolset was made up of the Query Designer and Database Diagrams. There was no separate “Table Designer” tool, in that if you needed to design your tables, you did so via Database Diagrams. When the VS DATA toolset first hit the streets for the Alpha release of Visual Interdev 1.0, we received a lot of valuable feedback from users requesting us to provide a separate table designer tool for the case where users wanted to create or modify a single table instance. These users did not want to go through the process of creating a new database diagram for the creation or modification of one table only, they wanted a simply tool for this, hence the birth of the Table Designer.

So one of the questions that was playing on my mind since Casey’s history lesson, is that, is this still the case 10 years later, where people still require a separate tool for designing a single instance of a table as opposed to doing this via their database designer (database modeling) tool. Basically is there still a need for the Table Designer tool if Database diagrams covers all this functionality?   

If you have any thoughts on this please do let me know…

Mairead

Comments (10)

  1. I’m designing my tables through the Table Designer. I’m using the Database diagrams only for creating relationships and visualizing the overall database structure

    -Klaus

  2. Owen Brady says:

    To Answer your question about if there still should be a Table Designer tool outside of the database modeling tool. I would say yes. I tend to build one table at a time and only want to look at that one table, then when I am finished add it to the db design diagram. It is handy to be able to do it from inside the Db diagramer but I usually hate having the view exapanded to show all the field types, usually get information overload. Just my 2 cents.

  3. Mairead, when it comes to designing larger databases, I usually do them one table at a time. The database modeling tool, for the actual creation of tables aside from the modeling, I use for small databases with no more than a dozen tables. I still design the database model using a modeling tool first, but usually will not implement that model for a large database. I do it one table at a time. As far as the diagrammer in Sql Server’s client tools, I use this in the same way Klaus does, for an overal visualization and relationship view once the database exists. I usually model a database before implementation using Visio. But going back to my VFP and DBase days, a table designer has always been very valuable to me, and will continue to do so.

  4. The table designer is much easier to use for single tables as you can see more of the column and table properties in one view, plus it’s a lot quicker to load and save. Having to use a diagram for this would be a real drag.

    However, perhaps you could combine the two as the class designer does. In the class designer I can see all classes and the relationships between them. If I select a class I can see all the properties, methods, events etc in the editing grid below the diagram – also I can change the code and have this reflected in the design.

    It would be very cool if the database diagrams worked the same way. Selecting a table would show me the columns, table attributes, indexes, constraints etc in a properties panel below the diagram – much like the table designer but using a tab page setup or multiple panels. Then selecting View Code on an object would show me the sql to create and/or alter the object. And while your at it, I’d like to see stored procs, function and all other schema data in the one place – and permissions too! But now, I’m getting carried away with myself.

    If this worked as well as the class designer, the table designer ‘might’ become redundant.

  5. Peter, Visio Enterprise Architect edition provides that kind of functionality you are looking for. You can make changes and then merge your changes up to your database from your ERD.

  6. I don’t ever use the diagram tool except, as Klaus said, to visualize overall structure—and only then toward the end of the database creation process. More as documentation/reference than anything.

    I’m still working in SQL Server 2000 so there may be updates of which I am unaware, but in that version at least, I find the diagram tool awkward and painful to use. I’d be pretty put out if the table designer went away. My two cents.

  7. Mairead says:

    Thanks all for your comments and feedback, I really appreciate it and was delighted to hear how you use Table Designer

  8. Dating says:

    As a relatively new member to the VS Data team, I was unaware of the complete history behind our toolset until recently when my Dev Lead Casey Quayle, one of the founding members of our database tool suite, gave me a history lesson on the formation o

  9. Weddings says:

    As a relatively new member to the VS Data team, I was unaware of the complete history behind our toolset until recently when my Dev Lead Casey Quayle, one of the founding members of our database tool suite, gave me a history lesson on the formation o