Merlin писал(а):Не уверен, что это вообще задача для СУБД
именно для СУБД, дело в том, что "вводящие" вводят только нагрудный номер учасника и отсекают системное время финиша (или промежуточного КП), а всё остальное - имя, команда, время старта и т.д. берётся из базы, потом делается промежуточный расчет и текущее распределение мест, возможны ситуации, когда учасники снимаются за неправильную отметку на КП, а потом их опять восстанавливают, потому, что они были сняты по ошибке ну и т.д.
По поводу остального, предыдущая версия проги была написана давно на Clipper Sammer-87, ясно, что там и мечтать о возможностях жар-птицы не приходилось, ну и сейчас, что называется дорвался, хотелось крутизны по-полной.. Однако хорошо, что не зная броду, хоть спросил у маститых..
Евенты просто извещают комментаторов, что новые данные ЕСТЬ.
Приблизительно такая модель и была реализована раньше, так и сделаю сейчас это для проведения вполне приемлемо..
И в 1.5 и выше можно универсальные на все события. И можно их сгенерировать по шаблону, а не насиловать клаву.
Я по старинке пишу скрипты и выполняю их при помощи своей примочки, которая эксплуатирует IBEScript.. А как генерерировать по шаблону - это любопытно, проконсультируйте пожалуйста или ссылочку, где можно почитать
у комментатора вообще не должно быть на рабочем месте постоянно открытого датааваре-датасета..
из чистого любопытсва, что такое датасет я для себя уяснил, а вот датааваре, - как трактовать сей термин..
В частном случае одного комментатора было бы проще..
дык в большинстве случаев он один и есть.. просто спортивное ориентирование не есть олимпийским видом спорта, а с финансированием и олимпийских-то у нас, сами понимаете, вот и приходится организаторам постоянно прибегать к помощи дяденьки-спонсора.., а этот дяденька частенько попадается вредненький, интересуется знать как тратятся его кровные и лучшим способом удовлетворить его любопытсво и польстить самолюбие - это выделить ему отдельный ноут на котором "всё видно", а ещё лучше отдельный ноут и его другу (а как же без друга, кто ж оценит-то..), вот, собственно, где собачка порылась..
Но, поскольку в таблице событий по данному конкрентному соревнованию будут явно не миллионы записей
Пока больше 700 учасников в текущей финишной базе не регистрировалось.. И последний на сегодня вопрос: имеет-ли значение реальное количество записей в таблицах, если в каждый момент времени от сервера требоваться будет возвратить (или обработать) лишь какую-то часть этих строк (скажем 700) и вся структура базы реализована таким образом, что нужную информацию можно идентифицировать по первичному ключу. Дело в том, что помимо использования данных из базы в данный момент времени для определения победителей и призеров, ещё по итогам года считаются и рейтинги спортсменов (упрощенно это количесво набранных очков на специально запланированных вначале года так назывемых ранговых соревнованиях) для определения претендентов в сборную страны и др. Сейчас эта работа выполняется в полуручном режиме, с использованием Excel как я полагаю.. но это же КАТОРЖНЫЙ труд.. посему хотелось бы хранить в базе, скажем год, этого достаточно.. При подсчете навскидку в самой большей таблице будет до 50 тыс. записей.. Из Вашего опыта, господа эксперты, прикиньте сильные-ли ожидать тормоза в конце года на ноутбуке 1,7 МГц, 256 оперативки, 20 гиг на винте, win2000Prof (ломанный конечно) ну и FireBird 1.5.3. Конечно не вопрос сделать отдельную базу под эту задачу и туда сливать, но хотелось бы знать ваш прогноз, дабы определиться для решения других задач (зарплата, складской учет) достаточно-ли будет этой технологии.. Имеется ввиду сервер FireBird, этот замечательнейший софт, при всей своей бесплатности обладающий такими чудесными возможностями..