Базы данных под разным соусом.

XDiaBLoEmeryБазы данных под разным соусом.
Именно БД? Ну так ведь тут нужен конкретный заказ, не просто же от балды её выдумывать...
Вопрос почти философский. Работодатель ныне пошел избалованный, такое впечатление, что специалисты ему не нужны. Так, по крайней мере, у нас на Украине. Поэтому, «спасение утопающих становиться делом рук самих утопающих» :) . По большому счету работодателю безразлично то, что ты можешь сделать или достигнуть . Ему интересно может быть только то, что ты уже сделал или достиг . Отсюда весьма не утешительный вывод, что сначала нужно завоевать себе репутацию и рекламу, добиться каких-то достижений и успехов, а уже только потом работодатель «будет посмотреть» нужен ли ты ему такой красивый? Я не беру в расчет исключительные ситуации типа блата, знакомства, родство, взятки или «оказаться в нужное время в нужном месте» , хотя бы виртуально. Если ты профессионал, то хочется, чтобы тебя ценили за твой профессионализм, а не за «умение красиво лизать задницу или передницу» :) . Так что вывод получается такой, поначалу придется пахать и пахать практически «за бесплатно». В какой области, это уже другой разговор, по сути, это вопрос данной темы. Главное, не рассчитывать на быстрые и легкие деньги («быстро только дети делаются» :) ).

Ну а если по существу, то «базы данных» это то, за что работодатель относительно легко готов платить деньги. Правда эта ниша уже сильно заполнена разными корпорациями и фирмами либо собственными программистами конкретного предприятия. Однако, не все «так запущено». Во-первых, это область неисчерпаема, а во-вторых, сейчас явно просматривается тенденция на существенное удорожание технических решений на основе баз данных. Оно ведь понятно, корпорациям ведь кушать тоже хочется, а дешевые решения их «не прикалывают». Поэтому конкурировать программисту одиночке можно будет только на ценовом поле. Скажем, на нашем предприятие, где я работаю, поступали предложения от филиала Майкрософт на Украине с предложением об автоматизации учета и т.п. Представьте, что мы бы согласились. Интересно, во сколько мегабаксов нам бы обошлось это предложение? Тут вовремя оказался я, с уже практически готовыми программами учета. Мой учет заработной платы мы внедрили на следующий месяц после моего приема на работу, а учет ресурсов (материалов, основных средств, денежных средств, забалансовых ресурсов, частично налоговый учет) через пару лет моей работы. Можно было бы и раньше, если была бы более острая потребность в этом. Сейчас мог бы внедрить и обобщающий бухгалтерский учет, но не вижу в этом особого смысла, так как заинтересованности со стороны бухгалтеров нет (их слишком много, со своей работой вполне справляются вручную и особо учиться работе с компьютером не жаждут). Фактически, у меня хорошо пошло то внедрение, за который нашей фирме приходилось ежемесячно отстегивать бабло районному вычислительному центру. Все расходы фирмы состоят только в моей обычной зарплате начальника отдела.

Сейчас, когда у меня появилось свободное время на работе встал вопрос, что делать дальше. В общем можно было бы продолжать развивать то направление, что и раньше. Но, вспомнив одно изречение американского бизнесмена, что «каждый профессионал должен существенно менять область своих профессиональных интересов каждые десять лет» , решил с прикладного программирования перейти на системный. И конкурировать с фирмами в области решений не для средних предприятий, а для крупных . Конечно, можно было бы уже сейчас разослать разным конторам свое резюме с предложением самостоятельно разработать систему учета на базе MS Visual Studio C++. Но уверен хорошей зарплаты не предложат либо скажут, когда разработаете, тогда и приходите. Так что остается только одно, разрабатывать пока для себя программу учета для крупных предприятию, относительно простую и не дорогую, без всяких не особо нужных прибамбасов и «рюшечек». Потом уже можно будет поискать хорошего заказчика, тем не менее периодически рекламируя себя в интернете.

Вот примерно тот путь, который выбрал лично я, вы можете пойти этим же путем (места здесь всем хватит), либо разработать собственный вариант успеха. Думаю, что основные принципиальные моменты я указал, поэтому интересно было бы узнать, как решают подобные задачи другие.

XDiaBLoEmery,
Есть проблема, я в учёте не смыслю.
А в нем никто не смыслит! Я, конечно, преувеличиваю, однако реальных специалистов в теории реального учета на всем СНГ считанные единицы. А те, кто силен и в теории и практике, давно слиняли на запад. Сейчас тот задают фирмы, девиз которых отделить юзверей и даже системных программеров от непосредственной работы с базами данных. Усилено культивируется миф, что базы данных на системном уровне это архисложно и общаться с ними положено только через посредников, типа провайдеров и библиотек данных, sql серверов и так далее. На самом деле все здесь сильно преувеличено с целью срубить максимум бабла с наивных пользователей баз данных. Для этого специально создаются монстрообразные программы даже там, где в этом нет явной необходимости. Скажу более, что в бухгалтерии тоже мало кто разбирается по сути, а не по форме . Например, считается, что существует бухгалтерский учет , хотя точнее говорить о методах бухгалтерского контроля государства относительно предприятий. А то, что можно было бы назвать учетом, например, натуральный учет , так об этом вообще мало кто имеет представление. В учетной политике любого предприятия должен находиться именно натуральный учет из которого уже должен следовать, бухгалтерский «учет», налоговый «учет» и прочая контрольная и управленческая отчетность. В общем, я это говорю не для того, чтобы привлечь кого-то в эту область деятельности, а для того чтобы показать, что весьма полезно разбираться глубоко в сути вещей, которые программируешь . А если ты к тому же хороший кодировщик, то цены тебе нет.

XDiaBLoЯ сижу в банке, занимаюсь поддержкой базы данных пластиковых карт, и написанием приложений, которые с ней работают.
Ну вот, кое-что о базах данных уже знаешь. Чтобы знать больше, неплохо познакомиться с базами данных ДОСовсих времен, тогда они были честнее по отношению к пользователю. Очень часто старые версии много лучше новых. Например, из всех существующих Access’ов лучше всего Access-97. Из всех ядер 1С лучше всего ядро 1С77, из MS VS C++ лучше всего 6-я версия и т.д. и т.п. И главное, не очень доверять документации фирм монополистов, там правда, но далеко не вся правда.

XDiaBLoEmery,
Я не кое-что знаю о базах данных, а довольно много, хотя и далеко не всё. И что вы имеете в виду под досовскими базами данных? .dbf-файлы? Так я писал для них программы. Конечно основное с чем я работаю, это Оракл, но бывает приходится и в другие области погружаться.
Ну, прежде всего Clipper 5.x под MS-DOS, сейчас распространен его аналог xHarbour – http://www.xharbour.org с открытыми исходными текстами под Win32 и Linux. Затем dBase, FoxPro v. 2.6a под MS-DOS и т.п. В общем, если считать Оракл калькулятором, то Clipper будет таблицей умножения. Те, кто имел дело с Clipper’ом гораздо лучше понимают внутреннюю логику баз данных и ее суть. Clipper это тот же Си с библиотеками для работы с dbf файлами. Самое смешное, что там не было даже оператора Select SQL, но было Create Table, Insert, Delete, Locate, Find, Index Оn, Seek и т.п. Для получения запросов организовывались банальные циклы, поиск по ключу, индексация и прочее. Подозреваю, что современный SQL произошел отсюда сначала как функциональный макрос, оптимизирующий шаблонные операции выборки данных с помощью циклов, индексов, поиска и т.п. Просто знать эту технику очень не вредно, хотя никто не запрещает пользоваться современными базами данных, тем же VFP, MS SQL Server, Oracle, DB2 и т.д. Совершенно не обязательно возвращаться уже на Clipper или переходить на xHarbour. Гораздо лучше просто попрограммировать чуток базы данных самому. Просто чтобы прочувствовать их изнутри. Это что касается внутреннего механизма баз данных. Относительно организации учета на базах данных – это уже другая песня. Этому трудно научиться, хотя бы потому, что учет на уровне программирования, методологии и организации мало кто знает хорошо. Литературы тоже не очень много. Например, когда я прогуглил запрос «Критика бухгалтерского учета», то наткнулся на докторскую диссертацию одной тети-экономиста, посвященной, в том числе и этой теме. С критически мышлением, она начала вникать чуть-чуть в суть дела, вот если бы она была еще программистом, то цены бы ей не было. Могу сказать, что я фактически работаю сейчас над этой темой, но до собственных книг в этой области мне еще далеко. Тем не менее, я начал публиковать цикл статей с программным кодом, цель которых написать собственное приложение, с объяснением всех принципиальных моментов, в котором будет как собственная поддержка баз данных формата VFP-9, так и использование рантайм библиотек vfp9t.dll / vfp9renu.dll напрямую, что, обычно, никто не делает. В общем-то, могут быть и другие библиотеки баз данных, сейчас это не важно. Более того, можно расширить формат dbf на случай 8-байтового указателя, чтобы иметь возможность адресовать более 4.5 GB и работать с собственным форматом данных любого размера. В своей очередной статье я готовлю раздел: «Альтернатива SQL запросам» . Т.е. в некоторых случаях можно работать с огромными базами данных, в которых все предсказуемые SQL запросы могут быть заменены своими эквивалентами, типа как в Clipper’e, так чтобы не терять существенно в производительности. Главное здесь найти наилучший алгоритм создания и модификации CDX файлов, о чем есть моя статья здесь.

Сахават ЮсифовEmery,

Тебе надо не учет писать на коболе, а переквалифицироваться в полутехнического писателя. Больно грамотно излагаешь суть - которой нет. :)
Гораздо интересней было бы услышать возражения по существу, просто сказать «Борис, ты не прав» – много ума не надо :) . А на счет «полутехнического писателя» ты, пожалуй, прав – это можно.

XDiaBLoEmery,
Я думаю всё же я лучше буду изучать современные СУБД, Oracle, MS SQL Server, Postgresql, Berkley DB, MySQL. Они больше пригодятся. А старые иерархические и сетевые СУБД, устарели, и в принципе можно прожить и без них.
Все правильно, так сейчас все делают. Если понимаешь суть баз данных, то тогда нечего ворошить старое белье. Но если остаются непонятки, то главная наводка, что создаются они сознательно производителями современных баз данных, чтобы отдалить программиста от ядра базы данных. Если есть желание разобраться в проблемах, то весьма хорошим способом могло бы стать решение вопроса на чистом С++ & (MFC | Qt) поднятого в теме «Несложная специфическая БД для 200 млн записей.» . Задача эта относительно не сложная, на пару месяцев можно справится, зато эффект в понимании работы баз данных был бы колоссальный. По крайней мере, я этот вопрос взял себе на заметку, когда подойдет к нему очередь, то займусь им.

BIONСсылочки на ваши труды можно?

Вот, специально ради вас опубликовал «Альтернатива SQL запросам» :) .

Guest_09Было бы интересно почитать. Если можно, дайте ссылочку на эту диссертацию или хотя бы назовите и.ф.о тети) не могу найти...(
К сожалению, ссылку не сохранил и фамилию не помню. Искать нужно заново, а у меня сейчас другие интересы. Помню только, что полный текст диссертации был недоступен (ныне эти услуги платные), опубликовано было что-то типа краткого реферата по диссертации. Я обратил на нее внимание только потому, что «докторша» пришла примерно к тем же выводам относительно бухгалтерского учета, что и я, т.е. что «современный бухучет это не метод учета (несмотря на открытие Лука Пачолли), а метод контроля». Кроме того, она там критиковала методику «бухгалтерского баланса» и много еще что. Впрочем, она была умеренной, типа, «да плохо, но если сильно надо, то почти хорошо» :) .