| 0
- 16.04.2014 - 17:27
|
Есть массивы данных по гражданам в тексте и цифрах. Нужна программа, которая поможет обрабатывать эти данные. А именно: накапливает со временем статистику по каждой отдельной анкете, выводить графики изменений, объединять группы по сходным параметрам и т. Д. Вопрос, в каком направлении искать?
    | | |||||||||||
| 1
- 17.04.2014 - 07:31
| http://habrahabr.ru/post/150109/ | | |||||||||||
| 2
- 17.04.2014 - 15:37
| EXCEL | | |||||||||||
| 3
- 18.04.2014 - 07:47
| Не зная структуры данных и их однородности, а также их объема - решительно нельзя ничего посоветовать. Стойте на месте, или колитесь :-) | | |||||||||||
| 4
- 18.04.2014 - 23:36
|
Эксель думал. Но надо что бы юзеры не имели возможности что-то менять. Объем на одного человека 5-6 листов текста цифр графиков. Таких человек 500. | | |||||||||||
| 5
- 19.04.2014 - 01:06
| 0-Sgo > В направлении разработчика ПО. В итоге будет намного проще, а данные, как и положено, хранить в СУБД. Заодно и права доступа выставляются. | | |||||||||||
| 6
- 21.04.2014 - 12:36
|
Sgo - в Excel реализована безопасность и защита паролем. 500 анкет - это мизерный объем, СУБД здесь не нужна, а вот удобный ввод данных с элементами интерактивности - нужен, и здесб Excel вне конкуренции. Для того чтобы "анкеты" уложить в плоскую таблицу для анализа (базу данных) - возможно придется писать мудреный макрос. Если же данные плохо структурированы - возможно придется вводить данные заново в Excel, либо копировать распознанный текст. Объем работы - примерно 100 человеко-часов. | | |||||||||||
| 7
- 22.04.2014 - 02:33
| 2 - 6 спасибо за конкретику. | | |||||||||||
| 8
- 22.04.2014 - 09:23
| DB в open/libre office | | |||||||||||
| 9
- 29.04.2014 - 21:15
|
6-economist > Нет, если почитать внимательно техзадание, то очевидно, что Exсel совершенно не подойдет. Смотри на выделенное полужирным: Есть массивы данных по гражданам в тексте и цифрах. Нужна программа, которая поможет обрабатывать эти данные. А именно: накапливает со временем статистику по каждой отдельной анкете, выводить графики изменений, объединять группы по сходным параметрам и т. Д. Вопрос, в каком направлении искать? Excel хранит данные в таблице, а это - ограниченный двумерный массив. Гораздо проще (и правильнее) использовать СУБД с записями-модификаторами чем пытаться встроить трехмерный массив данных в двухмерный. Небольшой объем задачи позволяет разместить данные в приложении типа in-memory (что возможно обеспечит обработку данных в режиме реального времени). А работать с трехмерным массивом в Excel удовольствие очень ниже среднего. 8-Фанат NASCAR > тоже вариант. Особенно если оператор не имеет профессиональных IT-навыков. | | |||||||||||
| 10
- 27.05.2014 - 15:11
| Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
www.fast-report.com. Для графиков написал два модуля. Один на DELPРI,другой на FORTRAN. Цитата:
А для проверки и исправления, вятия какой - нибудь статистики лучще всего умный человек + IBExpert. | | |||||||||||
| 11
- 28.05.2014 - 10:27
| 10-x_05772 > я использую perl+MySQL, о FR знаю, но лицензии нет. Выкладывать десятки килорублей тоже пока желания нет. | | |||||||||||
| 12
- 28.05.2014 - 11:28
|
КК СПД - вы называете Техзаданием написанный топикстартером первый абзац и на его основе советуете "взрослую" СУБД?! Аплодирую стоя! Анкеты из сабажа - суть наборы "вопрос-ответ". В 2-мерную таблицу они укладывается идеально, с некоторой, правда, избыточностью. Например название одного и того же популярного в регионе ВУЗа в 500 анкетах будет встречаться аж целых 10 раз. Excel - не двумерная таблица, а табличный процессор, поддерживающий связи многих таблиц с помощью механизма вычисляемых формул и/или имен, а механизм "справочников" - через условия/провереку на полях ввода данных. Это реализует ту самую реляцию почти как в СУБД. Может повторюсь, но во внутреннем представлении данных в Excel - используются индексы, триггеры, запросы, польз. функции, языки построения запросов и даже сам SQL, есть среда программирования VBA - чем вам Excel не СУБД? Еще раз повторюсь - для таких объемов (500 строк х 50 полей) - заводить взрослую СУБД просто смешно. За то время, которое уйдет на установку СУБД и написание постов этого топика - я наваяю макрос импорта/парсинга анкет с doc-файлов и получу готовую "СУБД" в Excel. Каждой задаче - свой инструмент. Если нужно вбить один гвоздик в посылочный ящик - не надо покупать кувалду. Вполне можно постучать тем, что есть под рукой x_05772 - связка это хорошо, но мир не стоит на месте. Вам будет наверняка интересно и приятно узнать, что свободная СУБД FireBird теперь входит в программу Base свободного пакета LibreOffice в качестве основной СУБД. Данные из любых СУБД доступны через Base - во всех приложениях - Writer, Calc итп. Для рисования графиков - LibreOffice Calc предлагает довольно приличный набор инструментов, а для агрегации - механизм сводных таблиц. Плюс (огромный!) - для вычислений Calc использует GPU в AMD/NVidia, чем уже уделывает некоторые математические пакеты и СУБД по скорости работы. Конечно, все это на "средних" объемах (100-300к строк, 100-300 полей, 1-4 Гб). Впрочем, это примерный объем бухучета 10 средних компаний за 10 лет. И заметьте - никакого программирования и "связок"! Просто один свободный офисный пакет. | | |||||||||||
| 13
- 28.05.2014 - 11:34
|
+12 выражусь корректнее: Данные из любых СУБД, полученные с помощью адаптеров или через ODBC/JDBC в LO Base - и будучи зарегистрированы как "источники данных" - станут доступны во всех приложениях LO (Writer, Calc) по нажатию F4... | | |||||||||||
| 14
- 28.05.2014 - 14:13
| Цитата:
FreeReport VCL - FastReport www.fast-report.com/ru/product/free-report-vcl/ Основные возможности FreeReport 2.34: Единственный бесплатный визуальный профессиональный генератор отчётов для Delphi и C++Builder с... Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
| | |||||||||||
| 15
- 28.05.2014 - 15:24
|
x_05772 - во всем с вами согласен, кроме последнего пункта: "Невозможно привести все СУБД к одному виду" Это возможно и это главный тренд. Языка SQL - на 99% универсален. Серьезное хорошее ПО - всегда абстрагируется от модели СУБД. Прослойки вида ODBC/JDBC - делают это же на прикладном уровне. Библиотеки вида SQLAlchemy и иные ORM - реализуют свои абстракции . Ваша связка "DELPHI+FireBird+FastReport" (3 разных по актуальности и времени происхождения приложения) сложилась исторически и она ничем не лучше "StarBasic+FireBird+Writer/Calc" (одно приложение) - для сабжевых задач, по крайней мере, точно. А для серьезных задач и Дельфей с фастрипортом может оказаться мало. В защиту Excel-way приведу еще один довод. Именно благодаря этой программе (а не играм) компьютеры пришли в бизнес и платформа IBM PC состоялась и заняла 80% рынка. Продажи офисного пакета дают 35% софтверных доходов мелкомягким. Это миллиарды долларов. Сам Гейц придумал концепцию, по которой движок макрорекордера, среда разработки, язык программирования, "субд", средство по построению интерфейсов и табличный процессор оказались одной программой. Гениальная идея вылилась в самое безумное кол-во кодеров-энтузиастов и самое большое кол-во реальных решений "лоскутной" автоматизации. Можно сказать, VBA привел в мир любительского программирования десятки тысяч людей. До сих пор в ЕС и США макросописатели являются выскоооплачиваемым офисным звеном,хотя они не программисты, просто хорошо знают свобю предметную область по основной професии. Концепция VBA прижилась не только в MSO. Назову по памяти ColerDraw, AutoCAD, GIMP, Reaper итп (там не только VBA, но и Python и др.) Все СУБД "делового" толка, по сути - одного вида. И изучать "...одну СУБД, один язык написания программ, одно средство создания отчетов..." в целях сабжа и для автора сабжа будет крайне долго и трудно. Все это содержится в одном свободном офисном пакете, который можно и нужно изучать со кшолы, ведь LibreOffice это: Родной движок СУБД FireBird Адаптеры к MySQL, Postgre, Access, DB2 Мосты к ODBC/JDBC/ADO Тонкий клиент к любой СУБД в виде LO Base с: - развитым SQL-редактором c подсветкой синтаксиса - средствами программирования на языках StarBasic, Python, JavaScript, с IDE и технологиями а-ля Intellisense, библиотеками объектов итп. Средство построения отчетов на основе текстовых шаблонов формата OpenDocument Средство консолидации с построителями графиков Calc Инструмент презентаций Impress с данными из СУБД Я до сих пор не понимаю, почему именно его не изучают на уроках информатики в школах, а затем и в ВУЗах, па продолжают "учить рисовать в worde" ~8-)) И, кстати, "нормализовать данные и завести справочники" - в описанном вами случае с фамилиями - в Excel быстрее всего: - Визуальный автофильтр сам объединит разнорегистровые записи ИВАНОВ==Иванов - Средство проверки орфографии само подсветит латинские символы в ФИО неа русском - Соединить Ф+И+О, убрать лишние пробелы и преобразовать регистр столбца на 500 строк - я могу в Excel за 10 секунд, написав одну единственную формулу: =сжпробелы(прописн(A2&" "&B2&" "&C2)) + Enter + двойной щелчок. И сделать это может любой мой сотрудник, проработавший в отделе 2 месяца. А в СУБД нужно писать несколько UPDATE с REPLACE, а то и шкодить свою UDF. И уйдет на это не 10 секунд, а 10 минут. И что самое удивительное - если строк будет 100000 - то Excel эту же задачу выполнит за те же 10 секунд. А СУБД одни индексы будет перестраивать дольше. Конечно, когда строк >300 тыс. и полей десятки - Excel начинает тупить, но Calc с GPU не тупит до 1 млн. строк. Все что выше - да, только СУБД, никаких "табличных процессоров". И что-то мне подсказывает, что описанную в сабже работу я выполню быстрее именно в Excel и обгоню любого с другим инструментарием. Но рассудить нас некому :-)) | | |||||||||||
| 16
- 28.05.2014 - 18:36
| Цитата:
Цитата:
Цитата:
Лучше. Потому что Есть мнохество людей, пишущих на Visual Basic, но мне он не нужен, потому как меня вполне удовлетворяет DELPHI, FORTRUN. Цитата:
Цитата:
Главный ресурс рунета по программированию для бизнеса sql.ru коичество топиков Delphi 72 327 C++ 17 291 Visual Basic 15 510 | | |||||||||||
| 17
- 28.05.2014 - 19:45
| Цитата:
Цитата:
Цитата:
"и она ничем не лучше" Лучше. Потому что Есть мнохество людей, пишущих на Visual Basic, но мне он не нужен, потому как меня вполне удовлетворяет DELPHI, FORTRUN. Цитата:
Цитата:
Главный ресурс рунета по программированию для бизнеса sql.ru коичество топиков Delphi 72 327 C++ 17 291 Visual Basic 15 510 Сразу Видна популярность языков Цитата:
Как легко найти Первая версия Excel предназначалась для Mac и была выпущена в 1985 году, Цитата:
Цитата:
Цитата:
--- Цитата:
"Давеча пришлось поработать с Excel. Хочу поделиться несколькими впечатлениями. Подключался к Excel используя ADO и строку подключения:... и ещё 7 строк итог AMD 2ГГц (ОЗУ 256) Win 98 Off.-2000 Одно поле символьное 65500 записей - 4мин 50 сек. Данные выбирались циклом (см. сооб. Vit) из DBase + ADO. --- Поскольку вставка записи в таблицу сложнее чем чтение, я сделал тест вставки. При эксперименте 5003 статей из DELPHIWORLD (теперь статьи стали гораздо больше) вставдялись в БЛ FireBird. При COMMIT на каждую запись 36с один COMMIT после 100 записей 26 У меня тогда был пень 800МГц 36с вставка + соmmit на каждую запись 26 соmmit после вставки 100 записей. Цитата:
--- Ну и специалисты в Краснодаре... | | |||||||||||
| 18
- 29.05.2014 - 07:35
|
14-x_05772 > спасибо, сударь, за ссылку. 15-economist > ИМХО, лучше делать правильно, а не пытаться прикрутить камазовские колеса запорожцу. | | |||||||||||
| 19
- 29.05.2014 - 09:37
|
x_05772 - уфф.... много всего. Опять же, во всем согласен, но: sql.ru - нашефсе, только объем кода в мире на VBA превышает дельфийский в разы. Пруфы не дам - гуглите. А Python - вообще 4-5-й по числу проектов среди ЯП, Borland там на втором десятке. Впрочем, на это бессмысленно спорить. У вас слишком зашкаливает эго :-)) У моих дельфийцев на работе часто бывает резкость в суждениях, это видимо следствие непростой судьбы их ЯП. Я бы тоже переживал, честно говоря, если бы потратил на изучения языка неск. лет. Насчет http://forum.vingrad.ru/act-Print/cl...8/t-64235.html и выборки из БД в Excel циклами - так можно делать только тогда, когда речь идет о десятках-сотнях строк. Налицо неправильное применение Excel и др. инструментов. Способов получить данные в формате файла Excel (де-факто стандарт обмена табличной информацией) из СУБД много (>10). Это и COM/OLE, и прямые запросы, и ODBC, ADO/DAO, прямой рендеринг итп. В общем http://office.microsoft.com/en-us/ex...010342748.aspx И Вы таки-будете удивлены, но в бизнесе в 80% подобных решений - применяется самый медленный, самый глючный и дорогой способ (потому что нужен сам Excel) - OLE/COM. Приведу несколько цифр, мои изыскания в Excel по загрузке "больших" данных: 1) Возврат 65 тыс. символьных строк из DBF/SQLITE/FIREBIRD, 10 полей - чтением на VBA в Array - 35-70 секунд. 2) то же, на VBS, чтением в Range +COM - 40-60 сек. 2) То же посредством ODBC - 70-110 сек. 3) То же, парсингом TXT (точнее CSV, а еще точнее TSV) - 15-20 сек. 4) То же, чтением In Memory SQLITE с помощью dll-ки - 9-14 сек. В общем, я считаю что с небольшими наборами данных вполне Excel справляется. Хранить в нем все данные СУБД - не обязательно, а для построения сабжевых по-сути экспертных систем, разработанных самостоятельно - Excel подходит лучше "связок". Есть простые способы держать данные в легчайших СУБД (типа однофайловой SQLite, которая быстрее MDB JET Access в 8-12 раз), делать к ним запрос и отображать в Excel, визуализируя и консолидируя посильные тому объемы (тысячи строк). А уж в плане визуализации - Excel стоит в ряду лучших рисовалок с интерактивностью. Например: Качнуть http://exceldashboardschool.com/project-management/ Позырить http://www.dailymotion.com/video/x1a...e-tracker_tech Всяким кристалрипортам за бешенный бабки до такой уровня еще пилить и пилить. Но самое главное - к такой работе можно подключить не-программистов (их в любом офисе втридесятеро больше), и построить экспертную систему не за год, а, скажем, за 2 месяца. Я рад содержимому ветки и плюрализму мнений. Люди почерпнут для себя много интересного. Всех благ!!! | | |||||||||||
| 20
- 29.05.2014 - 09:46
| КК СПД - 500 анкет это даже не запороджец, это самокат. А самокату - самокатово... | | |||||||||||
| 21
- 29.05.2014 - 09:54
|
19-economist > вот я никогда не смотрю на ЯП по его рейтингу или популярности. Я его смотрю по задаче. Вот, например, есть такая вещь - логическая обработка массива данных. И есть специальный язык для этого (Пролог). Можно и на Perl, C, C++ сделать, но проще и правильнее на Прологе. Есть задача по обработке неформатированного текста. В этом случае лучше всего perl. Высоконагруженный процесс - пишем на Си. Так и для Excel есть свои задачи, но явно не хранение данных. При всей видимой простоте это шаблонное решение, шаблонное в смысле - позволяет решить задачу, но при существенном изменении условий придется делать все заново, и не факт, что можно будет перенести данные. БД в этом случае в разы надежнее и гибче. Более того - база данных заточена под хранение данных. Excel, как и Word или Access, действтительно может использоваться, но только как наглядный интерфейс к БД. | | |||||||||||
| 22
- 29.05.2014 - 12:02
|
КК СПД - к вопросу парсинга plain-текста (логи) размером в 6 Гб. В лоб сравнивал производительность Perl, Python (с библой re), MS LogParser и Excel. Победил Питон, потом LogParser, потому уже Perl. Имхо, если бы ЯП типа Python не могли эффективно логически обрабатывать массивы, делать морфоанализ, быстро парсить текст и надежно работать в высоконагруженных проектах - хрен бы они попали в топы рейтингов. Понятно что там ставят оценки не беспристрастно, влияет бесплатность одних и ангажированность за других, но тем не менее. Советовать новичкам забыть про все и зубрить Дельфи - в наше время, имхо, несколько безответственно. "Для Excel есть свои задачи, но явно не хранение данных" - блин, а мужики-то не знают, и хранят как раз большую часть бизнес-информации в Excel! Только маленкими стопочками. Опять же, срисую с натуры: На моем предприятии с 1998 г. применяется СУБД 1С, почти каждый год - новая база (DBF). Потому что база >2 Гб начинает тупить и сама ЗАО 1С рекомендует "обрезать, сжимать и продолжать". Прыгать по 10-ти базам суммарным объемом 40 Гб надоело. И встал вопрос где хранить все в одной базе (нужны кросс-годовые отчеты) - было много предложений (MSSQL, MySQL, и даже 1С с MSSQL Engine за 0,5 млн. руб.) Победила крохотная свободная СУБД SQLite, имеющая все навороты от других СУБД, разрешающая работать по сети 3-4-м юзверям безо всяких паролей. А в кач-ве "морды" был призван Excel. Все данные из 40 Гб поместились в ней в 4 Гб, с индексами! А выборки в 300 тыс строк х 50 полей выполнялись за время до минуты. И зачастую они сохранялись в Excel (10 Мб). Это быстро взлетело, работало и работает. Так что отрицание возможности хранения данных в Excel лично для меня звучит смешно. | | |||||||||||
| 23
- 29.05.2014 - 12:24
|
22-economist > опять же - парсинг это только одна из задач. Кстати - сравнивали объем кода и объем работ для написания парсинга логов? Python тоже неплохой ЯП, хоть и сверхвысокого уровня. Дельфин пользовал последний раз в 2006 году, поэтому объективного мнения не имею. Насчет хранения бизнес информации в Excel - можно, но глупо. Почему? Да потому что "Только маленкими стопочками". А вот использование СУБД SQLite - правильный выбор, так же как и выборка данных из БД в лист Excel. А теперь представите, что будет если хранить Ваши 4 Гб только в Excel... БД - хранит данные, обработка данных - задача ПО по обработке данных (в том числе и электронные таблицы). Потому что объем информации организации - гигабайты и хранить её нормально можно только в БД, в какой - другой вопрос. Хранить в ЭТ можно, но при этом будет куча файлов и мусора. | | |||||||||||
| 24
- 29.05.2014 - 12:35
|
КК СПД - объем кода был примерно одинаков. Код на перле и питоне компактный, но LogParser - еще меньше (т.к. это спец. инструмент именно для разбора логов, там фактически однострочник). 4 Гб всех данных из SQLite - по "SELECT * from BUH" в Excel все-же помещались, только XLSM-файл становился равным 55 метров (это ZIP-архив-OXML-компаунд) и еле жил - работать в нем было нельзя. | | |||||||||||
| 25
- 29.05.2014 - 15:02
|
Немного в тему генотчетов http://habrahabr.ru/company/haulmont/blog/224125/ | | |||||||||||
| 26
- 29.05.2014 - 17:52
|
очень странные нынче в Краснодаре экономисты. Потому что в начале было. Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
--- Пора завязывать. А то зачинщика не видно и не слышно. Испугался потока ценных советов. | | |||||||||||
| 27
- 30.05.2014 - 10:01
|
x_05772 - пост 4 был после поста 3, а не наоборот - непоследовательное цитирование. А все остальное - отрыв от контекста. Это - запрещенные приемы в полемике, приводящие к демагогии. Вы читаете снизу-вверх? Если одна таблица в 500 строк и 100 полей это объем для СУБД - то enjoy it! Вот я задачу топикстартера в одиночку решу за 2 дня и 10 тыс. руб. на Excel+VBA. Это включит импорт/парсинг/чистку текстовых анкет, создание сводной таблицы/диаграммы для фомрирования отчетов в любом аналитическом разрезе, ну и поле ввода новых анкет с условиями и проверками. Если же мне делать это в том же FireBird/Access - я потеряю еще пол-дня на "чистку" неуникальностей, двойников и создание справочников, и еще часа три на рисование диалогов. Одним из веских преимуществ Excel является возможность создания "интерфейса приложения" в самой книге, на листе - без муторного программирования свойств и проверочного кода. Впрочем, если не работать в Excel без чтения книг, на уровне "нарисовать рамки" - можно обо всех этих возможностях даже не догадываться. Например из 20-ти моих айтишников-сетевиков-киповцев - средний уровень знания возможностей Excel - не более 10%, а использование - не более 5%. Из 2 тыс. функций они знают наизусть (действие, синтаксис,аргументы) не более 7-ми. Я знаю примерно в 5 раз больше, хоть и не сторонник "зубрежки". | | |||||||||||
| 28
- 30.05.2014 - 11:26
| Цитата:
Цитата:
Петух, навозну кучу разгребая Нашел жемчужное зерно. -------- Бедный зачинщик что-то не появляется. Запугали. К тому же обсуждение полезло в сторону какие системы есть, какие лучше. А надо Цитата:
Моя связка DELPHI, FireBird, FastReport это для тех, кто хочет стать профессионалом. Основные компоненты MS Access: построитель таблиц; построитель экранных форм; построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI); построитель отчётов, выводимых на печать. | | |||||||||||
| 29
- 30.05.2014 - 13:01
|
x_05772 - "...еще пол-дня..." означает удлинение 2 дней на полдня за счет определенных работ, безотносительного того, сколько эти работы занимают времени в 2-х сутках. Про 0 часов - ваша выдумка. То что чистка Excel-ем таких объемов с помощью интерактивных автофильтров и формул и наиболее эффективна (и нет ничего лучше Excel) - вам подтвердят другие, спросите. И кстати, "язык SQL не соответствует стандарту ANSI" не только в Access, но и в MSSQL, MySQL, PostgreSQL и еще доброй тридцатке СУБД. Они непрофессиональные? | | |||||||||||
| 30
- 30.05.2014 - 19:49
| Цитата:
Вот мне регулярно приходилось стыковать данные от собеса про льготников и от медучреждений и аптек. Стандартная ситуация: ошибки в фио, улицах. Англоязычные SOUDEX & METAPHONE естественно не годятся. И русский METAPHONE и методы нечеткого сравнения взятые из инета тоже. Я использовал готовую функцию нечеткого сравнения Similar из очень полезной библиотеки HYPERSTR. Как такое сделать на EXCEL? Цитата:
Цитата:
| | |||||||||||
| 31
- 01.06.2014 - 21:42
|
x_05772 - поржал про SOUDEX, METAPHONE, HYPERSTR, в контектсе топика (у мя это бзик, все время помню как все начиналось). Слово "провесси?нал*" не я первый использовал. Для меня профессионал может быть и в Word - это тот кто пишет макросы и не работает без стилей. Такому K=2 к зарплате сразу. ... Пушки при 500 строках?! А больше...?! Откройте для себя библиотеки морфоанализа на русском, писанные на Python. Вот уж где точно - нечОткое сравнение. А также признание от Google/Yandex. Впрочем, походу "my way", априори, у x_05772 важнее. Кстати, мы почти лично знакомы, и под старым ником - тем более. И это хорошо - я уважаю принципиальных оппонентов: пусть мы оба неправы - но зато другие узнают что-то полезное для себя. ... Вернусь к сабжу - в свободном пакете OO/LO Calc есть фоновая ПОСТОЯННАЯ, МУЛЬТИЯЗЫЧНАЯ проверка орфографии (в отл. от того же Excel) - дык вот она устраняет половину перечисленных проблем. Ибо персоналии и "фиы" - в тех словарях в избытке. Даже есть "Батразд" и "Джумшуд" :-) На Excel/Calc есть автофильтр - который вам в списке выбора с чекбоксами покажет две похожие, но РАЗНЫЕ строки: Иванов Иван Иванович Иванoв Иван Иванович И это вычислит обычная дуреха/бухша, коих в избытке в любом офисе. И за это им спасибо - ни один программист в поиске именно такой лажи глазами - не преуспеет лучше обычных сотрудников. Лично я всегда считаю нужным привлечь к трудной работе массу людей - хоть и могу ее порой сделать и сам (IT-компания). В результате - через 3-5 лет каждый второй чел уходит от меня на вдове-втрое большую ЗП. И пусть... | | |||||||||||
| 32
- 02.06.2014 - 07:19
| знатный срач. | | |||||||||||
| 33
- 02.06.2014 - 07:30
|
31) Для меня профессионал может быть и в Word - это тот кто пишет макросы и не работает без стилей. Такому K=2 к зарплате сразу. А какая у вас базовая ставка в отделе? ) | | |||||||||||
| 34
- 02.06.2014 - 11:55
| 25 база | | |||||||||||
| 35
- 02.06.2014 - 14:43
| 50 тыс. за Excel и макросы - не слабо. | | |||||||||||
| 36
- 03.06.2014 - 08:48
|
Marr - все познается в сравнении и расчете. Например, в одной "силовой структуре" макрос, написанный в 1996-м году, 600 строк, позволил сократить численность отдела с 4-х до 2-х человек. Макрос был средней сложности, но ответственный - парсил "принтерый" вывод в файл из СУБД PARADOX и FOXPRO и делал справочку, на основании которой приезжали дяди и забирали всю кассу доброй сотни предприятий, и так почти каждый день. Естественно тот макрос окупился как напрямую, так и за счет сокращения персонала. Это миллионы рублей на наши деньги. Или еще пример: Расчет зарплаты и табелирование на предприятии в 2 тыс. человек, с работой по сменам и регулярными "отклонениями". Даже имея электронную систему контроля доступа и "профильный" дорогой продукт от 1С "ЗиК"- нельзя получить то, что нужно, не затратив дополнительно 80 чел-часов труда в неделю, а значит +2 работника, которые обойдутся в 30х1,5х12х2=1,1 млн. руб. в год. А если написать макрос - можно этих 2-х человек сократить, а скорость расчета зарплаты - увеличить вдвое. Причина - высокая интероперабельность решений на макросах. Это когда большая задача легко и логично делится на кусочки, методом "лоскутной" автоматизации множеством людей пишутся макросы для себя - и удается объединить то, что кажется несовместимым. Да и не в макросах дело, а уровне владения офисными технологиями. Вот мои данные по клиентам: 90% юристов делают свои договоры "из предыдущего файла", вручную меняя реквизиты 90% секретарей и кадровиков пишут письма, конверты, уведомления итп - от руки 90% расчетчиков пишут извещения на алименты от руки... А ведь все данные для автоматического заполнения этих документов уже имеются в электронном виде. И не нужно никаких макросов - достаточно механизмов слияния. Ну максимум - кнопку нарисовать и запустить слияние по конкретной таблице. | | |||||||||||
| 37
- 03.06.2014 - 12:37
| economist, я примерно представляю, о чем вы говорите - сам занимаюсь автоматизацией производства. | | |||||||||||
| 38
- 03.06.2014 - 12:42
| Я к тому, что 50 тыс. обычно платят сотруднику, который целенаправленно делает какой-то важный продукт, а не просто "умеет макрос написать". Т.е. это з/п не планктона, а уже программиста. | | |||||||||||
| 39
- 03.06.2014 - 14:35
|
36-economist > выделю ключевое Это когда большая задача легко и логично делится на кусочки, методом "лоскутной" автоматизации множеством людей пишутся макросы для себя - и удается объединить то, что кажется несовместимым. и прокомментирую - когда человек имеет достаточно знаний, то он естественно напишет. А вот уговорить руководителя это внедрить... У меня тоже работает ПО на VBA, которое оставлял на прошлых местах работы, ежемесячно экономит примерно 45-50 килорублей. 38-Marr > есть подход "от результата", если человеку платят % и он автоматизировал труд чтобы работать за 3-х, то почему бы и нет? | |
Интернет-форум Краснодарского края и Краснодара |
