Чета все молчат. Никому не интересно?

Справедливости ради - в том году ФПЕЧа не было, а наш форум отжог по полной всеми 4мя командами -)

Терь к делу. Идея отдать разработку фрилансерам мне в данный момент кажется утопичной, однако что-то делать нужно. Понятно что ни у кого нет времени, но если двигаться маленькими шажками то можно в конце концов соорудить что-то удобоваримое условно говоря к концу след весны а то и раньше. Под это дело было бы неплохо выделить отдельную тему а то и чем черт не шутит раздел на форуме, и основным решением я вижу совместные обсуждения основных деталей реализации, особенно если что-то вызывает вопросы технического и/или понятийного плана. Как я уже говорил, некоторые наработки у меня уже есть, но они нуждаются в небольшой переделке, чуть более большой доделке и последующем переносе на более подходящий сервак БД.
В данный момент отметил бы следующие вопросы, пусть и немного в кучу, важные для понимания того, что мы хотим в итоге иметь -
1. Тип доступа к серверу БД (Web / клиент-сервер)
2. Какой сервер БД будет использоваться? (исходя из 2)
3. Основные задачи, охватываемые проектом
4. Детализация данных
5. Среда разработки для клиентского ПО
6. Если нужно - аутентификация и права доступа

начну пожалуй сам.
1. Тип доступа к серверу БД (Web / клиент-сервер)
В данный момент склоняюсь все же к версии с клиент-сервером т.к. это видится проще, тогда имеем только администраторскую часть приложений. Альтернатива - веб, тогда кроме админки нужен еще интерфейс а-ля прогноз.орг или хотя бы sbz.ru для того чтобы пользователи могли САМИ вбивать туда свои прогнозы (ну или админ за них, если они сильно торопятся..). С вебом кмк мы рискуем завязнуть надолго, хотя возможно я просто не шибко в теме т.к. по странному стечению обстоятельств почти вся веб-разработка всегда проходила мимо меня -)
2. Какой сервер БД будет использоваться? (исходя из 2)
Основное здесь - будет ли это некий централизованный сервак, размещенный на каком-то инет-ресурсе, с которым теоретически смогут работать все, или же будет просто один или несколько локальных экземпляров, с которыми будут работать администраторы-организаторы. Исходя из этого надо буит выбрать базку какуюнить халявную.. ) На первых порах придется юзать второй вариант, однако все-таки при выборе самого сервера лучше этот нюанс учесть чтобы не было потом траблов с возможным размещением.
3. Основные задачи, охватываемые проектом
Здесь на самом деле нужно сразу принять одно важное стратегическое решение - или мы затачиваем проект исключительно под ФПЕЧ и ему подобные турниры, или более скрупулезно подходим к проектированию БД с тем чтобы была возможность вести в рамках проекта и иные турниры, существенно отличающиеся по методам подачи прогнозов и методам подсчета итогов (например, те же троица, итоги ЧР, марафон). Как и в предыдущих пунктах - каждый из вариантов по-своему хорош и по-своему плох. Вообще я все-таки за второй вариант, за бОльшую гибкость одним словом)
4. Детализация данных
Что тут имеется в виду. Можно просто хранить в базе строчку "Боруссия Д - Нюрнберг" как одно из полей сущности "МАТЧ" и не заморачиваться по этому поводу, а можно создать справочник стран, справочник городов, справочник клубов, справочник соревнований, и в конце концов добавить в сущность "МАТЧ" ссылки на сущности "КОМАНДА"(хозяева) и "КОМАНДА"(гости). Первый случай - самый простой, требует минимум администрирования. Второй случай хорош тем, что можно будет собирать достаточно любопытную статистику по прогнозированию той или иной команды (это, кстати, куда интереснее подходит не для ФПЕЧа а для прогнозирования целого чемпионата (например, России)) ну и еще всякие фишки. В Оракле, кстати, щас реализован именно 2й вариант. Говоря языком спецов по СУБД, речь идет о выделении сущностей и нормализации.
5. Среда разработки для клиентского ПО
Тут понятно многое будет зависеть от п.1 и личных предпочтений разработчика)) Себя я больше вижу как архитектора БД и разработчика серверных программных единиц, так что этот по этому пункту пока промолчу..)
6. Если нужно - аутентификация и права доступа
Понятно что это нужно только если все-таки будет веб-доступ, и то не сразу. Однако все же предлагаю подумать над этим, когда наступит бОльшая определенность по остальным пунктам.

Доклад окончил -)

Понятно гибкость лучше, но есть еще один вопрос - насколько быстро мы хотим все это получить? Если быстро, то гибкость нужно отбрасывать и делать жесткий конструкт под ФПЕЧ, если готовы ждать, то конечно лучше заморочиться.
Блин, надо порыться в памяти, вспомнить все чему учился

+сто тыщ мильонов

Ну раз я стал тут отписываться значит мне это интересно

Вообще считаю что банальный парсер прогноза не так сложно написать - там вощемта кроме распознавания счета ниче не нужно при фиксированной программе.. Контрол Цэ - Контрол Вэ, кнопочку "Обработать" тыркаем - и все дела. Тут кмк вообще достаточно одной процедурки в БД с параметром типа текст (ну, CLOB например если это оракл..) + вспомогательными параметрами - идентификаторы участника, соревнования, тура соревнования. А как это делать - хоть в лоб, хоть через регулярные выражения, кому как нравится..)

А дельфи вообще живо еще?.. ) Я мож для поднятия скилла на сишарпе поупражнялся бы вместе с девэкспрессом, но пока лишь в теории.. -) Чето начинал делать помнится как раз под эту базу, но потом забросил потому что долго выходило и по-бырому на оракл формс сварганил.. -)

+1

Идея очень понравилась, поддуржу рублем-)

Отредактировано mavrus (2011-09-29 20:27:32)

Давненько уже

Я согласен, это было бы круто. Но пока - сложно. С готовой базой можно будет замахнуться, но кмк начать надо с того, чтобы автоматизировать сбор прогнозов, подсчет и выдачу результатов.

Это задача довольно простая для знающего человека. Насколько я понимаю по откликам на мое предложение сделать это своими силами попросту некому... Насчёт готового - не знаю... Как вот Борис проги собирает со Спортдозора? Может у него спросить?

Не, я круче автоматизацию хочу. Задаёшь ссылку на тему, куда народ фигачит прогнозы на каждый тур, а прога автоматически перебирает все сообщения в теме, парсит от кого, счета и загоняет в БД.

Более чем живо Вся контора наша работает на Дельфи Но если ты будешь прогать - нет вопросов и по сишарпу

Давайте, давайте, я обеими руками за!

Ну это уже следующий шаг, тем более парсер нужен энивей..)

Угу, тока то что ты хочешь - это по большому щщету веб-сервис занимающийся html-парсингом, и в рамках этого все равно отдельным пунктом пойдет определение необходимых параметров прогнозных сообщений (тот же участник + текст прогнозы)  с последующей обработкой прогнозного текста - что кмк является отдельной независимой задачей, не зависящей от того же веб-контекста форума и прочего..) И реализовать ее отдельно можно раньше чем веб-сервис, я об этом.

Да, Саня, вопрос такой еще будет по поводу майскуля и дельфей - гм.. ты откуда их брать собрался? )) и вообще есть какаянить возможность без палева скачать для некоммерческого юзания или только гм.. обходными маневрами?.. )

Это MySQL Workbench. А ты возьми PowerDesigner - он и Oracle жуёт!

А у меня тут нет ничего про матчи прогнозистов, подсчет очков, и т.д.
Только основная часть по сбору прогнозов.

Что касается мускуля - конечно есть, вот MySQL Community Server 5.5.16
Что касается Delphi - вероятно, нет Но у меня есть 5-7 версии, мне достаточно. Могу сунуть куда

С юникодом - у версий до 6, 64-битного компайлера до сих пор нет... Но это все пофик ИМХО.

Попробуй. И жду замечаний по своей

Угу, стараюсь, но выхи были заняты а вчера освободился в час ночи и ушел спать..)
так и триальный двухнедельный период к павердизайнеру 15му завершится, нет ключика кстати?.. ))

Я не готов, напротив капитанство отдаю на ближайшие месяца два. Так-то вроде Костя собирался, поэтому и тема появилась, но теперь ему еще и капитанить придется так что есть сомнения..