Hello Alex!
My suggestion:
If there is a system of working witth a fixed number of columns with each version and really that GT uses a fixed number of columns and remaining the users customizes, that would lead to a better pacing with the development. Otherwise its a real headache to keep on changing formats and fields.
Lets say, GT uses in the version of Links SQL 2.0 - 2.0.xx only 40 fields in the entire database. So mark to end part of version as 2.0.3.40 to be able to identify in each version the number of fields.
Further, keep couple of fields as a reserve for the future development as a default. By doing so there will be no field conflicts for a while and the extra field if it is in there empty will no occupy a lot of space and even if it does then I would compromise as compared to the entire hurdle of import and export problems. The export and import has never ever worked so satisfactorily if there are some little minor difference somewhere. Hence the suggestion would help a lot.
What I mean in a nutshell is to have really a freeze of fields for a particluar version series and not a constant pain of mind blowing field conflicts.
Further, if the default installation also offers a default number of some X fields will also give some generalization of customization. Lets say GT uses always 40 fields which includes five extra i.e. two in the category and three in the links table, and further there is anathor five default for the user, then the entire programming of scripts will be aware of the extra fields and there shall be not much conflicts.
The advantage.
Lets say field Column36-40 are for the users as extra.
Then there can be also tags that be produced everywhere later in the templates allowing the customization easy. The names can be defined in the Links.pm and those five names can be reflected everywhere, eventhough the names of the columns are Column36 upto Column40 in the database and not their respective names.
Hence the default installation takes care of some fixed predetermined fields number and this can be specified during the installation. By doing this the import and export can be easier, I beleive, as the default values are already known basically as programmed.
The idea is to have a default installation with some default but extra fields that the GT and user uses for reduction of future problems.
My suggestion:
If there is a system of working witth a fixed number of columns with each version and really that GT uses a fixed number of columns and remaining the users customizes, that would lead to a better pacing with the development. Otherwise its a real headache to keep on changing formats and fields.
Lets say, GT uses in the version of Links SQL 2.0 - 2.0.xx only 40 fields in the entire database. So mark to end part of version as 2.0.3.40 to be able to identify in each version the number of fields.
Further, keep couple of fields as a reserve for the future development as a default. By doing so there will be no field conflicts for a while and the extra field if it is in there empty will no occupy a lot of space and even if it does then I would compromise as compared to the entire hurdle of import and export problems. The export and import has never ever worked so satisfactorily if there are some little minor difference somewhere. Hence the suggestion would help a lot.
What I mean in a nutshell is to have really a freeze of fields for a particluar version series and not a constant pain of mind blowing field conflicts.
Further, if the default installation also offers a default number of some X fields will also give some generalization of customization. Lets say GT uses always 40 fields which includes five extra i.e. two in the category and three in the links table, and further there is anathor five default for the user, then the entire programming of scripts will be aware of the extra fields and there shall be not much conflicts.
The advantage.
Lets say field Column36-40 are for the users as extra.
Then there can be also tags that be produced everywhere later in the templates allowing the customization easy. The names can be defined in the Links.pm and those five names can be reflected everywhere, eventhough the names of the columns are Column36 upto Column40 in the database and not their respective names.
Hence the default installation takes care of some fixed predetermined fields number and this can be specified during the installation. By doing this the import and export can be easier, I beleive, as the default values are already known basically as programmed.
The idea is to have a default installation with some default but extra fields that the GT and user uses for reduction of future problems.