KD9KC’s topic “SOTA surpasses IOTA” became somewhat by diverted examining the authenticity of claimed chaser/activator records resulting from the lack of confirming asterisks which service has been (temporarly) been suspended. (BTW. Frenchmen have a saying: there’s no more permanent state as temporary is! Am I right, Alain - F6ENO? :-))) ) As far as I can concern, this is an issue worth of discussing, therefore I started the present new topic.
I am replying not for X or Y but in general to the debating community. I am not going to blame anybody, who have made their best for our community up to now. However I had been earning my money for over 2 decades from IT system analysis, system design and programming, thus I assume that some of my ideas are worth of considering.
The present solutions really worked (more or less) fine during the passed years… in small DBs with a low number of users. However, by today, both SOTA community and SOTA QSO DB grew to the extent what can not be managed by means of amateur way of thinking and amateur solutions. And what is more, time passing the larger the DB grows, the worse the circumstances will become, because the time and processor power consumption (demand) of processing does not increase linearly with the size of the DB but exponentially! This is predictable, unless we change to professional way of thinking!
What do I mean? There are easy and effective ways as well of obtaining a result. However easy solutions, preferring the ease of coding and testing to long term considerations demand far more cost in general. Nevertheless the seemingly complicated and seemingly more time consuming solutions, may pay off considering long term aspects.
What is my problem? Whenever I start a query (e.g. to see my chaser log), the entire DB is browsed and each QSO is checked against the activator’s log just in order to add that tiny little asterisk… Supposing that I am fool enough to do so a hundred times in a row, that process is re-executed a hundred times and provides me the very same result at a cost of tremendous processor power, slowing down the response of other users! This is absolutely useless wasting of processor power, as it merely results of an operation focusing on the simplicity and ease of data entry forgetting about the costs of the output. (Let me put it again, this way of program organising may have been reasonable and acceptable in case of a low number of users and records.)
What could be done instead? Well, supposing that the data entry (processing of uploaded files or manual entries) were a bit more complex, as a return value the output could be got far easier and faster! The data entry procedure obviously includes several checking procedures, e.g. checks the summit reference specified in the record against the data stored in the reference DB. Why not check the confirmation of the QSO from the partner station as well? Why not adding a “CFM” field into the QSO records and fill it with the good old * or with a Boolean TRUE value in both party’s records, supposing that the coincidence of the rest of the QSO information justifies it? (Of course the one who uploads his data firts, won’t find any confirmation, but the second will. N.b.: Of course this kind of processing assumes that deleting the record from one partner’s log shall also influent the other partner’s record as well, that is delete the * or change TRUE to FALSE value!) Of course this takes a few more instruction, but it fairly pays off!!! Just because there is no need to execute any QSO confirmation checking any more when you ask a “Chaser log” and this obviously accelerates response saving processor power.
This was only a simple example on it, how important the farsighted system design and programming is and how much it influences performance, processor demand, etc.
73: Jóska (M.Sc. E.E.), HA5CW