[quote=economist;35422101]Причина - высокая интероперабельность решений на макросах. Это когда большая задача легко и логично делится на кусочки, методом "лоскутной" автоматизации множеством людей пишутся макросы для себя [/quote]
Печальный опыт показывает, что чаще "множество людей" только мешает. Пишут кое-как, отладить что и как работает неправильно очень трудно. Лучше самому делать работу.
История из жизни. Наша контора делала для Китая кой-какие железяки и программы для обработки сигналов от нмх. Был провелен эксперимент, а при обработке выяснилось, что координаты корабля, таскавшего излучатель были измерены относительно чего-то. Мы им шлем запрос - нет ответа. Шлем второй - нет ответа. Вскрытие показало, что китайцы исправно слали данные. Но наш начальник, как гордая птица, не принимал emailы, а поручил девице секретарши. Которая напутала с сортировкой писем.[quote=КК СПД;35427732] множеством людей пишутся макросы для себя [/quote]
Лучше когда один человек пишет почти всё сам. Но зная, что уже есть, берет правильные инструменты. Или делает их сам. У меня такого добра оеоло 200кБ. Чего стоит преобразования адреса к стандартному виду, когда есть
ул. ПушкЕнская дом 12.а кв. 34а

> Пишут кое-как, отладить что и как работает неправильно очень трудно. Лучше самому делать работу.

Тут значит вылезает усе в белом unit и интеграционное тестирование. Но да в краснодыр оно придет еще лет через 10 т.к. это вам не снежный барс - культуру программирования в ящике не привезешь.

Marr - а сейчас вообще спрос на мультиспецов. Программисту 1С, без знания им предметной области (бухучет и налоговый учет) - будут платить не 40 а 25 тыс. руб. Web-программисту, слабому в дизайне/работе с графикой - не 30, а 20, администратору сети, без знания офисной COM-автоматизации и пользовательских скриптов - не 40, а 20...

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

43) это потому что ведь бизнес мелкий. Если бизнес покрупней вырастает, то там уже требуются узкие спецы высококлассные.

Marr - не соглашусь: даже в среднем бизнесе (это где выручка до 35 млрд. руб. в год) - узкий спец типа "сисадмин" не получит ЗП больше 40 тыс. руб. А вот если у него есть управленческие навыки - он может стать руководителем какого-то проекта автоматизации и получить солидную прибавку к ЗП либо премию, эквивалентную 1,5-ному увеличению ЗП на "горячую пору". Просто "винтики" тоже нужны, но на 10 винтиков нужен хотя бы один "гайковерт", который будет качественно менять работу, так сказать "эволюционировать" бизнес-процессы.

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

А много ли у нас в Краснодаре средних и крупных бизнесов? Кроме Тандера.

Ну вот, диспут ушел в совершенно другую сторону. Вот пример для зачинщика
---
[quote=КК СПД;35062842]Нет, если почитать внимательно техзадание, то очевидно,[/quote]
Иду на гуглю "деловая графика в excel"
нахожу 163 000 результатов. Например
[url]http://festival.1september.ru/articles/592609/[/url]
"Деловая графика в MS Excel. 9-й класс
Бадамшина Галия Габдульзяновна, учитель информатики и математики
Разделы: Преподавание информатики

Цели урока:
Показать возможности MS Excel для наглядного (графического) представления числовых данных.
Научить строить диаграммы различного вида."
---
Так что много чего можно найти, вопрошая гуглю.

economist - " а сейчас вообще спрос на мультиспецов.."
Позволю себе с Вами не согласится. Спрос на мультиспецов исключительно в мультибизнесе. К примеру, в мультиторговле, когда сегодня бананами, а завтра двигателями. Тогда, действительно, да. Один макрос меняем на другой - и вуаля. Зачем нам программер-прикладник? Просит много, да к тому же и не в теме. Даже слово "маржа" через "у" произносит. Но не все же у нас мультибизнес. Есть много задач, где решения на экселе приводят к непредсказуемым последствиям в виде невозможности дальнейшей поддержки такого "агрегата". Потому как макросов много, а народ меняется. Ну, Вы меня понимаете ;-)

AlienX - в 90-х на макросах в Excel была написана биллинговая система нехилого впоследующем сотового оператора Vodafone, а также процессинговая система дочки Citybank.

Что придало смелости акционерам выбрать "решения на экселе"? Думаю, банально большое число VBA-программистов, неизмеримо большее, чем прикладников. И многие из этих VBA-шников были профильными управленцами, формирующими техзадание профессиональным прикладным языком. Понятно что потом все это переписали. Но в качестве старта - это было здорово.

Кстати, советское высшее образование было именно "мульти-", толковый выпускник отличался чрезвычайно широким кругозором и знаниями, позволяющими смело браться за любую работу. Имхо, сейчас "высшая школа" в 7 из 10 случаев выпускает примерно вот таких спецов-олегов (цитирую чужой стишок-пирожок):

олег за все берется смело
все превращается в г-нo
а если за г-нo берется
то просто меньше тратит сил

То есть вы предлагаете автору топика начать с экселя, а потом переделать, если будет необходимо? Я Вас правильно понял?
Об образовании речи не идет, здесь я с Вами полностью согласен. Но при всех прочих равных Вы возьмете на работу мультиспеца или специалиста с опытом в нужной Вам области?
По теме - ИМХО данная задача все же больше в сторону нормальной СУБД смотрит. А какую именно СУБД и язык предпочтет автор топика - решать ему.

AlienX - да, вы поняли меня правильно. Задача автора настолько скромна, что потраченные человеко-часы на написание постов в этой ветке уже обеспечили бы ее решение, но только, опять же, на базе Excel.

За это время "нормальную СУБД" удастся только прототипировать и создать (пустую). А вот задачу импорта неструктурированных данных, да еще и в СУБД - можно потом решать очень долго и нудно.

Я сам тоже когда-то любил давать "правильные советы" (будучи консалтером/экспертом), пока сам не стал внедрять то, что советовал. И любимый инструментарий у меня быстро поменялся. Теперь там много opensource и да, ...популярных решений, типа Excel (в без промаха бьющем расчете на то, что "красивости" спокойно доделают за меня моя команда или люди заказчика). В 50% прототипирования ТЗ у заказчика в Excel - на нем и останавливались (точнее на варианте Calc/Excel, особенно если рабочих мест - тысячи).

В России "гигантомания" и традиции "народного распила" финансирования - выродились сейчас в засилие монcтруозных платных решений (SAP R3, Галактика, УПП +, железо на все это), даже в тех проектах, где достаточно Excel или вообще бесплатного OpenOffice.

Причина есть еще одна - неведение и воинствующий дилетантизм (ламерство). 9 из 10 человек знают, что "макросы с свободных офисах не поддерживаются, а документы открываются криво" - сами даже не ни разу попробовав это проверить. Оно и понятно - ведь они не используют автоматизацию макросами вообще, а представление о "сложноформатированных" документах у них исключительно на основе опыта открытия скачанных с вирусней и безграмотным форматированием рефератов из сети Интернет.

Кстати, как только у автора топика число анкет вырастет с 500 до 50000 - в Excel можно просто не хранить сами данные, оставив всю бизнес-логику. А сами анкеты "уволочь" во внешнюю СУБД любого типа (Access, DBF, SQLite, MySQL итп). В Calc - аналогично, но можно сделать еще проще - "не выходя из пакета" задействовать прекрасную во всех смыслах встроенную СУБД FireBird, которая нравится абсолютно всем :-))

Хм..Но ведь даже для анализа вышеозначенных анкет данные, так или иначе, все же придется структурировать. Тогда, в таком случае, зачем "страдать"? Быть может, с этого и "начать"? Хранение данных - в БД, а анализ в эксель. Об этом было сказано ранее. Разве нет?

AlienX - "из пушки по воробьям" - это так по-российски.

Вы не поверите: Excel - лучшее программное средство для структурирования неструктурированного. Я бы хотел поглядеть - как будут UPDATE-ами править СУБД на предмет неправильного написания тех же ВУЗов или адресов. Да банальная секретутка с минимумом знаний вычистит в Excele с помощью автофильтров и автозаполнения всю такую "базу" за три дня.

И хранить 500 строк х 50 текстовых полей Excel вполне в состоянии. Как и 50000 х 500, только комфорта будет чуть меньше (время отклика вырастет до 5 секунд).

Для себя я опытным путем определил стартовый рубеж, после которого нужно сразу браться за СУБД: 15000 строк х 50 полей. Гонять СУБД на меньших объемах - это тешить себя осознанием правильного "программизма". Только это контрпродуктивно.

Нужно наоборот - делать в чем проще (Excel). Ведь потом, при росте объемов анкет - наверняка выяснится еще кое-что... Например, что здесь нужна не СУБД, а свободная или платная HMR-система, заточенная на сабж.

Access

оживлю обсуждение
[quote=economist;35406499]На Excel/Calc есть автофильтр - который вам в списке выбора с чекбоксами покажет две похожие, но РАЗНЫЕ строки: Иванов Иван Иванович Иванoв Иван Иванович И это вычислит обычная дуреха/бухша, коих в избытке в любом офисе.[/quote]
Сколько дурёх надо, чтобы сравнив две базы, созданные в разных конторах разными дурёхами, что Варвара Петренко это на самом деле лицо кавказской национальности Анвар, каковой вступил в брак с женщиной Петренко и взял её фамилию.
Недавно вытащил из Современный толковый словарь парсингом 26М текста японские слова.
время обработки 0,65811 секунд.
[quote=economist;35731018]А вот задачу импорта неструктурированных данных, да еще и в СУБД - можно потом решать очень долго и нудно.[/quote]
Никоим образом. Посмотрев, какие есть значащие поля и чем они обрамлены, составляется конечный автомат для разбора исходных данных. Они распределяются в справочники и собственно нормализованные таблицы. Вот и всё. Используя IBExpert база создаётся лёгким движением руки.
[quote=economist;35731018]За это время "нормальную СУБД" удастся только прототипировать и создать (пустую)...
засилие монcтруозных платных решений...
в Excel можно просто не хранить сами данные, оставив всю бизнес-логику. А сами анкеты "уволочь" во внешнюю СУБД[/quote]
Отнюдь.
1 Как то я создал прогу для работы с данными иерархических объектов, причем были данные типа "факт" содержащие когда, где, что, сколько, цена... При добавлении новых сущностей автоматически создавались заготовки триггеров и хранимых процедур. Скрипт длиной 18000 символов
2 простая база данных склад с со справочником товаров, товарами, накладными и остатками 2304 символов.
Поскольку есть транзакции, то работа многопользовательская, целостность данных поддерживается СУБД. Хотя очень редко задумчивый пользователь получал сообщение: извините, но товар уже куплен.
Бизнес-логику надо делать на СУБД, как хранимые процедуры или пользовательские функции.

x_05772 - поначитавшись таких постов про IBExpert и бизнес-логику в СУБД для 500 анкет - автор топика удавился и забросил идею. Браво, товарищи! Благодаря нашей помощи - скромный проект автоматизации хранения и построения малой экспертной системы гикнулся впополам, даже не начавшись. Будут сидеть и в блокнотиках ставить "крыжики", ища тех кто походит.