Галактика в вопросах и ответах

См. выше. Приведен расчет стоимости владения для покупателей. Но аналогичный расчет нужно сделать и для инвестиций в разработку. Если расчеты покажут, что это выгодно, то новый движок не заставит себя долго ждать.

LaaLaa писал(а):См. выше. Приведен расчет стоимости владения для покупателей. Но аналогичный расчет нужно сделать и для инвестиций в разработку. Если расчеты покажут, что это выгодно, то новый движок не заставит себя долго ждать.

Для правильного расчета нужно как минимум провести анализ потребительского рынка и долю конкурентов, на которую можно замахнуться. Я так понимаю при выпуске Галактика-Старт и Галактика-Прогресс данные анализы проводились, иначе бы не было таких конфигураций, рассчитанных явно на сегмент малого бизнеса, но вот идея дальше почему-то не пошла. А суть идеи следующий: для сегмента малого бизнеса начальная цена владения должна быть снижена максимум. Да, это сделано по отношению к стоимости самой Галактики, но вот по отношению к используемым СУБД не приложили труда.
Если бы изначально действительно сделать открытым часть кода прослойки Галактика-СУБД, то думаю партнеры бы приступили к разработке собственных наборов библиотек под другие СУБД и это дало бы действительно очень большой толчок для продвижения продукта на рынке. Суть в том, что клиент сам сможет в конечном счете выбирать СУБД. Да, местами часть функций специфичных может и не поддерживаться, как в случае с тем же первасивом, для которого есть возможность из випа работать с таблицами разных БД, а вот в том же МС СКЛ не реализовано, так и не хай с ним, главное, что основной набор работает и клиенты могут выбирать, первасив, мс скл или оракл, но надо расширить границы выбора.

Тот же клиент будет размышлять так: если я могу поставить на бесплатном СУБД базу сэкономив денежки и не нарушив авторских прав, то можно сэкономленную сумму пустить на дополнительные лицензии. Клиенты же с большими объемами данных и большим кол-вом пользователей заведомо имеют возможность (хотя зачастую не хотят ею пользоваться) на приобретение того же оракла.

Все верно.

LaaLaa писал(а):Все верно.

А если все верно и как ранее вами было озвучено, что сложностей в этом нет, то может стоит приступить либо к закрытой разработке корпорацией набора библиотек для работы хотя бы с одной из бесплатных СУБД, либо к разработке инструментария, позволяющего самим партнерам к примеру производить доработку для работы с другими СУБД, либо открыть код, который отвечает за работу с СУБД?

Ведь ни кто не просит открыть часть, отвечающую за лицензирование

хотя бы с одной из бесплатных СУБД

Btrive раньше был тоже бесплатным.

galover писал(а):LaaLaa
Были бы прозорливей - предоставили интерфейс/контракт/соглашение (можно взять за реализацию тот же COM), остальное бы различные вендоры и комьюнити реализовали. Так во всех ORM системах сделано. DAL слой - это просто работа с интерфейсом, реализация м.б любой, т.е.
Так кстати сделано с OPC серверами - есть интерфейс, который разработал комитет и есть куча реализаций от сторонних компаний, клиент просто работает с неким абстрактным сервером

Напрашивается вопрос, почему стомость Г-ки на разных платформах отличается?

Напрашивается вопрос, почему стомость Г-ки на разных платформах отличается?

Начинающий путь
вы о чем? я писал о технической стороне - о том как надо, а не о том как есть

Начинающий путь писал(а): Напрашивается вопрос, почему стомость Г-ки на разных платформах отличается?

Это как комплектация авто Есть побюджетнее варианты, а есть для "реальных пацанов".

Некорректное сравнение.
Галактика под ораклом ничем не отличается от Галактики под первазивом (смехотворное количество служебных объектов базы не в счет). Логичнее продавать было Галку с фиксированной наценкой на СУБД(за то что драйвер разработали) , а не привязываться к лицензиям (ну НИЧЕГО нет в функционале разделенное под использование конкретной СУБД). Есть западные продукты ориентированые на оракл и мсскл и стоящие по-разному, но там прикладной ф-ал лежит на хранимых ф-иях и процедурах, которые для обеих СУБД пишутся отдельно.

oiko писал(а):Некорректное сравнение.
Галактика под ораклом ничем не отличается от Галактики под первазивом (смехотворное количество служебных объектов базы не в счет). Логичнее продавать было Галку с фиксированной наценкой на СУБД(за то что драйвер разработали) , а не привязываться к лицензиям (ну НИЧЕГО нет в функционале разделенное под использование конкретной СУБД). Есть западные продукты ориентированые на оракл и мсскл и стоящие по-разному, но там прикладной ф-ал лежит на хранимых ф-иях и процедурах, которые для обеих СУБД пишутся отдельно.

Нее, смотрел в прайсах - отличается

Если по серьезному, у меня сложидось двоякое отношение к Г-ке под разными СУБД

1. Pervasive, вернее Btrieve, наследие еще с ДОС'осовских времен, у
нас мало распостранена, поэтому русскоязычной литературы не встречал. В доке по Г-ке настройки его минимальны. Г-ка на этом движке достаточно функциональна (судя по форуму) и дешевле.

2. MS SQL и Oracle распостренены более. Имеется масса литературы на русском языке и есть множество курсов. Но есть проблемы у Г-ки (судя по форуму, один свал при переходе ЗП у МS SQL чего стоит).


о

Отличие есть, причем серьезное
- PVSW для мелко-сердних БД, MSSQL и Oracle для более серьезных размеров
- PVSW не требуют больших навыков администрирования, не в пример MSSQL и Oracle.

PVSW нужен, вы же не прийдете к клиенту продавать Прогресс + Oracle в мелкую контору

Ага, в мелких конторах с большим удовольствием покупают первасив.
Особенно тот, что лежит на фтп вместе с кейгеном

Нашел интересный транслятор, здесь: WIKI: SELTA@Etersoft или здесь: родной сайт, правда, платный. никто не пробовал к Галактике "применить"?
Может разработчики могут что по этому поводу сказать?

Исследования продукта SELTA@Etersoft на предмет использования для Галактики не проводились.

Были исследования только их продукта WINE@Etersoft и оригинального WINE. О результатах читайте на мниском форуме http://forum.galaktika.by/viewtopic.php?p=2120#2120

Ребят, смотрите в корень - Галактика - это все-таки система для обработки бооольших объемов структурированных данных...
Поэтому "что-то типа MySQL" использовать ну никак низяя.... Вы бы еще "Волгу-DB" вспомнили

Норальной системе нужны наиболее скоростные из наиболее распространенных СУБД