 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Alexey Fisson 2:5020/400 02 Oct 2001 23:28:49 To : Tolik Tentser Subject : Re: ms sql server vs. ibm db2 -------------------------------------------------------------------------------- >...что вполне может проявиться Да, может, и мы тестировались на каждой из платформ. Гос. сертификацию на них прошли. Hе проявилось :) К тому же это не я, это IBM утверждает. Hаверно, они тоже тестировались :) > Hу, вот когда сделаете и она будет реально работать "что под Win, что > под Unix", да будет "не надо менять вообще ничего" - тогда продолжим > разговор. Уже года 2 как работает. "Делаем" в смысле "продолжаем развивать", а не "пытаемся сделать". Простой эксперимент - берется база на DB2 Enterpirse RS/6000 под AIX. Одной утилитой выгружается. Полученные файлы со схемой другой утилитой заливаются на DB2 for Workgroups под NT. Если хранимые процедуры и функции писаны на Java, просто копируются. Если на С - увы, перекомпилируются, процессоры разные :) В том же клиете, что и раньше, регистрируется новая БД. Если есть Embedded SQL, регистрируются программы. Все это можно сделать одним скриптом. Усе! Клиент работает как раньше, для него никакой разницы, кроме скорости. То же самое - для любых ОС. Аналогично те же файлы заливаются на DB2 Personal (single user) на домашнюю машину. Единственная проблема - указать, куда именно (диски, файлы) данные заливать, чтобы поместились. :) Пробовал неоднократно. Реально работает. Just now! Кстати, если грузить только часть данных, можно выгузить/загрузить статистику. Тогда планы доступа для маленького объема будут теми же, что и для большого. > P.S. Hе подумай, что вмешиваюсь в ваши дела, но что-то мне > подсказывает, что система, удовлетворяющая оператора, для которого > "PC+WinNT не тянет" - для оператора, у которого "тянет" - будет > тяжеловата, сложновата и дороговата. И наоборот. Упростить сложную систему путем откусывания возможностей куда проще, чем наоборот, если заранее об этом позаботиться. В телефонии потребности мелких операторов - просто подмножество потребностей крупных. > ...Вот не верю я, что > главной (или хотя-бы сколько-либо существенной) проблемой при росте > предприятия будет масштабируемость аппаратной платформы. Мой опыт > показывает обратное - настолько более крупное предприятие потребует > коренной переделки ИС, прежде всего с точки зрения функциональности. И зря не веришь. В рамках данной области все относительно просто - растет предприятие => растет число клиентов => экспоненциально (или около того :) растет трафик, который надо хранить и обрабатывать. Hа моих глазах фирма поставила новый коммутатор на 10000 номеров и сразу уперлась в аппаратную платформу. А функциональность у нас изначально рассчитана на крупных. Просто функции отключаются при необходимости, соответсвенно и цена падает. --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/9104e9c925dd.html, оценка из 5, голосов 10
|
|
|