Hi guys. I'm playing around evaluating the DDT at the moment.



The DDT does not seem to provide any way of creating triggers. One area where triggers are useful is in the enforcement of cardinality on a relationship. For example, a parent must have one and only one child, or perhaps between one and three children, but no more or less, etc.



Assuming that you use the DDT with your own apps, do you ignore triggers completely and implement things like cardinality in the business objects? For that matter, do you write any SQL at all (such as stored procedures for reports), or do you do it all in the .NET application?



The help file for the DDT is a little bit light on at this stage. For example, there is nothing on deployment packages or how to create and use them. Similarly for the steps required to update an existing database with a new version, something which the DDT is touted to be able to do.



The import function is very limited. I pointed it at an existing SQL Server 2005 database and only got the tables. No foreign key contraints, no unique key constraints, no indexes, no descriptions, no triggers and no stored procedures.



At the moment it is difficult to see what I would use the DDT for. The fact that it lacks any kind of diagram tools is also a big minus. I currently use CASE Studio 2 for designing my database schema, and while it may rely on scripts, it works and is very flexible, including ER diagrams, HTML reports, generation of RI triggers, and support for a multitude of databases.



The DDT has potential, but I think it is currently way too underdeveloped. Maybe you've got big plans for it that we will see in the future?



Regards,

Bruce

Hi Ben,



Interesting. So your approach is to use SQL Server primarily as a repository for the data tables, with some foreign key constraints and some indexes, and this is why these are the primary features that the DDT supports.



The DDT also has provision for stored procedures, either T-SQL or CLR. But your preference seems to be to avoid stored procedures altogether, if possible, and do everything in the application using the business objects. If you have to resort to a stored procedure, using CLR is your preferred choice.



I was taught database design using SQL and stored procedures. In my researches on .NET tools for database development, I am beginning to see that there are alternative approaches. I do like StrataFrame's ability to dynamically generate SQL statements. Some of the other tools I have evaluated take this approach also.



There seems to be a strong polarization in the developer community between stored procedures and dynamically generated SQL. I can see that the latter has some clear advantages. For example, not having to write and maintain dozens or hundreds of SQL stored procedures is a great idea. However throwing out stored procedures completely seems a bit extreme. To my mind some tasks can still benefit from stored procedures. Report generation, for example. Some reports require accessing large amounts of data in the database to produce a relatively short summary. In this case it seems better to compile the report on the database server rather than transfer huge amounts of data across the network.



As with most things in life, one needs to find the right balance. StrataFrame seems to take the dynamic SQL approach, but provides support for stored procedures when required. And of course, SQL Server 2005 provides this new feature of CLR stored procedures, which adds a whole new twist.



I am curious as to your database design technique. Do you design your database schemas directly into the DDT, or do you use other tools as well? Personally I would find it difficult to design a schema without diagramming tools, such as ER diagrams, as this is how I was taught. In addition, the diagrams are a great communication tool, both between developers and with clients. CASE Studio 2 is my current tool of choice because it does everything I need for a reasonable price. I have noted on some web sites that some people may be using Visio, however I am not familiar with this tool. There may even be some tools in Visual Studio 2005 that I haven't encountered yet, being so new to the product.



Thanks for your comments Ben, and for providing a different point of view.



Regards,

Bruce