К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

В каком направлении двигаться?

Гость
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
Цитата:
Сообщение от economist Посмотреть сообщение
Не зная структуры данных и их однородности, а также их объема - решительно нельзя ничего посоветовать.
В общем случае надо просто использовать общеизвестныt SQL движки.
Цитата:
Сообщение от Sgo Посмотреть сообщение
Но надо что бы юзеры не имели возможности что-то менять.
В тех же SQL уже встроены поддержки прав пользователей. Но всё равно будет девочка / тетка, вводящая текст и временами редактирующая.
Цитата:
Сообщение от economist Посмотреть сообщение
СУБД здесь не нужна,
Прелесть СУБД в том, что они имеют очень много всего полезного, чего нет у EXCEL и всякой лабуды вроде FOXPRO и и прочиз.
Цитата:
Сообщение от КК СПД Посмотреть сообщение
Excel хранит данные в таблице, а это - ограниченный двумерный массив.
Со времен пророка Дейта знают, что надо хранить данные в нормализованых таблицах.
Цитата:
Сообщение от КК СПД Посмотреть сообщение
Небольшой объем задачи позволяет разместить данные в приложении типа in-memory (что возможно обеспечит обработку данных в режиме реального времени).
Цитата:
Сообщение от КК СПД Посмотреть сообщение
А именно: накапливает со временем статистику по каждой отдельной анкете, выводить графики изменений,
Я испокон веков использую связку DELPHI, FireBird, FastReport=
www.fast-report.com.
Для графиков написал два модуля. Один на DELPРI,другой на FORTRAN.
Цитата:
Сообщение от КК СПД Посмотреть сообщение
Особенно если оператор не имеет профессиональных IT-навыков.
Это не нужно. Программа ввода должна быть простой в обращении. Например при вводе поля фамилия подсказывать уже имеющиеся.
А для проверки и исправления, вятия какой - нибудь статистики лучще всего умный человек + 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
Цитата:
Сообщение от КК СПД Посмотреть сообщение
о FR знаю, но лицензии нет
Мало знаете, сударь

FreeReport VCL - FastReport
www.fast-report.com/ru/product/free-report-vcl/

Основные возможности FreeReport 2.34: Единственный бесплатный визуальный профессиональный генератор отчётов для Delphi и C++Builder с...
Цитата:
Сообщение от economist Посмотреть сообщение
Анкеты из сабажа - суть наборы "вопрос-ответ". В 2-мерную таблицу они укладывается идеально, с некоторой, правда, избыточностью.
Никоим образом не валить всё сразу. Надо нормализовать данные и завести справочники. Иначе потом будет плохо. Я как-то переводил просто текст в базу, и пришлось повозиться с отождествлением людей, заесенных из разных контор собес и медицина. Жуть!
Цитата:
Сообщение от economist Посмотреть сообщение
Excel - не двумерная таблица,
Единственный плюс EXCEL - её многие знают. Однако для регулярной работе лучше всего освоить вышеупомянутую связку.
Цитата:
Сообщение от economist Посмотреть сообщение
Еще раз повторюсь - для таких объемов (500 строк х 50 полей) - заводить взрослую СУБД просто смешно.
Не смешно, а профессиональный подход. Лучше освоить один набор инстументом и пользоваться им, чем изучать и стыковать майкрософтовские. Уже приустановке MSDE оно на пол пути завопило о отсутствии аксесса. Установи, прошла дальше и завопила что ещё что-то требуется. А потом оказалось, что для работы есть только средство командной строки, и нет документации.
Цитата:
Сообщение от economist Посмотреть сообщение
чем вам Excel не СУБД?
Предлагаю посмотреть на возможности FireBird и сравнить.
Цитата:
Сообщение от economist Посмотреть сообщение
связка это хорошо, но мир не стоит на месте
Какое отношение эта общая фраза относится к выбору инструментов?

Цитата:
Сообщение от economist Посмотреть сообщение
И заметьте - никакого программирования
Именно по этой причине его не надо использовать.
Цитата:
Сообщение от economist Посмотреть сообщение
Данные из любых СУБД, полученные с помощью адаптеров или через ODBC/JDBC в LO Base
Невозможно привести все СУБД к одному виду. Поэтому из принципа экономии времени и мозгов лучше изучить одну СУБЛ, один язык написания программ, одно средство создания отчетов.
Гость
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
Цитата:
Сообщение от economist Посмотреть сообщение
лавный тренд. Языка SQL - на 99% универсален.
К сожалению, главное что требуется в СУБД - пресловутые ACID решаются в каждой по своему. Аналогично различаются треггера, хранимые процедуры. опрелеленные пользователем функции.
Цитата:
Сообщение от economist Посмотреть сообщение
3 разных по актуальности и времени происхождения приложения
Это никого не волнует.
Цитата:
Сообщение от economist Посмотреть сообщение
сложилась исторически и она ничем не лучше "StarBasic
Меня список StarBasic, Python, JavaScript ну совершенно удручает. Незачем их изучать.
Лучше. Потому что Есть мнохество людей, пишущих на Visual Basic, но мне он не нужен, потому как меня вполне удовлетворяет DELPHI, FORTRUN.
Цитата:
Сообщение от economist Посмотреть сообщение
Серьезное хорошее ПО - всегда абстрагируется от модели СУБД.
Цитата:
Сообщение от economist Посмотреть сообщение
А для серьезных задач и Дельфей с фастрипортом может оказаться мало.
Это мнение на чем-то основано?
Главный ресурс рунета по программированию для бизнеса sql.ru
коичество топиков
Delphi 72 327
C++ 17 291
Visual Basic 15 510
Гость
17 - 28.05.2014 - 19:45
Цитата:
Сообщение от economist Посмотреть сообщение
лавный тренд. Языка SQL - на 99% универсален.
К сожалению, главное что требуется в СУБД - пресловутые ACID решаются в каждой по своему. Аналогично различаются треггера, хранимые процедуры. опрелеленные пользователем функции.
Цитата:
Сообщение от economist Посмотреть сообщение
3 разных по актуальности и времени происхождения приложения
Это никого не волнует.
Цитата:
Сообщение от economist Посмотреть сообщение
сложилась исторически и она ничем не лучше "StarBasic
Меня список StarBasic, Python, JavaScript ну совершенно удручает. Незачем их изучать.
"и она ничем не лучше"
Лучше. Потому что Есть мнохество людей, пишущих на Visual Basic, но мне он не нужен, потому как меня вполне удовлетворяет DELPHI, FORTRUN.
Цитата:
Сообщение от economist Посмотреть сообщение
Серьезное хорошее ПО - всегда абстрагируется от модели СУБД.
Цитата:
Сообщение от economist Посмотреть сообщение
А для серьезных задач и Дельфей с фастрипортом может оказаться мало.
Это мнение на чем-то основано?
Главный ресурс рунета по программированию для бизнеса sql.ru
коичество топиков
Delphi 72 327
C++ 17 291
Visual Basic 15 510
Сразу Видна популярность языков
Цитата:
Сообщение от economist Посмотреть сообщение
В защиту Excel-way приведу еще один довод. Именно благодаря этой программе (а не играм) компьютеры пришли в бизнес и платформа IBM PC состоялась и заняла 80% рынка.
Давным давно люди использовали PARADOX, dBASE, Clipper, FOXBASE.
Как легко найти

Первая версия Excel предназначалась для Mac и была выпущена в 1985 году,

Цитата:
Сообщение от economist Посмотреть сообщение
Продажи офисного пакета дают 35% софтверных доходов мелкомягким.
Сударь, перестаньте сообщать совершенно никому не нужные сведения
Цитата:
Сообщение от economist Посмотреть сообщение
Сам Гейц
Интересно, кто этот Гейц?
Цитата:
Сообщение от economist Посмотреть сообщение
А в СУБД нужно писать несколько UPDATE с REPLACE,
А что такое REPLACE? Что-то в моём скопише документов и разных *.sql такого нет.
---
Цитата:
Сообщение от economist Посмотреть сообщение
Соединить Ф+И+О, убрать лишние пробелы и преобразовать регистр столбца на 500 строк - я могу в Excel за 10 секунд,
Давным давно, увидев на http://forum.vingrad.ru/act-Print/cl...8/t-64235.html некую мастурбацию с выбором из таблицы

"Давеча пришлось поработать с 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 записей.
Цитата:
Сообщение от economist Посмотреть сообщение
А в СУБД нужно писать несколько UPDATE с REPLACE, а то и шкодить свою UDF. И уйдет на это не 10 секунд, а 10 минут.
Из какого пальца высосана эта странная инфа?
---
Ну и специалисты в Краснодаре...
Гость
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
очень странные нынче в Краснодаре экономисты. Потому что в начале было.
Цитата:
Сообщение от economist Посмотреть сообщение
Не зная структуры данных и их однородности, а также их объема - решительно нельзя ничего посоветовать. Стойте на месте, или колитесь :-)
Однако начал потоком изливать свои советы.
Цитата:
Сообщение от economist Посмотреть сообщение
500 анкет - это мизерный объем, СУБД здесь не нужна, а вот удобный ввод данных с элементами интерактивности - нужен, и здесб Excel вне конкуренции.
запомнили
Цитата:
Сообщение от economist Посмотреть сообщение
- средствами программирования на языках StarBasic, Python, JavaScript, с IDE и технологиями а-
Цитата:
Сообщение от economist Посмотреть сообщение
И заметьте - никакого программирования и "связок"!
Цитата:
Сообщение от economist Посмотреть сообщение
Имхо, если бы ЯП типа Python не могли эффективно логически обрабатывать массивы, делать морфоанализ,
Такое уемет каждый язык программирования.
Цитата:
Сообщение от economist Посмотреть сообщение
Есть простые способы держать данные в легчайших СУБД (типа однофайловой SQLite, которая быстрее MDB JET Access в 8-12 раз)
СУБД ценятся не своим весом, а возможностями.
---
Пора завязывать. А то зачинщика не видно и не слышно. Испугался потока ценных советов.
Гость
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
Цитата:
Сообщение от economist Посмотреть сообщение
я потеряю еще пол-дня на "чистку" неуникальностей, двойников и создание справочников,
А что, для Excel+VBA это будет делаться за 0 часов?
Цитата:
Сообщение от economist Посмотреть сообщение
Из 2 тыс. функций они знают наизусть
У классика
Петух, навозну кучу разгребая
Нашел жемчужное зерно.
--------
Бедный зачинщик что-то не появляется. Запугали. К тому же обсуждение полезло в сторону какие системы есть, какие лучше.
А надо
Цитата:
Сообщение от Sgo Посмотреть сообщение
Вопрос, в каком направлении искать?
Если надо сделать некое хранилище, вбить туда данные И не требуется обучиться, чтобы стать профессионалом, , лучше всего Access. У него есть всё лдя создания простых систем, есть куча книг "Как изучить ... за 21 день", есть у кого спросить.
Моя связка 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
Цитата:
Сообщение от economist Посмотреть сообщение
То что чистка Excel-ем таких объемов с помощью интерактивных автофильтров и формул и наиболее эффективна (и нет ничего лучше Excel) - вам подтвердят другие
По сравнением с чем? Вы пробовали сами что-нибудь помощнее нежно любимой Excel?
Вот мне регулярно приходилось стыковать данные от собеса про льготников и от медучреждений и аптек. Стандартная ситуация: ошибки в фио, улицах. Англоязычные SOUDEX & METAPHONE естественно не годятся. И русский METAPHONE и методы нечеткого сравнения взятые из инета тоже.
Я использовал готовую функцию нечеткого сравнения Similar из очень полезной библиотеки HYPERSTR. Как такое сделать на EXCEL?

Цитата:
Сообщение от economist Посмотреть сообщение
язык SQL не соответствует стандарту
Цитата:
Сообщение от economist Посмотреть сообщение
Они непрофессиональные?
Какое отношение имеет несоответствие стандарту к профессионализму? Три больших сервера DB2, ORACLE, MSSQL имеют некоторые несоответствия стандарту, но никто по этому поводу не льет слез.
Гость
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-х, то почему бы и нет?


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены