Оцените проект: "сервер бухгалтерии"
Цель данного поста: узнать ваше мнение. К тому же, вполне возможно, проект вскоре перейдет в разряд open-source.
Читать этот пост, я думаю, имеет смысл только тем, кто хотя бы поверхностно знаком с бухгалтерией, бухгалтерскими итогами, проведением документов, а еще лучше - с 1С.
Собственно идея.
Есть распространенные бизнес-приложения, предназначенные для бухгалтерского, управленческого и иного, более специализированного, учета. Однако этот софт платный. Есть приложения подешевле - 1С, к примеру, но тот принципиально не поддерживает распределенное хранение и обработку данных. Другие - я не знаю, возможно поддерживают, но они на порядки дороже.
Наш директор считает :) что многим выгоднее купить лишнюю машину под сервер, чем покупать очень дорогое ПО, поскольку серьезное ПО дороже даже нескольких машин. Поэтому
ПЕРВАЯ ЧАСТЬ ИДЕИ такова: делаем так называемый "сервер бухгалтерских итогов", куда приходят клиентские запросы на проведение документов. Сервер распределяет запросы на множество баз данных. Множество БД построено таким образом, чтобы:
1) Ускорить чтение данных;
2) Ускорить запись данных;
3) Повысить надежность системы.
Ускорение чтения и повышение надежности достигается за счет "зеркального" хранения данных: одни и те же данные пишутся параллельно на несколько БД.
Ускорение записи достигается за счет того, что часть данных записывается на один сервер, часть - на другой, т. е., попросту говоря, если документ создает 50 проводок, и имеется 10 баз данных, 5 проводок пишем на одну БД, 5 проводок - на вторую, и т. д.
Итак, получаем "сверхкластерную" архитектуру, в которой имеется N кластеров (кластеры между собой "зеркальны", т. е. содержат одну и ту же информацию), внутри каждого кластера имеется M баз данных (каждая БД содержит часть информации кластера).
Первая часть идеи обеспечивает распределенную и параллельную обработку и хранение бухгалтерской информации.
ВТОРАЯ ЧАСТЬ ИДЕИ: всегда поддерживать актуальность последовательности, т. е. при изменении данных и перепроведении "задним числом" автоматически перепроводить зависимые документы. Соответствующие алгоритмы и структуры данных (и таблиц БД) хорошо продуманы и предусматривают хорошую оптимизацию, которая минимизирует количество перепроводимых данных при восстановлении последовательности и позволяет перепроводить документы частично параллельно, несмотря на то, что имеет место строго хронологическая последовательность, причем эти алгоритмы практически не зависят от алгоритмов проведения каждого документа.
PS: главное, чтобы вас не поимели :) а то всякое бывает...
Проблема нынешнего рынка бухгалтерских приложений в отсутсвии альтернатив со стороны рабочей станции и дороговизне перехода на что-то новое :(
Поэтому большой вопрос в том насколько будет востребовано это решение. Лучше подумать над тем как сделать из бух. приложения хороший смарт-клиент.
у одного моего знакомого, компания. покупают 1С, и платят программерам 1С (сторонним ессна), чтобы конфигурацию "заточили" под их бизнес... не знаю что там делают, и как её затачивают ибо не разбираюсь, но суть в том что Лицензионная версия 1С + работа программеров выходит примерно в 1,2 миллиона деревянных.
я вот думаю что эту контору имеют :)
Проблема нынешнего рынка бухгалтерских приложений в отсутсвии альтернатив со стороны рабочей станции и дороговизне перехода на что-то новое :(
Поэтому большой вопрос в том насколько будет востребовано это решение. Лучше подумать над тем как сделать из бух. приложения хороший смарт-клиент.
Укажи мне дешевую, а еще лучше - бесплатную СУБД, которая реализовала бы транзакции не на одном сервере, а на кластере. Вообще, какие СУБД реализовали какую-то поддержку кластерной организации?
Директор наш лазил в поисках чего-то подобного и ничего путного не нашел, даже платного! А проблема масштабируемости остается, и апгрейд сервака имеет пределы.
И потом, я повторюсь еще раз, серьезный софт, предназначенный для Большого Бизнеса, очень дорог, дешевле купить 10 компов под серверы (если имеется кластерная архитектура), чем несколько дополнительных лицензий под этот софт.
Хотя я возхможно даже и не отказался бы от участия в этом проекте, пора показать монопалистам 1С что они не одни, и кто-то может делать лучше:)
Поддержка СУБД PostageSQL (немного переработанной самой фирмой 1С),
Реальзация платформы 1С на ОС Linux
Так что вскоре предприятия начнут экономить на лицензии от Microsoft (для тех кто не в курсе, нужно покрайней мере установить Windows а так же желательно наличие MS SQL Server на серваке).
Цитирую первоначальный пост:
"Множество БД построено таким образом, чтобы:
1) Ускорить чтение данных;
2) Ускорить запись данных;
3) Повысить надежность системы.
Ускорение чтения и повышение надежности достигается за счет... Ускорение записи достигается за счет..."
Как-раз таки ускорение достигается за счет того, что запросы (как на запись, так и на чтение) "разбрасываются" по многим БД, а процесс разброса происходит на уровне кода C++, что будет работать быстрее, чем на уровне БД.
А если к нам одновременно приходят много схожих запросов - тут все продумано: запросы накапливаются, прежде чем выполняться, и схожие запросы объединяются в один, за счет чего обход записей в поисках подходящих будет происходить один раз, а не два, три и т. д. Эта идея как раз в данный момент находится на реализации.
Можно, конечно, и распределение запросов на несколько БД, и "накопление и объединение" заменить тупо добавлением индексов в соответствующие таблицы, но:
1) Даже при надлежащем индексировании две БД сработают быстрее, чем одна.
2) Полей в таблицах много, и индексировать все поля, а также создавать композитные индексы по всем возможным комбинациям полей - чересчур. Ведь чем больше индексов, тем медленнее вставка/изменение записей в БД (ускоряется только чтение). Поэтому индексирование по всем подряд полям не производится, только по самым важным (идентификатор документа и т. п.).
Ap0k, я забыл упомянуть, что описанный "сервер бухгалтерии" есть лишь часть большого проекта. В проект входят еще клиентская часть, сервер проведения (генератор проводок). А вообще, еще один принцип проектируемой системы - сильное упрощение обновления системы.
Что мы имеем в той же 1С? Имеется типовая конфигурация, которая "затачивается" (дорабатывается) под конкретное предприятие, в результате чего имеем уже доработанную конфигурацию. Теперь выходит обновление от самой 1С. Тут и возникают большие сложности - нужно обновить систему так, чтобы доработанный код не потерялся (т. е. нужно одновременно внедрить то, что доработала 1С, но оставить то, что дорабатывали мы. А если 1С обновила тот же самый код, который мы доработали?). Поверь, обновление (грамотное, без глюков) занимает немалое время. Некоторые организации тратят на это большие бабки, порой больше, чем стоит сам хард энд софт.
Наша идея в том, чтобы обновление происходило вообще автоматически.
И еще.
Та же 1С продает конфигурацию целиком, заточенную под "типовое" предприятие. А если организация не использует какие-то подсистемы конфигурации? Например, у них всего лишь один склад, и им нафиг не нужен многоскладской учет? Можно, конечно, создать всего один склад, и его всегда указывать во всех документах. Но ведь указывать надо! Каждый раз щелкать на поле "склад" и указывать там все время одно и то же - лишняя трата времени пользователя. А ведь если взять такую конфигурацию, как УПП (управление производственным предприятием) - там столько всего, что вряд ли найдется организация, которая использует все это. К тому же такая избыточность ведет к сильному замедлению и ресурсопожирательству. Это самое УПП загружается на компах с 756 Мб памяти минуту-две, а при меньших объемах лучше даже не думать об УПП. Это, позволю заметить, на клиентской машине!
Так что, кроме автообновления, предлагается еще и модульность. Т. е. организация получает от нас не конфигурацию, а модули (при необходимости, мы дадим ей модуль складского учета, если понадобится учет упрощенной системы налогообложения - дадим и этот модуль, и т. д.). Таким образом, попытаемся вообще избежать доработок (заточек под конкретную организацию). И конфигурация будет такая, какая им нужна, без лишнего и без недостающего. И установка модулей, равно как и интеграция с другими модулями, заложена в самой концепции нашей софтины.
На счет вышесказанного - глубже уточнить не могу, т. к. я занимаюсь конкретно сервером бухгалтерии, а вся эта модульность и т. п. - не мое дело.
Дело такое.
1. Мы к клиенту вообще не приезжаем (в отличие от франчайзи);
2. Платформа наша распространяется бесплатно;
3. Платно мы распространяем только модули, причем за копейки, т. к. модули реализуются легко, и интегрируются в систему легко;
4. Продавая клиенту очередной модуль (или обновляя его), мы, попросту говоря, высылаем дистрибутив на емайл, он двойным щелчком его устанавливает.
5. Остается возможность все-таки дорабатывать под конкретное предприятие, т. е. клиент может нанять программера, знающего нашу систему. Но возможность легкого и быстрого обновления остается (как это реализуется - понятия не имею :), как я и говорил, не моя это забота).
Таким образом, мы рубим бабки по сути по копейке с каждого клиента, но реально - сидим и режемся в старкрафт 2, и лишь раз в месяц (когда изменяется наше изменчивое российское законодательство) обновляем модули или пишем новые и отсылаем их клиентам. Вот так, с миру по нитке - "как я заработал свой первый миллион".
Будем хранить так называемые "бухгалтерские итоги", т. е. остатки и обороты данных по месяцам (скорее всего; возможно, дадим возможность период сохранения итогов настраивать администратору). Т. е. если в течение месяца было 100 поступлений одного конкретного товара на один конкретный склад, и 80 реализаций того же товара с того же склада, мы эти 180 записей объединяем в одну запись, где храним просто начальный остаток (сколько было в начале месяца), конечный остаток (сколько осталось в конце), приход (сколько всего пришло) и расход (догадайтесь?). Задумка вполне оправдана, поскольку:
1. Создание таких записей (по сути - операция записи в БД) будет происходить лишь раз в месяц, и поэтому можно проиндексировать хоть по всем полям (плюс даже всевозможным комбинациям полей).
2. Чтение этих данных будет происходить на каждом шагу. Это - формирование отчетов за различные периоды, не только за текущий месяц, но и за прошлые; анализ и контроль остатков товаров в документах; и т. д. и т. п. Таким образом, чтение - частое, запись - нечастая, к тому же количество записей в таблице итогов гораздо меньше, чем число записей в исходной таблице, и индексация обоснована.
Идея не то чтобы взята из 1С, до нее нетрудно догадаться, просто она там тоже реализована. Но идея хорошая.
Поддержка СУБД PostageSQL (немного переработанной самой фирмой 1С),
Реальзация платформы 1С на ОС Linux
Так что вскоре предприятия начнут экономить на лицензии от Microsoft (для тех кто не в курсе, нужно покрайней мере установить Windows а так же желательно наличие MS SQL Server на серваке).[/QUOTE]
8.1 уже вышла.
На Linux реализован только сервер. Клиентская часть - по-прежнему форточная.
1) Ускорить чтение данных;
2) Ускорить запись данных;
3) Повысить надежность системы.
Ускорение чтения и повышение надежности достигается за счет "зеркального" хранения данных: одни и те же данные пишутся параллельно на несколько БД.
Ускорение записи достигается за счет того, что часть данных записывается на один сервер, часть - на другой, т. е., попросту говоря, если документ создает 50 проводок, и имеется 10 баз данных, 5 проводок пишем на одну БД, 5 проводок - на вторую, и т. д.
Итак, получаем "сверхкластерную" архитектуру, в которой имеется N кластеров (кластеры между собой "зеркальны", т. е. содержат одну и ту же информацию), внутри каждого кластера имеется M баз данных (каждая БД содержит часть информации кластера).
Первая часть идеи обеспечивает распределенную и параллельную обработку и хранение бухгалтерской информации.
IMHO. Поскольку, скорее всего, бухгалтерская БД будет, скорее всего, базироваться на принципах реляционной СУБД (возможно, я ошибаюсь, но альтернатив пока не вижу), лучше не изобретать велосипед, а взять готовое решение от Oracle, IBM или Teradata, благо с производительностью, многоплатформенностью, кластеризацией и обеспечением надёжности там всё уже решено до нас специально обученными людьми.
Ещё одно IMHO. При грамотном проектировании структуры БД с глубоким знанием как предмета автоматизации, так и особенностей работы используемой СУБД и неиспользованием Java на сервере проблем производительности быть не должно даже на довольно скромных серверных конфигурациях. Так, например, некий финансовый софт (какой -- не скажу, военная тайна ;) ) под Oracle работал на двухпроцессорном Pentium 3 с 1024 Мб оперативной памяти, при этом финансовых данных было за 3 года примерно о 16000 единицах финансового учёта; с базой данных одновременно без тормозов работало 110 человек.
Опять IMHO. Многие знатоки бухгалтерского учёта, из тех, кто знает истинное значение волшебного слова "GAAP", заслуженно критикуют 1С за отсутствие т.н. аудиторского следа. Так вот, насколько я понимаю, проведение документов "задним числом" тоже противоречит понятию аудиторского следа. Для "опоздавших" и отменённых документов должен существовать механизм перерасчёта, как в ведомости на зарплату, типа, "перерасчёт: доплата за прошлый месяц и удержание за позапрошлый".
И последнее IMHO. Как я понимаю, мы приходим к подобию "1С:Предприятия 8.1". Существует сервер (или кластер серверов), обеспечивающих хранение и выборку данных, соблюдение целостности данных, обеспечивающий неблокируемое согласованное чтение данных, управляемый при помощи языка SQL. Существует среднее звено, реализующее идеологию работы с документами, итогами, регистрами учёта, планом счетов и т.п. и обеспечивающее доступ к бухгалтерским данным, хранящимся на сервере, с помощью языка запросов, "заточенного" под бухгалтерские задачи. Существует клиент, который отображает и печатает бухгалтерские данные и вообще обеспечивает взаимодействие человека с бухгалтерским сервером.
В заключение не могу не привести ссылку на проект 1L, посвящённый сходной проблематике.
Директор наш лазил в поисках чего-то подобного и ничего путного не нашел, даже платного! А проблема масштабируемости остается, и апгрейд сервака имеет пределы.
И потом, я повторюсь еще раз, серьезный софт, предназначенный для Большого Бизнеса, очень дорог, дешевле купить 10 компов под серверы (если имеется кластерная архитектура), чем несколько дополнительных лицензий под этот софт.
Teradata, кажись, бесплатная. И кластерная изначально. Из "СУБД вообще" самая мощная реализация кластеров, IMHO, у Oracle и IBM DB2. А проблема масштабируемости указанных СУБД сводится исключительно к проблеме грамотного проектирования структуры данных. Так что директор плохо искал. А по поводу дороговизны софта -- это верно... Oracle 10g Enterprise на 4 процессора стоит с учётом скидок 165920 дохлых американских президентов. Правда, за эти деньги получишь очень много вкусняшек.
Постановки задачи, подобно вашей, возникают исключительно от верхоглядства и непонимания фактических причин проблемы. Так рождаются безнадёжные проекты. И если ему суждено реализоваться, дай бог, чтобы было хоть похоже на 1С (про "лучше" молчу).
Понимаю, если под это дело разрабатывается инновационная платформа, с чётким обоснованием преимуществ. Текущее же описание живо напоминает известный анекдот:
- Я знаю, как защититься от врагов!
- Как?
- Нужно сделать большую красную кнопку. Нажал на неё - и врагам кранты!
- И каким образом?
- Инженеры придумают...
Инженеры уже реализовывают.
Вы представить сколько тогда будет стоить конечный продукт, если использовать дорогие коммерческие СУБД (это конечно хорошо). ИМХО для малого и среднего бизнеса лучше подойдет MySQL или PostageSQL (MySQL поддерживает кластеризацию, PostageSQL не знаю).
Не буду "парировать" каждое ваше предложение, но Oracle точно не подходит. Думаю, даже использование СУБД с поддержкой кластеризации не решит поставленные задачи. 1L (я, если честно, в деталях с ней не знаком, но по поверхностному знакомству я понял, что это как раз нечто подобное 1С) также не канает. Но за ссылки спасибо, ознакомлюсь.
Это я понял сразу. Подобие "1С:Предприятию" я здесь понимаю не как такие же окошки/планы счетов/журналы документов/регистры, а как создание концепции информационной среды и среды разработки, максимально "заточенной" для решения учётных задач. В этом плане "1С" превосходят только такие дорогие и сложные в установке и администрировании продукты как "Аксапта".
Трошки маловат, что ли? Что же это за задачи такие? :wow: Кстати, такие компании, как Центральный банк Российской Федерации, Внешэконмбанк, ОАО «Новосибирскэнерго» и Некоммерческое Партнерство «Администратор торговой системы оптового рынка электроэнергии Единой энергетической системы» Oracle вполне устраивает. ;)
Обязательно ознакомьтесь. Даже если Вас абсолютно не устроит принятая в 1L идеология, полезно знать, чего в выбранной Вами области творчества достигли конкуренты.
Начинаю с конца.
PostgreSQL, который Вы почему-то называете PostageSQL, претендует на звание современной СУБД, но до развитых механизмов контроля доступа к данным, способов хранения данных и работы в кластерах, распределённых БД и работы с большими (десятки терабайт и более) массивами данных ей до Oracle и DB2 ещё очень далеко. Не стОит забывать, что у последних есть специальные подразделения, занимающиеся математическими теориями и методами построения СУБД. Кстати, AFAIK, только Oracle и MS SQL имеют версионный механизм изоляции транзакций, остальные СУБД применяют блокировочный. Вроде бы, какие-то зачатки версионности появились в PostgreSQL, но до изящества Oracle (с неограниченными транзакциями последней) PGSQL пока не доросла.
А MySQL -- вообще не СУБД в современном смысле этого слова.
Теперь о платности.
Директор наш лазил в поисках чего-то подобного и ничего путного не нашел, даже платного! А проблема масштабируемости остается, и апгрейд сервака имеет пределы.
Речь-таки шла и о "СУБД вообще". Я привёл пример СУБД, которая имеет отличную масштабируемость и возможность работы в кластере. То, что она "даже платная" -- соответствует условиям, поставленным в вопросе.
Повторюсь про сервант. Проблемы низкой производительности -- в основном на самом деле являются проблемами плохо проработанной структуры данных и неумелым тюнингом СУБД (впрочем, тюнинг -- последняя стадия оптимизации).
PostgreSQL, который Вы почему-то называете PostageSQL
Извиняюсь за безграмотность.
Я имел ввиду что использование свободной СУБД позволит сократить затраты пользователя на внедрение ПО, что очень важно, особенно для малого и среднего бизнеса. Предприятие просто откажется внедрять ПО, если у него нет денег на это ПО, даже если ПО выполнено очень качественно, обладает огромными функциями.
Я имел ввиду что использование свободной СУБД позволит сократить затраты пользователя на внедрение ПО, что очень важно, особенно для малого и среднего бизнеса. Предприятие просто откажется внедрять ПО, если у него нет денег на это ПО, даже если ПО выполнено очень качественно, обладает огромными функциями.[/QUOTE]
Для малого бизнеса существуют бесплатные версии MS SQL Server, Oracle, IBM DB2. Данные версии имеют ограничения, не позволяющие эксплуатировать их в крупных предприятиях -- например, ограничение размера БД 4 Гб, -- однако для небольшого предприятия это не столь важно. Например, мне по работе довольно часто приходится работать с бухгалтерами и "одноэсовыми" информационными базами. Так вот, не считая форм отчётности, которые, естественно, можно хранить вне БД, сами данные занимают не очень много места -- порядка 200-300 Мб (это за несколько лет работы!) на одно "предприятие малого бизнеса". Надеюсь, никто не станет утверждать, что DBF, используемый платформой 1С:Предприятие оптимально хранит строковые данные...
Более крупные предприятия могут раскошелиться на стандартные версии СУБД, а для предприятий, насчитывающих сотни или тысячи сотрудников, и покупка энтерпрайзовых версий не должна составить особых финансовых проблем.
Как показывает практика, "свобода" и бесплатность мгновенно улетучиваются при первом же серьёзном соприкосновении с бизнесом. Нужно понимать и проводить чёткую грань между (недо)продуктами и решениями. Бизнес всегда интересует последнее.
[QUOTE=>DiN<;198162]Предприятие просто откажется внедрять ПО, если у него нет денег на это ПО, даже если ПО выполнено очень качественно, обладает огромными функциями.[/QUOTE]
Однако, если через несколько месяцев после внедрения (дай бог, чтобы во время него) предприятие столкнётся с ограничением ПО, потери от его эксплуатации превысят мнимые выгоды низкой стоимости.
А вообще, как показывает неумолимая практика, проблемы большинства компаний кроются не в недостатках ПО, а в отсутствии культуры ведения бизнеса - неумении управленцев управлять и банальном разгильдяйстве. Недаром обязательным этапом при внедрении любой серьёзной системы управления предприятием является приведение структуры управления к некоторому стандарту.
Есть распространенные бизнес-приложения, предназначенные для бухгалтерского, управленческого и иного, более специализированного, учета. Однако этот софт платный. Есть приложения подешевле - 1С, к примеру, но тот принципиально не поддерживает распределенное хранение и обработку данных. Другие - я не знаю, возможно поддерживают, но они на порядки дороже.
...многим выгоднее купить лишнюю машину под сервер, чем покупать очень дорогое ПО, поскольку серьезное ПО дороже даже нескольких машин.
О существовании Oracle, Аксапта и пр. авторы проекта прекрасно знают, и их использование не обсуждается. Их бесплатные версии, имеющие ограничения на размер БД и пр., также не обсуждаются, поскольку "бесплатная система" не означает "система для малых организаций". Приводимые примеры насчет Центрального банка и т. п. неуместны, поскольку "крупная организация" не означает "богатая организация" и не означает "крупный бизнес".
еще один принцип проектируемой системы - сильное упрощение обновления системы.
Что мы имеем в той же 1С? Имеется типовая конфигурация, которая "затачивается" (дорабатывается) под конкретное предприятие, в результате чего имеем доработанную конфигурацию. Теперь выходит обновление от самой 1С. Тут и возникают большие сложности - нужно обновить систему так, чтобы доработанный код не потерялся...
Ну, и третий принцип - модульность:
Та же 1С продает конфигурацию целиком, заточенную под "типовое" предприятие. А если организация не использует какие-то подсистемы конфигурации?
Короче говоря, большие конфигурации, конечно, универсальны (меньше затрат на доработку готовой, универсальной, системы под конкретное предприятие), но слишком уж большие, что приводит к ресурсоемкости. У клиента должна быть возможность отключить не используемые подсистемы.
Проект изначально проектировался не как некий аналог СУБД, под которую на каждого клиента отдельно пишутся приложения, а как универсальная система, которую привезли к клиенту и установили. В этом отношении, действительно, есть сходство с 1С.
Авторы жгут! Пусть пишут ещё!
Понятно. Дальше будет много букв, причём практически без разбиения на абзацы, уж не обессутьте.
Лишних денег нет ни у кого -- ни у крупного бизнеса, ни у мелкого. Просто, если хочешь работоспособного решения для своего бизнеса, будь готов выложить соответствующее количество денег за это решение. И чем масштабнее бизнес, тем больше денег стоит решение, что, в общем, логично. Корабельный дизель на 15000 лошадиных сил обычно несколько дороже автомобильного движка на 80 л.с. (а ещё и стоимость монтажа! кстати, Вы никогда не интересовались, как на сейнер движок ставят?), также как H&K MSG-90 будет несколько дороже "мелкашки".
Вы много слов сказали относительно того, что решение должно быть быстрым, надёжным, масштабируемым, модульным и при этом высокодоступным с точки зрения стоимости. Каждая из перечисленных характеристик для любого сколь-нибудь серьёзного проекта -- результат большой работы по изучению и применению современных информационных технологий. Всё это требует времени -- прошу заметить, оплачиваемого! -- квалифицированного специалиста ИТ. Более того, вышеперечисленные характеристики зачастую являются взаимопротиворечивыми, поэтому любой серьёзный программный продукт -- результат долгого пути к компромиссу между всеми этими параметрами качества (см. управление качеством и функционально-стоимостный анализ). Вы же хотите всего и сразу.
Далее, вы говорите, что никакие современные СУБД вам не подходят (да, кстати, а Вы слышали про Caché? Лично я эту СУБД не люблю, но чем чёрт не шутит, вдруг Вам понравится? А если нет, то есть ещё ЛИНТЕР). При этом ни одного аргумента против я так и не увидел, кроме "высокой цены" (что, по вашему мнению, является фатальным недостатком; повторю ещё раз: за высокие технологии в сфере обработки информации приходится платить) и "бесплатно - не значит для малого бизнеса" (без обоснования такого заявления). Фраза, что кто-то безуспешно занимался поиском СУБД, поддерживающих работу в кластере, скорее всего, указывает на то, что искатель либо не умеет пользоваться поисковыми серверами и не знаком с форумами, посвящёнными проблемам СУБД, либо плохо знаком с материалом поиска. Не было приведено никакого сравнительного анализа существующих СУБД с точки зрения пригодности для данного проекта, при этом, как я понял из первого высказывания, есть энтузиазм разработать свою, не реляционную, а учётно-ориентированную (уж простите за такой выдуманный мной термин) СУБД. Мне эти факты напоминают анекдот: "Чукча не читатель, чукча писатель".
Фраза
говорит о малом опыте работы автора в сфере информационных технологий. Программист в любом крупном проекте всегда работает в режиме острого цейтнота, и различные приёмы вроде экстремального программирования могут в лучшем случае слегка ослабить стальную хватку недостатка времени, в основном же они направлены не на ускорение процесса программирования, а на уменьшение ошибок программиста (что, правда, влечёт за собой уменьшение времени на отладку и переписывание кода). Динамично меняющееся российское Положение о Бухгалтерском Учёте только добавляет остроты к обычной нехватке времени программиста.
Я не увидел ни слова относительно того, какими средствами разработки будут пользоваться авторы, относительно же платформы я увидел только слово "Linux". Будет ли использоваться для создания пользовательского интерфейса платформа MONO или же какая-либо другая аналогичная, либо будут использованы высокоинтегрированные Native-Code библиотеки типа QT, либо будет создана своя библиотека, автор не указывает. Впрочем, готов согласиться, что обсуждение выбора конкретной технологии реализации пользовательского приложения у авторов ещё впереди (возможно, авторы посчитают целесообразным создать пользовательский интерфейс на базе WebSphere или Notes...).
Однако, я не услышал ничего о том, какие проекты реализовали авторы до того, как взялись за этот мегапроект и какими информационными технологиями и средствами разработки они при этом пользовались.
Резюмируя вышесказанное, хочу сказать, что проект на данном этапе больше напоминает полное энтузиазма предложение сделать суперпрограмму, которая заткнёт за пояс всех производителей софта, без малейшего представления, при помощи каких технологий всё это будет сделано, т.е. анекдот от Freeman про красную кнопку.
На этом, увы, я теряю интерес к данному проекту. Надеюсь, однако, что хотя бы приведённые мной ссылки будут проанализированы и авторы хотя бы будут знать причины своей неудачи.
......................
сами данные занимают не очень много места -- порядка 200-300 Мб (это за несколько лет работы!) на одно "предприятие малого бизнеса".
Тебе не кажется, что для БД такого масштаба прекрасно подойдет PostgreSQL, к примеру? Причем, работающий не на кластере, а на обычном сервере?
Во всем остальном в твоих постах - полностью согласен.
Пока работа идет на Firebird. Но сменить СУБД - проблема 1 (максимум 2) дней.
Остальным отвечу позже.
По всему видно, суть спора в основном заключается в различной аксиоматике. Цели и задачи данного проекта четко определены, в связи с чем предлагается обсуждать их обоснованность за пределами данной темы.
Предлагается обсуждать в данной теме разрешимость поставленных задач указанными методами.
В противном случае автор бы поместил тему обсуждения в другой раздел, как-то: "базы данных".
Так она задана тобой. Заявления выше о кластерах и распределёнке мало согласуются с
и уж тем более
Для меня это означает, что вы всех возможностей Firebird не используете или болеете одержимостью разработки ПО, "независимого от СУБД".
Остальным отвечу позже.
ЖЖош! Пиши ещё!
Даже если не использовать (что, имхо, просто глупо) расширения SQL, предоставляемые разными СУБД, перенос БД на другую СУБД может быть сопряжён с рядом трудностей, как то различие в концепциях разграничения доступа к данным, различные стратегии оптимизации данных, совпадение наименований полей с зарезервированными словами СУБД и многое другое.
Во всем остальном в твоих постах - полностью согласен.
В условиях задачи говорится про масштабируемость и кластерность. Сегодня ставим клиенту, у которого БД 400 Мб, завтра клиенту, у которого 5 Тб и 10 серверов. И везде одна и та же СУБД.
У меня другой вопрос на языке вертится: почему до такой гениальной идеи не додумались ни Micro$oft, ни Oracle, ни 1С, ни Парус, ни какая бы то ни было другая фирма, имеющая опыт в разработке учётно-ориентированного софта.
На нашем предприятии решение взяли от Oracle
Инженеринг делали IBM совместно с Borlas
Реализацию делал Oracle
Заплачено более 3 мил $
итог: некоторые ежедневные отчеты готовятся 40 минут
бухгалтерские отчеты за месяц готовятся сутки (иногда больше)
это я к слову о специально обученных людях
Инженеринг делали IBM совместно с Borlas
Реализацию делал Oracle
Заплачено более 3 мил $
IBM создаёт решение на базе Oracle? Более чем странно... Кто такая Borlas -- не знаю.
бухгалтерские отчеты за месяц готовятся сутки (иногда больше)
это я к слову о специально обученных людях
Это ни о чём не говорит. Каков объём исходной информации, нагрузка на сервер, конфигурация сервера, какова сложность отчёта? В конце концов, сколько времени такой же отчёт на аналогичном оборудовании создаётся при использовании другой СУБД (DB2, PosgreSQL)?
У меня по внедрению (и "вынедрению") Oracle есть обратный опыт. Было ПО с БД под Oracle 8.0.5, перешли на MS SQL Server 2000, стало в 3 раза медленнее несмотря на апгрэйд серванта. В другом месте был Clarion 2 (DOS), перешли на Oracle, по скорости примерно так же, зато куча народу одновременно работает с одной БД, ничего не рушится (в отличие от кларионовской версии, где периодически приходилось пересоздавать индексы) и отчёты получаются не в пример более крутые, и "горячее" резервное копирование можно делать. В некоторой организации был Access, ПО затыкалось на 5 юзерах, переписали под MS SQL Server 2000, стало затыкаться на 25 юзерах (прогресс!), переписали под Oracle, полсотни юзеров работают уже года два без всяких затыков.
Считается крутой компанией и хорошей строчкой резюме в Москве.
Нет, IBM проводила общий базовый инженеринг
Борлас http://borlas.ru/ создавала бизнес процессы (совместно с нашими сотрудниками)
Это ни о чём не говорит. Каков объём исходной информации, нагрузка на сервер, конфигурация сервера, какова сложность отчёта? В конце концов, сколько времени такой же отчёт на аналогичном оборудовании создаётся при использовании другой СУБД (DB2, PosgreSQL)?
В общем, то верно, не говорит.
Но говорит другое - люди тоже самое делали в экселе(!!) с общим доступом, было трудновато, но с внедрением Oracle трудочасы тех же сотрудников увеличилось 1.5 раза, домой стали уходить не 17:30 а 18:30-21:00 (благо корпоративная стоянка в 21:00 закрывается) и это уже в течение полутора лет, и стало как нормой. Вот и сейчас пятница, домой бы еще полчаса назад уйти, пиво пить, но сижу, жду жену, когда освободится.
Сам я участия в проекте не имел, только наблюдал со стороны, поэтому конкретных цифр о нагрузках сказать не могу.
С тем, что надо двигать технологию вперед я не спорю. Но в данном конкретном проекте по моему что то перемудрили.
Да и говорю я не про сам Oracle а то что на нем создали
В данном конкретном случае, скорее всего, имеет место некомпетентность аналитиков, ставивших постановку. Как в анекдоте про консультанта и пастуха. Без владения ситуацией сестрам по серьгам раздавать не буду, ограничусь лишь общей фразой о методах прое- и нае-бизнеса.
"Эта обитель нелюдей превращает человека в монстра." (с) Если есть возможность, меняй работу.