Hello Guys,

what are the future plans of the designer? Will it be more and more a data maintenance tool? I am thinking about indexes and other stuff which is important for the generation process of the database script.

Or should I use a tool like xCase to do that and use the reverse engineering functionality of LLBLGen?

What do you think?

Kind regards Carlo

Rushmore wrote:

Hello Guys,

what are the future plans of the designer?

I'm not going into details here, but the designer will be extended in v4, as well as the runtime, with new features

Will it be more and more a data maintenance tool? I am thinking about indexes and other stuff which is important for the generation process of the database script.

It won't go towards data-maintenance, as it's primarily a model oriented tool. Index creation/generation is often requested, but it's one of those things which, when you have it, won't prove to be useful. The thing with indexes is that it depends on dataset size and query behavior where which indexes you're creating, not the model. This means that if you have the model in llblgen pro's designer, you of course could say "I want all FK's to be covered with an index", but having an index isn't free: every insert will take longer if there are indexes on the table. Add to that that with just the model, you don't know where to place the indexes, as you don't know the query behavior of your application nor the size of the data.

So the tool is for creating and maintaining the relational model. The indexes are not part of that; indexes are part of the tuning kit available to you inside the RDBMS, and which you use when you see in production that some queries are less optimally performing. In our runtime we'll be adding additional tools in v4 to tweak queries more (like hints and caching) on the code side.

Or should I use a tool like xCase to do that and use the reverse engineering functionality of LLBLGen?

You don't need to fall back to xCase for the model. Just create your DB and maintain it from the model in the designer. For indexes, you have to analyze what's going on at runtime in your application: which queries result in a table scan and therefore benefit from an index: there you'll add an index. SQL Server has tools which advice you where to place indexes, based on queries: the Database Engine Tuning Advisor. This tool analyzes in real time where you can add indexes, where you might want to apply partitioning etc. based on the usage of the database by your application.

This greatly helps getting insight in where you really need to place indexes and where you really have to apply other tuning options, instead of placing indexes at places where they might not be necessary.

Thank you for your answer.

Now I´m waiting for v4 ;-)