Цитата: 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 и один из соавторов выбора СУБД для дальнейшего развития системы.