21.01.2008, 14:24 | #21 |
Участник
|
|
|
22.01.2008, 13:21 | #22 |
Ищу людей. Дорого.
|
Я понял что только для чтения.. я немного другое имел в виду
допустим что на публикаторе для всех таблиц диапазон от 1 до 999 999 а для виртуальных таблиц от 1000 000 до 1 999 999 вирт таблицы отреплицировались на подписчик. на подписчике для обычных таблиц не может создаться RecID с номером например 1 000 010.?? получится что в базе будет 2 записи с одинаковыми RecID?. |
|
03.02.2008, 19:40 | #23 |
Участник
|
Кто нибудь из ораторов знает как работает репликация в 1С? Или религия не позволяет? О какой репликации в аксапте можно говорить, если в качестве идентификатора записи используется значение Int? Выделение диапазона номеров в каждой информационной базе видимо подчерпнуто из книги Р. Вьейра. Он почему то про строковые идентификаторы и выделение в нем отдельных символов для кода базы вообще ничего не пишет. Никто не даст гарантии того, что когда нибудь один номер перекроет другой. Без сериализации все равно не обойтись, но тут возникает проблема с целостностью данных которая в аксапте даже на время не может быть нарушена. Про миграцию изменений таблиц и тем более приложения вообще стоит промолчать.
Вот и получается что чтобы там кто ни говорил нормальной репликации в аксапте нет, а есть что-то похожее на перенос отдельных записей отдельных таблиц с кучей условностей |
|
|
За это сообщение автора поблагодарили: mazzy (-2). |
04.02.2008, 09:37 | #24 |
Участник
|
Конечно знает. Многие работали и продолжают работать с 1С.
Обратите внимание, что сама 1С никогда не называет свой механизм репликацией. Потому что и у них не репликация. http://ru.wikipedia.org/wiki/%D0%A0%...D0%BA%D0%B0%29 (начиная с места "Основное различие между репликацией и управлением копированием заключается в следующем") Цитата:
потому что простой "обмен данными" (или "управлением копированием") не обеспечивает целостности данных - нужна двухфазная фиксация транзакций. А ее изначально не было и не будет (в 1С тоже ) http://www.unix.org.ua/sos/glava_13.htm (ключевое слово "двухфазн") http://www.dialektika.com/PDF/978-5-...138-4/part.pdf (ключевое слово "двухфазн") Насчет int-ов. Думайте и читайте дальше. int'ы затрудняют репликацию и вводят дополнительные ограничения, но не вводят принципиальный запрет. См. начало ветки. Автор ветки sergeypp как раз предлагал обсудить эту тему и обсудить варианты собственной доработки, которая решила бы эти пролбемы. Цитата:
Цитата:
Цитата:
Просто некоторые системы (например, 1С) плюют на целостность с высокой колокольни кроме того, вы неправы. Нарушить целостность данных в Аксапте можно. Только сделать это гораздо сложнее, чем в некоторых других системах Цитата:
Да, разработчики Аксапты предполагают, что дешевле организовать постоянный канал, нежели администрировать конфликты репликации или усложнять приложение, вводя фвухфазную фиксацию. Исходя из этого предположения построено все приложение (по 1Совски - конфигурация). Если вы не заметили, svcoder, то в этой ветке идет обсуждение что можно сделать дополнительно к стандартной функциональности, чтобы таки добавить репликацию. Какие плюсы и какие минусы будут у своей доработки. Молчите. А остальные продолжат обсуждение. |
|
04.02.2008, 10:35 | #25 |
Участник
|
Теперь по теме
Цитата:
В данной схеме содержит следующие недостатки: 1. специальная база будет постоянно расти, поскольку не предусмотрет механизм удаления данных 2. удалять из специальсной базы можно уже обработанные данные. Для этого надо знать какие данные полностью обработаны, чтобы их можно было удалять. А механизм обнаружения таких данных не предусмотрен. если кроме справочников переносятся операции/документы 3. при переносе данных в аксапту-подписчик возможны как невозможность завершить транзакцию (неуникальный индекс, попытка списать в минус при запрещенном отрицательном складе), так и нарушения целостности при завершенной транзакции. Механизма подтверждения о приеме/неприеме или о нарушении целостности приемника в предложенной схеме не предуcмотрено. 4. Если в приемнике транзакция не завершена, то центральная база должна что-то сделать. Например, откатить какие-нибудь свои транзакции, сменить статус у чего-нибудь или создать сторно/реверс. Не предусмотрена двухфазная фиксация транзакций В общем, стоит подумать. И может быть таки разработчики прав и организация постоянного канала обойдется дешевле? |
|
04.02.2008, 12:25 | #26 |
Участник
|
Цитата:
Сообщение от mazzy
Конечно знает. Многие работали и продолжают работать с 1С.
Обратите внимание, что сама 1С никогда не называет свой механизм репликацией. Потому что и у них не репликация. http://ru.wikipedia.org/wiki/%D0%A0%...D0%BA%D0%B0%29 (начиная с места "Основное различие между репликацией и управлением копированием заключается в следующем") State machine replication. This model assumes that replicated process is a deterministic finite state machine and that atomic broadcast of every event is possible Цитата:
Сообщение от mazzy
штатного механизма репликации в Аксапте нет, не было и не предполагается.
потому что простой "обмен данными" (или "управлением копированием") не обеспечивает целостности данных - нужна двухфазная фиксация транзакций. А ее изначально не было и не будет (в 1С тоже ) http://www.unix.org.ua/sos/glava_13.htm (ключевое слово "двухфазн") http://www.dialektika.com/PDF/978-5-...138-4/part.pdf (ключевое слово "двухфазн") Цитата:
Еще как принципиально, к строке справа можно добавить символы разделителя базы при появлении оного, а к числу нельзя Цитата:
Цитата:
Цитата:
Сообщение от mazzy
Да, в стандартной Аксапте репликации не было, нет и не предполагается.
Да, разработчики Аксапты предполагают, что дешевле организовать постоянный канал, нежели администрировать конфликты репликации или усложнять приложение, вводя фвухфазную фиксацию. Исходя из этого предположения построено все приложение (по 1Совски - конфигурация). Цитата:
Намек понял. Удаляюсь |
|
04.02.2008, 12:27 | #27 |
Member
|
Цитата:
Сообщение от mazzy
...
штатного механизма репликации в Аксапте нет, не было и не предполагается. ... До кучи можно добавить только, что в Аксапте заложен транспорт для организации обмена (в виде копирования или репликации). В 3.0 был Commerce gateway, в 4.0 его сменил AIF. Эта фигня реализует транспортный уровень. Саму репликацию предполагается разрабатывать на уровне отраслевых решений или на конкретном проекте внедрения. Насколько я представляю, эти модули редко кто использует.
__________________
С уважением, glibs® |
|
04.02.2008, 16:01 | #28 |
Участник
|
Цитата:
Сообщение от svcoder
Не вы случаем переводили? Потому что в английской версии статьи вообще ничего нет об управляемом копировании. Наоборот:
State machine replication. This model assumes that replicated process is a deterministic finite state machine and that atomic broadcast of every event is possible Цитата:
Цитата:
Цитата:
Но эти проблемы снова не относятся к Аксапте. Цитата:
Цитата:
Сообщение от svcoder
Найти применение двухфазной фиксации внутри одного приложения нужно очень постараться, все таки это нужно для разнородных систем. А в Японии вообще от проводов отказываются в пользу беспроводных технологий. Но мы ведь не там живем, а стране где связь между пунктами А и Б может существовать только по одному пути, и если он обрывается можно прекращать деятельность и идти домой.
|
|
04.02.2008, 16:07 | #29 |
Участник
|
Пока бедноват функционал и подтверждений о доставке нет, насколько я знаю.
Commerce Gateway не предполагался для самостоятельного использования (хотя такая возможность в пределах одной базы и была). Commerce Gateway это скорее шлюз в BizTalk Server. А уже BizTalk Server должен был выполнять преобразования и гарантировать доставку. Но идея не прокатила. |
|
04.02.2008, 16:47 | #30 |
Moderator
|
А скажите пожалуйста, кому-нибудь доводилось видеть работающую out-of-the-box в какой-нибудь более или менее сложной КИС-системе репликацию ? То есть - вообще речь идет не об Аксапте и MS SQL, а вообще о связке КИС+Любая БД. Просто я несколько раз видел написанные во второй половине 90ых самописки (причем достаточно сложные), которые репликацию использовали, но достаточно своебразным путем. Причем их авторы описывали примерно следующую историю:
1. Мы написали первую версию системы со стандартной репликацией 2. При попытке запуска, нам пришлось написать мегаалгоритм борьбы с конфликтами обновления. Но мы как-то запустились. 3. По итогам работы в течении первого года, выяснилось что в большей части случаев, конфлиткы обновления возникают не из за технических проблем, а являются отражением конфликта за ресурсы и вообще являются частью бизнес-процессов. 4. Поэтому в версии 2.0, которую мы написали в течении 2ого года жизни системы, мы создали буферные таблицы для обмена данными и только их реплицируем. А на каждом сайте у нас крутятся специальные процессы, которые бегают по этим буферным таблицам и исходя из данных в них, обновляют основные. Ну и еще некоторые простенкькие справочники тупо реплицируются. То есть - во всех виденных мною системах с репликацией, эта репликация используется просто как некоторый транспорт для обмена сообщениями между отдельно написанными процедурами обновления транзакционных данных. Но я вот для себя так и не решил - это мне просто так не повезло увидеть работающую out-of-the-box репликацию, или это просто принципиально невозможно... |
|
23.06.2008, 18:06 | #31 |
Участник
|
Цитата:
Сообщение от fed
А скажите пожалуйста, кому-нибудь доводилось видеть работающую out-of-the-box в какой-нибудь более или менее сложной КИС-системе репликацию ? То есть - вообще речь идет не об Аксапте и MS SQL, а вообще о связке КИС+Любая БД. ....
Но я вот для себя так и не решил - это мне просто так не повезло увидеть работающую out-of-the-box репликацию, или это просто принципиально невозможно... По разговорам вроде неплохо. |
|