|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
Александр Гoлдун Эта середина в каждом конкретном случае определяется индивидуально по многим критериям, основные из которых, это вероятность обрыва канала, стоимость простоя, стоимость решения, снижающего критичность обрыва. Согласен, но в случае обрыва канала, о какой репликации вообще может идти речь? Через дискетку? А это что, не простой? Беру простейший пример, когда имеем единый склад и два офиса. Остатки должны быть онлайновыми, ибо даже задержка в пол. минуты чревата необъективными остатками, а значит их уходом в минус, что недопустимо. Ну и как разрулим такую ситуацию репликацией? Александр Гoлдун Кроме эмоций перечень этих "любых серверов" мы увидим или нет? А как еще реагировать на выпад про компетенцию? Как говориться, если Вы такой самый умный, почему тогда не богатый. Если бы все так замечательно было в SyBase как тут расписывается, он бы не стоял на последних ролях при выборе SQL сервера. Наберите http://www.sql.ru/forum/actualforum.aspx Там найдете тот самый список. И тот самый рейтинг. Объясните почему такой изумительный во всех отношениях сервер так у нас не популярен. Мне действительно интересно. Потому как всегда приятно юзать недорогой производительный SQL Server. К тому же как часто бывает заказчик тоже принимает участие в выборе(эт наша действительность), хотя по идее это не его вопрос в принципе. Александр Гoлдун Там, где предполагается репликация - именно так. Причем учитывать репликацию надо еще до проектирования БД, на этапе проектирования бизнес-процессов, описания потоков документов и т.п. Если же возможно не предполагается репликация, то я просто _нормально_ проектирую систему и БД в том числе. В большинстве случаев просто качественное проектирование значительно упрощает в дальнейшем любое развитие системы, в том числе и включение репликации Правильно, я же говорил о некоторых ограничениях при проектировании. Мне сказали что это не так. Сейчас Вы повторяете мою мысль. Ибо что это, как не некоторые ограничения. Ну да бог с ними. Это действительно дело проектировщика-как ему рисовать базу. Но вот термин "Нормально спроектирована" - достаточно неопределенный. Тогда уж давайте говорить о конкретных задачах, а не о БД в целом. Каждый подход имеет право на жизнь в определенных задачах, а не в абсолютно любых условиях. Чуть Выше задачка про единый склад... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 18:38 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
OTiger Александр Гoлдун Эта середина в каждом конкретном случае определяется индивидуально по многим критериям, основные из которых, это вероятность обрыва канала, стоимость простоя, стоимость решения, снижающего критичность обрыва. Согласен, но в случае обрыва канала, о какой репликации вообще может идти речь? Через дискетку? А это что, не простой? Беру простейший пример, когда имеем единый склад и два офиса. Остатки должны быть онлайновыми, ибо даже задержка в пол. минуты чревата необъективными остатками, а значит их уходом в минус, что недопустимо. Ну и как разрулим такую ситуацию репликацией? А кто сказал, что репликация - панацея от всего? Если бизнес-процесс в принципе не допускает задержек в полученнии информации, тогда кроме переделки этого процесса ничего не поможет. В описанной ситуации по крайней мере можно работая со своей частью БД провести другие действия, не требующие немедленного отражения в центральной базе, например принять предварительный заказ и т.п. OTiger Александр Гoлдун Кроме эмоций перечень этих "любых серверов" мы увидим или нет? А как еще реагировать на выпад про компетенцию? Как говориться, если Вы такой самый умный, почему тогда не богатый. Если бы все так замечательно было в SyBase как тут расписывается, он бы не стоял на последних ролях при выборе SQL сервера. Наберите http://www.sql.ru/forum/actualforum.aspx Там найдете тот самый список. И тот самый рейтинг. Не будучи социологом, я воздержусь от упоминания таких терминов, как например репрезентативность выборки для определенных показателей И как предъявленный список показывает наличие у серверов штатных средств оффлайновой репликации? Ладно, пойдем по списку MS SQL - по крайней мере до версии 2000 только средства он-лайн репликации IB/FB - никакой штатной поддержки. Есть огромно море сторонних репликаторов разного качества. Многие реализуют для своих проектов средства репликации самостоятельно, по новой изобретая велосипеды для транспортного уровня, разрешения конфликтов, обеспечения целостности последовательности и т.п. Oracle - уважаемый сервер, но: 1, 2 , 3 , 4 В общем, штатные средства для off-line не упоминаются Про IBM DB2 gardenman уже рассказывает. PostgreSQL - слышал, одно время ходила идея использовать там решения от от Sybase Informix - не знаю. Другие СУБД - Линтер - можно сказать, что есть штатная офф-лайн репликация, хоть и отдельный продукт DbSync, но по крайней мере производимый тем же релексом. Ну и где тут "любой приличный SQL Server"? OTiger Объясните почему такой изумительный во всех отношениях сервер так у нас не популярен. Мне действительно интересно. Потому как всегда приятно юзать недорогой производительный SQL Server. К тому же как часто бывает заказчик тоже принимает участие в выборе(эт наша действительность), хотя по идее это не его вопрос в принципе. Ну, это уж вопрос не технический, а скорее маркетинга. OTiger Александр Гoлдун Там, где предполагается репликация - именно так. Причем учитывать репликацию надо еще до проектирования БД, на этапе проектирования бизнес-процессов, описания потоков документов и т.п. Если же возможно не предполагается репликация, то я просто _нормально_ проектирую систему и БД в том числе. В большинстве случаев просто качественное проектирование значительно упрощает в дальнейшем любое развитие системы, в том числе и включение репликации Правильно, я же говорил о некоторых ограничениях при проектировании. Я ж говорю, репликация - не панацея от всего. Эти ограничения - не ограничения технологии репликации, а принципиальные ограничения, накладываемые особенностями бизнес-процессов. Для упрощения понимания иногда стоит в уме выбросить компьютеры и разрисовать чисто бумажный документооборот и схемы взаимодействия. OTiger Чуть Выше задачка про единый склад... И эту задачку можно разрисовать для бумаги с курьером, чтобы понять, применима ли в принципе тут репликация. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 19:34 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
OTiger Объясните почему такой изумительный во всех отношениях сервер так у нас не популярен. Мне действительно интересно. Потому как всегда приятно юзать недорогой производительный SQL Server. Welcome в форумы "Сравнение СУБД" и "Sybase ASA, ASE, IQ" чтобы не превращать этот форум в их филиалы. Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 19:40 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
Следуя логике брать в расчет только попсовые решения MSSQL/Oracle, по тому же SQL.RU получается, что IBM DB2 очень непопулярный и никому не нужный продукт, а еще самые популярные и лучшие - это FB/Access/FoxPro. Только вот тот же DB2 или Sybase за рубежом имеют другую популярность и что ASA, что DB2 имеют на борту очень приличные решения (про ASE молчу). Вот почему IBM или Sybase имеют такой малый процент распостранения в России - это нужно их маркетологов спрашивать, вернее уж спрашивать маркетологов IBM, с Sybase я и так достаточно знаю почему. Я даже больше скажу - если бы ASA загнулась и прекратила свое постоянно ежемесячное развитие и рост популярности за бугром, я стопроцентно бы перешел на DB2, но уж никак на MSSQL или Oracle. Хотя слава богу, ASA и не подумает загибаться и по последнему исследованию Garter имеет очень и очень неплохие перспективы, в отличие от того же Sybase ASE. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 20:19 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
Александр Гoлдун OTiger Александр Гoлдун Эта середина в каждом конкретном случае определяется индивидуально по многим критериям, основные из которых, это вероятность обрыва канала, стоимость простоя, стоимость решения, снижающего критичность обрыва. Согласен, но в случае обрыва канала, о какой репликации вообще может идти речь? Через дискетку? А это что, не простой? Беру простейший пример, когда имеем единый склад и два офиса. Остатки должны быть онлайновыми, ибо даже задержка в пол. минуты чревата необъективными остатками, а значит их уходом в минус, что недопустимо. Ну и как разрулим такую ситуацию репликацией? А кто сказал, что репликация - панацея от всего? Если бизнес-процесс в принципе не допускает задержек в полученнии информации, тогда кроме переделки этого процесса ничего не поможет. В описанной ситуации по крайней мере можно работая со своей частью БД провести другие действия, не требующие немедленного отражения в центральной базе, например принять предварительный заказ и т.п. Так всю дорогу мне это доказывают, отметая вариант удаленного доступа начисто, объясняя это возможностью обрыва связи. Хотя если клиент хочет онлайн работы-и он может обеспечить устойчивую связь-почему бы и нет? Теперь Вы предлагаете поменять бизнес процесс предприятия. Это уже совсем весело получается... Как можно еще поменять бизнес процесс работы банального оптовика, у которого сидят десятки менеджеров и беспрерывно колбасят накладные отгрузок? Отсутствие остатков и резервирования фатально. Нет, можно конечно выделить каждому офису по складу-но это не решение... Или предложить всем менеджерам переехать в одно здание:) Александр Гoлдун И эту задачку можно разрисовать для бумаги с курьером, чтобы понять, применима ли в принципе тут репликация. Это было бы интересно посмотреть.:) Касабельно серверов и репликаций: на том же MSSQL вполне все делается. Может конечно не так красиво как у SyBase:), но вполне действенно, если конечно не зацикливаться на Offline репликации как панацее. Полагаю, к единому мнению мы не прийдем, просто потому что у нас разные задачи. В решении моих задач offline смерти подобен. В решении Ваших видимо удачно используется. Думаю на том и закруглимся:) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 20:50 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
ASCRUSСледуя логике брать в расчет только попсовые решения MSSQL/Oracle, по тому же SQL.RU получается, что IBM DB2 очень непопулярный и никому не нужный продукт, а еще самые популярные и лучшие - это FB/Access/FoxPro. Только вот тот же DB2 или Sybase за рубежом имеют другую популярность и что ASA, что DB2 имеют на борту очень приличные решения (про ASE молчу). Вот почему IBM или Sybase имеют такой малый процент распостранения в России - это нужно их маркетологов спрашивать, вернее уж спрашивать маркетологов IBM, с Sybase я и так достаточно знаю почему. Я даже больше скажу - если бы ASA загнулась и прекратила свое постоянно ежемесячное развитие и рост популярности за бугром, я стопроцентно бы перешел на DB2, но уж никак на MSSQL или Oracle. Хотя слава богу, ASA и не подумает загибаться и по последнему исследованию Garter имеет очень и очень неплохие перспективы, в отличие от того же Sybase ASE. Ух ты, Вы можете выбирать? я Вам искренне завидую. Полагаю у нас обычно выбор небольшой. Мы юзаем то, что лучше продается, на крайний случай выбираем оптимум цена/производителность. Опять же, распространенность продукта предполагает и распространенность лиц, которые его умеют поддерживать и администрить. Найдите у нас админов DB2 или Вы предполагаете сами администрить и поддерживать работу SQL сервера у всех своих клиентов? А чем вызвана такая не любовь к MSSQL и Oracle? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2006, 20:59 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
OTigerпопсовые решения MSSQL/Oracle не то, чтобы фанат, однако, аргумнентация немного настораживает... :( ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2006, 00:46 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
aefrsafdadsf OTigerпопсовые решения MSSQL/Oracle не то, чтобы фанат, однако, аргумнентация немного настораживает... :( Вообще то это я писал. Как известно слово попса - от слова популярный. MSSQL и Oracle наиболее популярные РСУБД в России. Что именно здесь настораживает - мое личное мнение, что популярность в России совершенно не означает, что эти сервера предлагают наилучшее соотношения цены/качества/скорости/стоимости сопровождения ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2006, 01:06 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
ASCRUS aefrsafdadsf OTigerпопсовые решения MSSQL/Oracle не то, чтобы фанат, однако, аргумнентация немного настораживает... :( Вообще то это я писал. Как известно слово попса - от слова популярный. MSSQL и Oracle наиболее популярные РСУБД в России. Что именно здесь настораживает - мое личное мнение, что популярность в России совершенно не означает, что эти сервера предлагают наилучшее соотношения цены/качества/скорости/стоимости сопровождения ? :) Я абсолютно согласен, что не все что популярно - хорошо. Но говорить, что все хорошо, что НЕ популярно-мягко говоря не правильно. Я правильно понял Вашу мысль? Или есть какие нибудь конкретные претензии к MSSQL или Oracle, по мимо их популярности?:) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2006, 01:20 |
|
выбор систем для разработки ПО для автоматиз. економич. процессов предприятия
|
|||
---|---|---|---|
#18+
Было бы странным в этом форуме перечислять все претензии к этим серверам :) Скажем так, если бы претензий не было, то и поводов менять сервер 3 года назад не было бы. Однако претензии обычно тоже не на пустом месте возникают, а на реальном круге задач. Опять же еще зависит от того, кто и как решает задачи - к примеру если вся логика вынесена с сервера, используются сторонние и самописные решения, то в принципе без разницы, какой там сервер то используется. Если нужно легко, без кода, штатно, чтобы вся логика лежала в БД - то оказывается не все сервера на эту роль подходят, то здесь, то там выплывают ограничения, разное поведение при разных условиях применения, а то и просто несоотвествия заявленным возможностям. У меня полностью вся логика в базе, поэтому я предпочитаю ASA и поэтому у меня клиенты спокойно в онлайн через интернет могут работать. Некоторое из того, что я реализовываю средствами языка ASA, физически невозможно реализовать на MSSQL/Oracle в силу их существующих ограничений и отсутствия н-ной фукциональности, если не прибегать к частичному выносу логики с БД или ее переносу на расширенные ХП C/Java/C# - меня это совершенно не устраивает. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2006, 02:16 |
|
|
start [/forum/search_topic.php?author=sna19&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
156ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 439ms |
total: | 719ms |
0 / 0 |