Should Gen allow database-specific settings ?

Following on from the last post on database independance, it got me thinking…..

 Since there are DB2-specific settings available in Gen could we not have Oracle or Datacom settings (or any other database that Gen supports ?) 

What settings would we need ?

 Well…..

…as a for instance, very often IU have had to hack some code to allow an “explain plan” to be set for a specifi piece of SQL which we perceive to be non-performant – I’d like to rebuild a piece of batch or online code with the ability to switch on or off this feature for a specific READ statement when I build – the syntax may be different for each database, but the generation options I select lead to database-specific pieces of SQL being generated anyway depending on the target database – so why not this ?

 … as another for instance,  when I am setting up a new entity in Gen and need to retransform to get the DDL, I always have to have my DBA’s modify the DDL to add in their clauses for creating the corresponding table in a certain tablespace or a specific disc for optimum performance – similarly with indexes, we have to amend the DDL to allow for specific fragmentation strategies.

It would, I admit, lead to an issue when changing database technology, but then, the planning for disc layouts and index structures HAS to be redone anyway, so why not capture that information in a Gen model and have the whole system self-contained.
This could be seen as a counter-argument to Gen’s flexibility in that system-specific settings and physically-dependant settings are in the Gen model, but at least all of them are then in the same place. Any time a relayout of the database on the physical discs is carried out for reasons of performance or new hardware procurement, then the Gen model is changed and retransformed and the new DDL can be produced.
My point is that ALL aspects of the system can then be controlled from within the model.

It would be interesting to hear feedback on this, as it is a continuing discussion within my own organisation as to where this “database stuff” is best kept…….