Hi Monks, I am developing a website from scratch which will hopefully have plenty of activity some time in the future after it goes live. Although I am still developing it on Windows, I will migrate it to Linux/Apache, with Perl and Postgres completing the rest of the picture before and after migration. I am inclined to avoid PHP for performance reasons.

While loading the database with some initial reference data (about 1GB), using one-off code that got fixed as I went along, I somehow managed to "lose" some PK values, because sequences do not roll back if accessed with nextval.

But it occurred to me that when the system goes live, it will need to manage deleted values. Although I was careful to use bigint for PK values where necessary, I don't want to have the situation where the PK values stay fragmented and increase fragmentation over time.

It was at this point that I realised I needed DBIx::Class, otherwise I would have layers of raw SQL hiding in any homegrown DBMS/Perl framework and that had to be avoided at all costs.

So I am at the point where I have installed DBIx class and feel obliged to determine the rest of the architecture (MVC perhaps) and at the same level of detail, before writing any methods to dynamically defrag my keys (probably through use of an idpool table/class where inserters will look before calling nextval if nothing is in the pool for the table).

It becomes clear that the defrag code belongs in the "Controller" part of the framework. But having never built a Controller before, I am hoping for advice on what the classes should look like in there, e.g. should I have a dbController class that uses methods in DBIx. Should it inherit from the Schema and/or should I have some kind of parent-of-all utility class? I am keen to make a good choice now rather than have to make fundamental architecture mods later. Many thanks in advance,

Simon