guest_20040621> всю жизнь жил с 1С
Боюсь, проектированию Вас уже не научить.
Да ну не, чего вы. Человек же стремится, а это ой как много значит.
А по сути -- у вас (я уже к Хладоносцу обращаюсь) тут намешаны вопросы как из проектирования БД, так и из не связанных с этим областей (Java, веб-интерфейсы какие-то). Давайте-ка отделять мухи от котлет.
Во-первых, просто "еще одна" issue-tracking система никому, боюсь, не нужна. А что-то отличное от "еще одна" у вас вряд ли получится -- первый опыт, как я понимаю.
Во-вторых, если вы не имели дела ни с одной серверной технологией (JSP какие-нибудь, ASP или ASP.NET), то процесс познавания СУБД упрется в никак не связанный с оным процесс познания выбранной серверной технологии. А просто БД проектировать... Интересно конечно, спору нет, но потом-то что с ней делать?
Ну а в-третьих, слона надо есть по кусочкам. Если хвататься сразу за все и реализовывать все задумки, то ничего и никогда у вас не получится: любая сложная работающая система эволюционирует из работающей же простой системы. Сразу сложная система не получится.
Посему.
Если вас не пугают первые два пункта, то вот примерный план действий.
Начинайте изучать БД и -- скорее всего, параллельно -- какую-то серверную технологию. Если все же выберете Java, то надо будет для начала остановиться на каком-то одном фреймворке, а не распыляться на все подряд. Сам я c Java не работал и в этом деле не советчик, но на правах рекламы посоветую посмотреть в сторону Hibernate и Spring -- судя по тому, что эти вещи творят в .NET, в мире Java они еще похлеще будут.
Как только появится достаточно опыта, напишите какое-нибудь простенькое веб-приложение -- что-то типа урезанных версипй
Ta-Da List или
Beast . Набивайте шишки, оттачивайте навыки. Потом (если достойно получится) переведете все это хозяйство в опенсорс.
Вот тут, пожалуй, можно уже начать изучать какие-то еще фреймворки. Их -- повторюсь -- много, так что выберите основные.
С набранными скиллзами можно уже подходить к планированию и разработке вашего трекера. Но тут уже вопрос гораздо более объемный, потому что к такому ответственному делу (теоретически, эта система посложней упомянутых будет -- хотя на начальном этапе сложность может быть сопоставима) надо подходить серьезно и стараться не допустить больших ляпов в самом начале, чтобы они потом поперек горла не встали.
