Востребованность специалиста T-SQL в Германии.
На Access & VBA писать какую-нибудь офисную мелочь
-----
Ее, мелочь, давно пишут на .Нет и цепляют ко всем офисам.
----
В основном да, но Access еще используется, я привел ссылку на job-angebot в своем первом посте.
хранимки для MS SQL Servera.
-----
Аналогично - на .Нет пишут нужную логику обработки и цепляют к серверу. Повторюсь - не к приложению, а именно к серверу, как расширение.
Чистый Т-СКЛ пользуется всего в двух ипостатсях - ДДЛ и контроль за целостностью данных. На СКЛ-сервере, в принципе, ничего другого и быть не должно. По крайней мере все известные мне проекты, где в Т-СКЛ решались другие задачи, уже померли... Да и ДДЛ в чистом виде уже начинает отмирать - из коде фирст разруливают структуру базы...
----
Когда нужна максимальная производительность на ms-sql server-е пишутся хранимые процедуры и вью на T-SQL.
не знаем насколько обучаем GeorgF в 50-м возрасте
------
Роли не играет.
Он либо - обучаем - и тогда без разницы чему учить, либо - не обучем - и тогда освоение Аксесс + ВБА будет под вопросом...
-----
Играет. Есть сложный материал, а есть несложный. Человек может освоить не без труда несложный, а сложный может не потянуть.
достаточно ли мне для нахождения работы знаний T-SQL
шансы конечно всегда есть, но по идее довольно минимальные.
Нужен довольно большой проект, чтобы был смысл держать только специалиста по базам.
Хотя был как то проект с одной фабрикой, так у них был целый отдел который только базами занимался.
Зато ПП относительно неплохо - можно несколько курсов из арбайтсамта выбить. Думаю для Вас корочки будут совсем не лишними.
Но для начала - это язык, без разговорного совсем никуда.
чтобы был смысл держать только специалиста по базам.
Есть и ещё один вариант - отчёты. Существует отдел менеджеров, им или клиентам нужны различные отчёты за различные периоды. Есть прога, через которую в базу забивается или импортируется инфа. И нужны люди, которые на репортинговой проге готовят sql запросы и оформляют в красивые отчёты. Минимальные требования это SQL и немецкий
Нет, это инженеры/физики/химики/биологи, хорошо разбирающиеся в сути производственных процессов - т.е., технологи со специальными знаниями в данной области. По крайней мере, я видел на нескольких предприятиях подобную ситуацию (включая то, на котором работаю). АйТи практически не занимается обработкой данных, только их накоплением, хранением и доступом.
Ну физика за отчёты садить не рационально. У нас это просто обученный персонал, который не имеет особых знаний в программировании, но может работать с программой, генерирующей отчёты. Они получают задания типа "нам нужна выборка за последние 2 месяца по трем отделам по следующим параметрам..." . Ну в общем есть такая экономическая ниша, я только не знаю, насколько это распространено.
АйТи практически не занимается обработкой данных, только их накоплением, хранением и доступом.
срочно меняй все учебники по информатике и википедию!
Речь шла об АйТи-отделе предприятия, а не об отрасли в целом. Думал, это и ежу понятно, ан нет...
Обработку и анализ производственных данных (включая формирование запросов к БД, ЦОС, визуализацию) у нас (т.е., на наукоемком производстве - у соседей все примерно так же) проводят ТОЛЬКО специалисты из R&D, а не айтишники, роль которых в данном аспекте сводится к установке ПО, которое затребует специалист, ну, очень изредка - еще и консультация по SQL.
Обработку и анализ производственных данных
Все правильно. Управленцы требуют новый столбец в квартальном отчете "количество просиженных штанов на квадратный метр". Программисты закладывают логику в прогу и дополняют бaзу данных. А потом те, кто делает отчеты, смотрят, где они эти данные могут взять и хреначат красивую синию полосу через весь отчет - количество штанов. Их задача - с помощью SQL(или другой источник данных) вытащить данные и изменить отчет. А отчеты могут быть теxнически сложные. А вот понимать, что конкретно эти цифры обозначают, необязательно.
Программисты закладывают логику в прогу
Повторяю: у нас никто программистов до серьезной логики не допускает. Айти занимается организацией первичного ввода данных на рабочих местах и функционированием СУБД, причем, структуру БД определяют тоже только специалисты-производственники. ВЕСЬ АНАЛИЗ осуществляется ТОЛЬКО специалистами - включая написание кода И для обработки данных ("логика"), И для генерации отчетов (визуализация данных, вывод в заданном формате). Айтишники не имеют отношения к генерации сколь-нибудь серьезных отчетов вообще. Максимум - что-то типа месячного графика количества трудоспособных сменных рабочих для начальника участка.
Поэтому я и скептичен по поводу востребованности чистого SQL-специалиста - да, возможно, "непрофессиональный программист" сделает менее эффективно (возможно! но не обязательно!), но и эта эффективность будет достаточна для решения всего спектра задач. И отдельную ставку для очень хорошо знающего SQL
не станут организовывать.
Access еще используется
-----
Дельфи - тоже.
Причем - вакансии заявляются довольно регулярно.
Будешь рекомендовать изучать Турбо Паскаль?
Когда нужна максимальная производительность на мс-сял сервер-е пишутся хранимые процедуры и вью на Т-СЯЛ.
-----
Ну и кто же утверждает что оно будет быстрее?
Я вот могу утверждать, что при выборе из 100 спецов каждого профиля, в 80% случаев написанное расширение будет работать быстрее.
Просто за счет того, что квалификация пишущих расширения к серверу по определению несколько выше.
Есть сложный материал, а есть несложный.
-----
Сложность Аксеес вс .Нет/Джава - примерно одинаковая. Второе даже чуть проще из-за доступности информации.
Ну физика за отчёты садить не рационально.
-----
Ну Я, вообще-то, физик по одной из специальностей.
У производственников "рациональность" несколько специфическая - рассматривается с точки зрения функционирования предприятия.
Т.е. можно инженера нанять на копание канавы - медленно, плохонько, дорого, но будет делаться и будет сделано - это рационально.