iScala Enterprise — что это?

Автор Сообщение
Juri
Заслуженный форумщик

Зарегистрирован: 18.10.2004
Сообщения: 99
Откуда: Tallinn Estonia

Добавлено: 20.09.2005 16:16 Заголовок сообщения: iScala Enterprise — что это?
Господа, кто имел какой-либо опыт работы с iScala Enterprise версией? Суть проблемы в том, что у нас появилась необходимость работы с удаленными компаниями в др. государствах Балтии. Хотим работать с одного сервера. Нам предлагают приобрести Enterprise версию, разделить базы, работать в unicode. Однако же такого опыта нет ни у нас, ни у других предприятий в этом регионе. Может кто-то что-то подскажет?
E-terminator
Почетный форумщик

Зарегистрирован: 03.01.2005
Сообщения: 46
Откуда: град Св. Петра

Добавлено: 21.09.2005 11:16 Заголовок сообщения:
Существуют два издания iScala server — Enterprise Edition и Standard Edition. В изначальных планах было 2 существенных отличия Enterprise от Standard:
1. Возможность иметь распределенную базу данных (бизнес данных, системная DB одна)
2. Поддержка UNICODE
После выхода «в свет» iScala выяснилось, что Standard также поддерживает UNICODE. На SQL server текстовые поля имеют тип NCHAR, NVARCHAR. И система печати начиная с SR1 работает по «печатным движком» Crystal Print Engine 9.x, разбирающимя с UNICODE.
Возможность иметь распределенную базу данных означает, что данные по различным компаниям можно иметь в различных DB, возможно на разных SQL серверах. Однако… Это не предназначено для возможности иметь такие базы на удаленных серверах, т.к. тут возникает вопрос о пропускной способности связывающего их канала. Т.о. реально эта возможность может быть полезна только для повышения performance системы в случае если есть физически другой SQL сервер и есть более-менее распараллеленная работа пользователей в нескольких компаниях.
Для реально удаленной работы Scala предлагает Connectivity Solution, но это уже обсуждалось ранее.
aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 21.09.2005 11:31 Заголовок сообщения: Терминальное подключение — вот о чем можно подумать
Мне кажется, что iScala Enterprise в данном контексте не более, чем маркетинговая уловка или же следует говорить о том, что человек, предлагающий ее, сам не шибко понимает, о чем идет речь.

Возможно стоит подумать об обычном терминальном подключении, что при наличии канала с неплохой пропускной способностью весьма работоспособное решение.

Juri
Заслуженный форумщик

Зарегистрирован: 18.10.2004
Сообщения: 99
Откуда: Tallinn Estonia

Добавлено: 21.09.2005 15:22 Заголовок сообщения: Re: Терминальное подключение — вот о чем можно подумать
Господа, спасибо за информацию! По поводу этого:

aav писал(а):
Мне кажется, что iScala Enterprise в данном контексте не более, чем маркетинговая уловка или же следует говорить о том, что человек, предлагающий ее, сам не шибко понимает, о чем идет речь…


.. я пришел примерно к таким же подозрениям. Потому как, действительно, Standart версия вполне поддерживает UNICODE, правда надо докупать скаловский прибамбас, что-то типа «Unicode for Business Server». И хотя этот прибамбас тоже не шибко дешевый, тем не менее, этот вариант вполне рабочий и значительно дешевле чем апгрейт на Enterprise версию. Кроме того, горящие глаза и воодушевленный вид продавца Enterprise версии наводят на определенные размышления по поводу особенностей отчетности по продажам продуктов SCALA за определенный период. Хотя вопрос разделения базы может у нас стать актуальным через какое-то время, много компаний развелось.
Что касается терминального подключения, то, собственно говоря, оно так и планируется. Тем более, что сегодня у нас вполне корректно в таком режиме работают около 10 точек из четырех городов Эстонии.

Jugulator
Главный форумщик

Зарегистрирован: 08.10.2004
Сообщения: 428

Добавлено: 21.09.2005 15:25 Заголовок сообщения:
Если пытаться подключить больше одной БД в Standard, то iScala выдаст сообщение, что опция Multiple Databases не лицензирована. В принципе, использование нескольких баз может иметь смысл и на одном SQL-сервере, имеющем несколько дисковых массивов, т.е. используемом для реально немаленьких БД. На одном дисковом массиве разбиение БД на части вряд ли имеет смысл, кроме, разве что, раздельного полного резервного копирования целых баз компаний, которое тоже непонятно зачем может понадобиться.