Это учебный проект, осваиваю android-разработку. Было еще желание сделать нечто, что не стыдно показать на собеседовании, но с такими "успехами", понятно что эта цель не достигнута. Так что это не хобби и не желание заработать, это желание сделать приложение, которое можно показать работодателю. Нужны хорошие оценки и аудитория.
Есть вечные профессии, которые не подведут никогда типа стоматолога. Есть такие, куда и за большую зарплату лезть страшно, а дураков, кому не страшно не пустят - типа капитана воздушного суда. Берите профессию, где нужны знания, опыт, добросовестность и есть большая ответственность и/или риск - это будет, то за что хорошо платят.
IT просто в полувековом восходящем тренде, повезло нам.
Anton, из теории ничего посоветовать не могу - видел это всё на работающей системе. Суть там в следующем:
1. Дополнительные реквизиты. Есть отдельная таблица такого вида: table-name, surrogate, rec-code, rec-val. Она позволяет на любую запись любой таблицы завести дополнительный реквизит. Например есть таблица person, в которой, как положено фио, дата рождения и т.д. И тут вам говорят - надо новый реквизит умер/жив ли этот человек. Стандартно решать - это надо реструктурировать person, хранить кучу true, ведь как правило люди в базе живые еще. А вот с таблицей доп.реквизитов ничего этого делать не надо, просто если человек умер создается запись в таблице доп.реквизитов: ("person", "6666", "dead", "true"). Понятно, что кроме самих значений хранится реквизитный состав - какие есть доп.реквизиты в системе. К тому же эти доп.реквизиты на самом деле цепляют даже не к таблицам, а к классам - об этом ниже.
2. Метасхема. В в каждой таблице есть поле class-code, и есть иерархический справочник классов. Например изначально был просто некий договор loan, потом захотелось вести карточные договоры - делают подкласс loan_card и навешивают на него доп.реквизит card-num - номер карты.
3. Есть еще пара трюков - писать долго.
Понятно, что для удобной работы с такой структурой написаны быстрые библиотеки, которые сами склеивают данные из разных таблиц и ты видишь объект как единое целое.
В результате, например, на базе бух.системы мы с ребятами с пару недель смогли соорудить: сейфинг, CRM и много чего еще, не меняя структуры базы данных.
Василий Мельников, видимо, речь о программистах. В своё время я оценивал задачи по трудоёмкости в человеко/часах - сколько бы у меня самого ушло на выполнение. Тогда выроботка = трудоёмкость выполненных задач, а затраты - время.
Подозреваю, что детали транзакционности сильно привязаны к реализации в конкретной СУБД, поэтому надо искать по каждой СУБД в отдельности эту информацию.
Я бы в ответ сделал встречное предложение. Вы хотите сэкономить на оплате НДФЛ и ФОТ. Это некая сумма Х. Давайте эту сумму поделим пополам - половина вам, половина мне в виде прибавки к з/п. Так будет честно.
Антон, если бы я писал программу - обязательно бы сделал перебором, потому что алгоритм будет потом проще понять и адаптировать под любые цифры (я бы сразу написал в общем виде, с любым количеством цифр и на любом табло). Но если сдать надо именно МАТЕМАТИКУ, то тогда да - надо научно.
