[ОТВЕТИТЬ]
Опции темы
22.09.2010 07:50  
FILBOR
Цитата:
Сообщение от VerLeon
Политика партии изменилась... Если коротко, то она звучит наверное так: наша ниша - мелкие и средние предприятия, а там и FB хватает.
А вообще очень жаль... Там почти все уже готово было, когда заморозили проект...

Но, впрочем, Оракл - это гут, конечно, но он интересен больше для аналитики, а для этого у нас есть шлюз на него и там - больше десятка отчетов на базе Oracle BI.
Понятно, ну вот кстати у вас в Новосибе политика партии отличается от политики Еката (хотя может я ошибаюсь)... а по FB сказать особо ничего не могу, я не спец по СУБД.
 
01.10.2010 22:49  
Опытный разведчик
Политика везде одинаковая и на Урале и в Сибири и даже в Китае - порог для S-Market сети с оборотм до 300 мегабаксов в год (если мы говорим о продуктовых сетях). Это где-то 30-40 тыс. метров торговой площади или 300 касс.
Все остальные уже могут позволить себе полноценную ERP если исходить из принципа, что ИТ бюджет в рознице = 0,7-1,0% от оборота.
 
01.10.2010 22:56  
Опытный разведчик
Цитата:
Сообщение от AlexeiDK
С-Маркет - система развивается довольно давно, вполне работоспособный продукт.
DK Link Front Office - сырое решение, у нас поработало в магазине чуть больше полугода, так от глюков и не удалось избавиться (решали одни, возникали другие), поменяли на Set Retail 5.
А давно дело было? Это уже 2-я версия или что-то из первых релизов?
 
02.10.2010 00:17  
VerLeon
Цитата:
Сообщение от Опытный разведчик
Политика везде одинаковая и на Урале и в Сибири и даже в Китае - порог для S-Market сети с оборотм до 300 мегабаксов в год (если мы говорим о продуктовых сетях). Это где-то 30-40 тыс. метров торговой площади или 300 касс.
Все остальные уже могут позволить себе полноценную ERP если исходить из принципа, что ИТ бюджет в рознице = 0,7-1,0% от оборота.
Я вот промолчал, так как не совсем понял о какой именно политике говорит уважаемый FILBOR.
Если о политике продаж S-Market - то тут да - на сегодняшний день S-Market именно таков. По достижению этих порогов люди уходят на SAP, ну и.. этим все сказано. Могу только отметить, что переходы эти у нас пока единичны и очень неоднозначны по результатам.
Но разговор вроде шел про пути развития, т.е. о перспективах и целях. Тут политика и устремления могут отличаться не то что в Сибири и на Урале, а в мозгах отдельно взятых руководителей и даже внутри команды разработчиков :) И вопрос о выборе СУБД вовсе не однозначно коррелирует с объемом оборотов наших потенциальных клиентов.
Но в целом - конечно на нишу SAP мы не посягаем, наши приоритеты сейчас (общие по корпорации во всех регионах) - скорее горизонтальное развитие, предоставление более полного и эффективного функционала в своей нише.
 
04.10.2010 10:08  
John Doe
Цитата:
Сообщение от Опытный разведчик
Политика везде одинаковая и на Урале и в Сибири и даже в Китае - порог для S-Market сети с оборотм до 300 мегабаксов в год (если мы говорим о продуктовых сетях). Это где-то 30-40 тыс. метров торговой площади или 300 касс.
Все остальные уже могут позволить себе полноценную ERP если исходить из принципа, что ИТ бюджет в рознице = 0,7-1,0% от оборота.
Звучит, как "наши поезда самые поездатые поезда в мире". Откуда эти цифры? Какой объем хранимых данных и как рыдают юзера, пользуясь отчетами на движке, который не предназначен для больших объемов? Более чем уверен, что помимо основного ядра на 300 касс, еще существует куча допилов и доработок с костылями, которые бы худо-бедно могли сводить концы с концами отчетности, причем, скорее всего, на других серверах и, возможно, в других системах. Или эта гордая цифра в мегабакс выручки с кассы в год. Хорошая проходимость для 300 касс. Вы автоматизировали МЕТРО? Я что-то не прикину другой продуктовой сети такого масштаба. Или это "сферический конь в вакууме"? Теоретические, неподтвержденные выкладки.
 
04.10.2010 15:28  
Опытный разведчик
Цитата:
Сообщение от John Doe
Звучит, как "наши поезда самые поездатые поезда в мире". Откуда эти цифры? Какой объем хранимых данных и как рыдают юзера, пользуясь отчетами на движке, который не предназначен для больших объемов? Более чем уверен, что помимо основного ядра на 300 касс, еще существует куча допилов и доработок с костылями, которые бы худо-бедно могли сводить концы с концами отчетности, причем, скорее всего, на других серверах и, возможно, в других системах. Или эта гордая цифра в мегабакс выручки с кассы в год. Хорошая проходимость для 300 касс. Вы автоматизировали МЕТРО? Я что-то не прикину другой продуктовой сети такого масштаба. Или это "сферический конь в вакууме"? Теоретические, неподтвержденные выкладки.
Отсечка такая поставлена исходя из практики. Я вобщем то регулярно практикую с 2003 года этой софтиной. Чтобы юзера не рыдали как раз и сделана эта отсечка. Ну а на больших базах (более 50Gb) можно разгрузить систему внешним аналитическим "допилом" (BI).
 
04.10.2010 15:32  
John Doe
А, т.е. хранятся не все данные и база режется? Ну это не интересно...
 
05.10.2010 13:25  
Опытный разведчик
Цитата:
Сообщение от John Doe
А, т.е. хранятся не все данные и база режется? Ну это не интересно...
Отсечка - в данном случае маркетинговая, чтобы сохранить одинаково приемлемое юзабилити как на больших так и на малых объемах данных. В софте ничего принудительно не режется, хотя есть программная возможность складывать древние периоды в архив.
 
05.10.2010 13:28  
John Doe
К сожалению, у нас разные понятия "большие базы". 50Гб, это маленькая база. О неспособности firebird работать, как именно хранилище крупных объемов я и говорил. А 300 касс, это сходу в первый год 50Гб. Потом помедленнее.
 
19.11.2010 17:45  
VerLeon
Цитата:
Сообщение от John Doe
К сожалению, у нас разные понятия "большие базы". 50Гб, это маленькая база. О неспособности firebird работать, как именно хранилище крупных объемов я и говорил. А 300 касс, это сходу в первый год 50Гб. Потом помедленнее.
Раз автор этого развития темы замолчал, отвечу я. Разведчик больше понимает в коммерции, я же - разработчик, так что извините, если какие-то мнения покажутся наивными с точки зрения продаж ПО.

1. 300 касс - отсечка, туда мы как раз не лезем. Так что там в первый год и во второй - уже не особо важно. Но хочу обратить внимание, что отсечка - коммерческая. Предприятия такого масштаба имеют большое количество денег на автоматизацию и большие запросы по функционалу и тут выплывает тот же SAP. Да, FB, по крайней мере так, как мы его используем - будет шевелиться с трудом, но уходят с нашей системы (развиваясь до такого уровня) не только, а может и не столько поэтому - нам не хватает функционала, чтобы на равных спорить с SAP. Потому мы работаем в сегменте ниже этого предела - и здесь предел производительности FB нас устраивает.

2. Про размеры базы. Эти цифры откуда? 300 касс, 50 Гб в первый год? Это эталон? В любой системе товародвижения с любой спецификой на любой СУБД будет 50 ГБ? Думаю, Вы говорите про системы, которые Вы ведете, на вполне конкретной СУБД (и это не FB). Или Вы имеете в виду 50 ГБ только кассовой ленты? Ну тогда, извините, Вы не правы, 50 гигов кассовой ленты за год не будет и у 300 касс (это просто мечта какая-то ритейлеров). Если конкретно сравнивать FB и Oracle (давайте откровенно - мы же про это говорим), то у FB аналогичные базы обычно меньше - FB прост, как 3 рубля, у него нет издержек на оракловые навороты. Так что, IMHO, говорить про размеры базы абстрактно - некорректно.
Кстати, могу дать ссылочку на TPC-тест FB на базе в 1 Тб - результаты впечатляющие, но опять же абстрактные.

3. Пожалуй даже самое важное. О чем спор? Что Oracle круче FB? Язык, масштабируемость, кластерность, партишионинг, средства репликации и еще многое-многое-многое? Конечно, смешно об этом спорить. Здесь даже PostGRE во многом делает FB (по крайней мере пока). Вылезает очень остро действительно на больших объемах баз.
Но Вы же сами прекрасно знаете и минусы "крутых СУБД". Это стоимость владения. Я не говорю даже про цены на саму СУБД. Сколько стоит оракловый DBA (кстати и PostGRE тоже)? А на FB он на начальном этапе развития торгового предприятия ВООБЩЕ не нужен. Мы (ДатаКрат) осуществляем поддержку небольшим предприятиям за символические деньги абонентской платы - не потому что мы меценаты, а потому что она по сути не очень-то и нужна (в плане обслуживания самой базы) . И не только на начальном. Я могу привести примеры множества средних предприятий (20-30 касс), работающих на нашей системе (ну здесь важно - на FB), где функции DBA исполняет штатный сисадмин, который с трудом шарит вообще в СУБД и SQL.
По мере развития предприятия - да, возникают проблемы, но.. см. п1. - когда предприятие перерастает технические возможности СУБД, то оно перерастает и функционал нашей системы. В этом плане мы работаем, но до SAP нам далеко, как впрочем всем отечественным системам.
Ну в общем вопрос - зачем платить за реактивный самолет, если когда его скорости реально понадобятся, то надо будет покупать истребитель с серьезным вооружением? Наше мнение - не надо. Пока вам хватает. Ту-154 - летайте на нем, когда перестанет хватать - у вас будет достаточно денег, чтоб купить флотилию МиГ-31

P.S. Пожалуй, несколько погорячился, с "наше мнение". Корпорация у нас немаленькая и различных мнений по перспективам много на разных уровнях. Консолидированное - Вы можете увидеть в текущем развитии продукта. Ну а здесь я выражаю мнение исключительно свое, как один из разработчиков S-Market и один из соавторов выбора СУБД для дальнейшего развития системы.
 
 


Опции темы



Часовой пояс GMT +3, время: 08:54.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.