Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Cane Cat Fisher
По поводу формата хранения, и разруливания блокировок, эту систему можно назвать "версионник, возведенный в абсолют", со всеми достоинствами и недостатками.

Версионник - да, похоже. А можно поподробнее о недостатках?

Cane Cat Fisher
Но практика показала, что чаще всего требования эти растут. И проблемой является именно задача расширения систем "в разы". Поэтому и придумали SQL-сервера - они масштабируются легче, позволяют накрыть более широкий диапазон задач - от быстрого (ну, в разумных пределах :) сбора телеметрии, до огромных неторопливых хранилищ аналитики.

Частично с вами соглашусь, но сегодня все-таки начинает наблюдаться и обратная тенденция: начали выплывать альтернативные стандартным реляционным базам решения. Я об этом уже говорила выше.

Cane Cat Fisher
Конечно, если бы под каждый род задач разрабатывалась особая, "заточенная" СУБД, возможно, она в каких-то моментах оказалась бы выигрышнее, чему универсальные. Но это очень дорогой и ненадежный путь.

Согласна в контексте "под каждую отдельную задачу". Но вот если попытаться выделить классы задач?

Cane Cat Fisher
Поэтому, я бы предположил, что в таком неторопливом режиме, на 30 бухгалтеров, можно было бы сделать систему практически на любой платформе. Аналогичные задачи - вариантную структуру записей, и т.д. - решить другими, но вполне работоспособными способами. А если те же усилия, что пошли на разработку своей системы, пустить на оптимизацию системы на SQL - результат был бы ничуть не хуже, а, уверен, лучше, и главное - перспективнее.
Вообще, я бы посоветовал, сейчас не прикручивать к этому делу SQL, а срочно перевести этот фреймворк (за который авторам честь и хвала), на работу с нормальным SQL - сервером.


Вот этот момент я как раз обсуждала с разработчиками именно прикладной части. То есть я реально задавала вопрос: может дело в том, как написана прикладная задача и в том, что у истоков создания системы стоял очень грамотный бухгалтер с математическим образованием? Но они почему-то уверены, что дело не только в этом. Что важны и прикладная и системная части и без такой системной многие особенности прикладной у них бы не получились.

У них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Насчет переноса на стандартный SQL-сервер. У них связь реализована. Т.е. есть API для цепляния и к обычному серверу. Но для реализации прикладных задач они этим не пользуются - говорят неудобно. Используют связку только если интеграция нужна.
29 авг 11, 13:28    [11194716]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Edd.Dragon,
Спасибо конечно, но я не разработчик :) Просто разработчики - мои очень близкие знакомые и я несколько лет так или иначе слушала про их систему всякие байки. Сейчас есть шанс все это раскрутить более серьезно. Вот я и оцениваю перспективы.
29 авг 11, 13:45    [11194850]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
У них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.


Как то так?
29 авг 11, 13:46    [11194863]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Vladimir Baskakov,
Так летает уже. Только в предыдущей версии, которая по некоторым характеристикам морально устарела, но база там именно такая как описана. А в предыдущей версии полный учет предприятия - как в 1C. В новой пока только зарплата.
29 авг 11, 13:47    [11194868]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Edd.Dragon,
Спасибо конечно, но я не разработчик :) Просто разработчики - мои очень близкие знакомые и я несколько лет так или иначе слушала про их систему всякие байки. Сейчас есть шанс все это раскрутить более серьезно. Вот я и оцениваю перспективы.


То есть 200 внедрений это НЕ серьезно?
29 авг 11, 13:47    [11194876]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
интересующаяся_мнением, если Вы собираетесь приобретать такую систему или что-то разрабатывать на ее основе - даже не думайте
причины на поверхности и даже не вижу смысла обсуждать

но сдается мне что это завуалированная реклама и интересуетесь Вы не этой БД, а тем как ее можно продвинуть
тогда Вы выбрали не ту площадку, тут Вы мало чего добьетесь
29 авг 11, 13:48    [11194892]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Vladimir Baskakov,
Нет, там не стартап. Контора работает с 90х годов и обслуживается силами ээ... 2.5 программистов (в разные годы по-разному, но среднее число примерно такое). При этом они всех своих клиентов успевают поддерживать и вовремся выпускать все изменения в законодательстве, которые за эти годы имели место быть. Говорят что все это благодаря только гибкости фреймворка.
29 авг 11, 13:50    [11194905]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Gluk (Kazan)
интересующаяся_мнением
У них, к примеру, есть такой режим песочницы. Он используется и бухгалтерами и при отладке комплекса. Если перевести станцию в локальный режим работы, то вам в теории ничего не мешает начать кромсать данные в базе как вам заблогарассудится - типа - эксперименты проводить. Вы можете этим часами заниматься. А потом просто сказать что-то типа undo и система у вас вернется в начальное состояние. В теории - так же просто делать и пошаговый undo и на заданный момент времени. Как вот эту, например фичу реализовать в стандартном реляционнике, вот без такого потокового метода записи - я не представляю, - накладные расходы слишком большими будут.

Как то так?

Да, по эффекту примерно похоже. Нууу... Oracle наверно может все, но это очень дорого, и по стоимости и по обслуживанию. Согласитесь.. небольшая конторка вообще без админов его себе позволить не может.
29 авг 11, 13:56    [11194947]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Gluk (Kazan)
То есть 200 внедрений это НЕ серьезно?

Смотря с чем сравнивать :) Если с 1С например, то эта капля даже не в море, в океане.
29 авг 11, 13:58    [11194961]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
SergSuper
интересующаяся_мнением, если Вы собираетесь приобретать такую систему или что-то разрабатывать на ее основе - даже не думайте
причины на поверхности и даже не вижу смысла обсуждать

Не покупать и не приобретать, а скорее, - поучаствовать. Вот пытаюсь понять перспективность. У меня тоже есть некоторое представление о теории и практике строения реляционных СУБД. И я понимаю, что это чудо ни на что не похоже. Но живет же. И даже вполне себе прилично. Вот мне и стало интересно. Я пытаюсь немного абстрагироваться от своих знаний и действительно посмотреть на систему непредвзято. Сравнивать только возможности, причем в контексте применения к конкретным задачам. Меня одной на такой анализ не хватит. Хочется коллективного мнения.

Взять к примеру, переменное число полей в таблицах. Де-факто получается, что у них просто очень широкие таблицы, в которые напихано сразу все. В теории, - ну что мешает сделать это в реляционной СУБД? Тем более что ALTER TABLE, насколько я понимаю, операция простая и в современных СУБД ресурсов не требует особо, а значения с NULL память не забивают.. Так почему не делают? Некошерно? Некрасиво? Почему?

С вычислениями агрегатов на лету, - опять то же самое. Я понимаю, что в теории ничто не мешает в современной БД повесить всю эту обработку на триггера. Но почему-то тоже особо не делают. Почему?

А жаль что не видите смысла обсуждать причины, но воля ваша.
29 авг 11, 14:10    [11195027]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

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

Такое возможно в двух случаях:
1) Транзакции полностью сериализованы и идут исключительно последовательно;
2) Хранится индивидуальный список принятых транзакций.

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

Какой случай реализован в Вашей системе?

Posted via ActualForum NNTP Server 1.4

29 авг 11, 14:12    [11195046]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
интересующаяся_мнением
Vladimir Baskakov,
Так летает уже. Только в предыдущей версии, которая по некоторым характеристикам морально устарела, но база там именно такая как описана. А в предыдущей версии полный учет предприятия - как в 1C. В новой пока только зарплата.

А, тогда хороших полетов! То есть кадры, зарплата, склад, управленка? Налоги всякие... а отпуска, больничные... перекрывающиеся... бюджетирование...

(тихо, почти шепотом) толстый клиент, да? чур меня, чур меня...

А на чем оно написано? Апи какое? Например, я хочу прикрутить к этому мегачуду эксель. Люблю экселевские сводные таблички например... так получилось. Или люблю фаст-репорт. Или кристалл - репорт. Или еще какую нить всеядную фигню...

Мой вердикт такой - или - это мегагениальный суперпродукт будущего.... или.... Ну - я романтик - буду верить в хорошее!
29 авг 11, 14:13    [11195053]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
интересующаяся_мнением
По номеру транзакции. Если станция получила обновление с пропуском, она запрашивает у
сервера недостающее и тогда он уже ей персонально пересылает.

Такое возможно в двух случаях:
1) Транзакции полностью сериализованы и идут исключительно последовательно;
2) Хранится индивидуальный список принятых транзакций.

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

Какой случай реализован в Вашей системе?

Я могу уточнить это у разработчика, - но по-моему первый. Информация от клиента уходит на сервер, сервер ей присваивает очередной по порядку номер и бродкастит это клиентам. Клиенты получают, записывают к себе в базу. Если клиент видит, что у него пропуск в номере - запрашивает у сервера недостающее.
29 авг 11, 14:18    [11195078]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Vladimir Baskakov
А, тогда хороших полетов! То есть кадры, зарплата, склад, управленка? Налоги всякие... а отпуска, больничные... перекрывающиеся... бюджетирование...

В предыдущей версии - да.

Vladimir Baskakov
(тихо, почти шепотом) толстый клиент, да? чур меня, чур меня...

Да, собственно на базе фреймворка и сделан. Клиентские БД, которые в описании базы описаны встроены в фреймворк, т.е. они как встроенная база работают.

Vladimir Baskakov
А на чем оно написано? Апи какое?

База и фреймворк написаны на C++, причем чистом, без использования библиотек. Разработчики собирали их детище под разными платформами, не Win - работает. Думаю, полное тестирование все-таки выявит особенности, но опять-таки, думаю, что допилить в случае чего будет несложно.
Сама прикладная часть написана на встроенном языке фреймворка, на нем и API, если дописать что-то хотите. Встроенный язык с полной поддержкой ООП и плюс чего-то там еще умеет. Но в этом мне еще отдельно разбираться надо.

Vladimir Baskakov
Например, я хочу прикрутить к этому мегачуду эксель. Люблю экселевские сводные таблички например... так получилось. Или люблю фаст-репорт. Или кристалл - репорт. Или еще какую нить всеядную фигню...

Excel, понятное дело, прикручен в плане экспорта в него. Более детально - надо спрашивать у разработчиков. Насчет остальных продуктов - неуверена. Они для создания отчетов внутренними средствами фреймворка пользуются. Доработки такого рода делают если заказчик пожелает.

Vladimir Baskakov
Мой вердикт такой - или - это мегагениальный суперпродукт будущего.... или.... Ну - я романтик - буду верить в хорошее!

Вот и я пытаюсь понять кто я.. или романтик или :) Поэтому и хочу коллективного мнения и критики подхода. :)
Только аргументированной.
29 авг 11, 14:27    [11195139]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

интересующаяся_мнением
Я могу уточнить это у разработчика, - но по-моему первый. Информация от клиента уходит на
сервер, сервер ей присваивает очередной по порядку номер и бродкастит это клиентам.

Т.е. пока с сервером работает один клиент, остальные сидят и курят в очереди.

Ещё вопрос:
она продолжает работать с состоянием, актуальным на момент завершения седьмой
транзакции и продолжает формировать данные для следующей. Если она в этот момент завершит
свою работу и изменившиеся данные пойдут на сервер, он не сможет записать ее данные и
сообщит на станцию об ошибке (вспомним, что они редактировали один и тот же документ).

Как сервер определит, что они редактировали один и тот же документ?

Сценарий:
1. Операционистки 1 и 2 начинают редактировать Документ 1;
2. Операционистка 3 начинает редактировать Документ 2;
3. Операционистка 1 сохраняет Документ 1;
4. Операционистка 3 сохраняет Документ 2;
5. Операционистка 2 сохраняет Документ1.

Что делает сервер чтобы сообщить Операционистке 2 об ошибке?

Posted via ActualForum NNTP Server 1.4

29 авг 11, 14:28    [11195149]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
интересующаяся_мнением

А жаль что не видите смысла обсуждать причины, но воля ваша.


интересующаяся_мнением
Контора работает с 90х годов и обслуживается силами ээ... 2.5 программистов


это разве не достаточная причина?
29 авг 11, 14:39    [11195207]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
--------------------------------
Guest
Не понял - что вы такого удивительного обнаружили в их транзакциях.
Вполне нормальный механизм. Обычно это называется "оптимистическая блокировка".
А транзакции перепутаться не могут просто потому, что номер транзакции присваивается при фиксации.

Непонятно другое - как быстро получить текущее состояние по, по сути, транзакционному логу и как обеспечиваются скорости поиска в такой базе.
29 авг 11, 14:46    [11195266]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Yo.!
Guest
Dimitry Sibiryakov
Как сервер определит, что они редактировали один и тот же документ?

Сценарий:
1. Операционистки 1 и 2 начинают редактировать Документ 1;
2. Операционистка 3 начинает редактировать Документ 2;
3. Операционистка 1 сохраняет Документ 1;
4. Операционистка 3 сохраняет Документ 2;
5. Операционистка 2 сохраняет Документ1.

Что делает сервер чтобы сообщить Операционистке 2 об ошибке?

ну тут то понятно, по SCN, как и любой другой версионник. просто совсем без блокировок на некоторых задачах процент неудачных транзакций зашкалит за все разумное.
интересующаяся_мнением
Я могу уточнить это у разработчика, - но по-моему первый. Информация от клиента уходит на сервер, сервер ей присваивает очередной по порядку номер и бродкастит это клиентам. Клиенты получают, записывают к себе в базу. Если клиент видит, что у него пропуск в номере - запрашивает у сервера недостающее.

ну даты все совсем не годиться архитектура. клиент отсылая транзакцию может не подозревать, что прозевал какие-то транзакции.
29 авг 11, 14:49    [11195286]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
Т.е. пока с сервером работает один клиент, остальные сидят и курят в очереди.

Почему? Каждый клиент ведь работает со своими локальными данными. Чтение - это вообще не проблема. Обновление записи, - что в такой схеме помешает нескольким клиентам одновременно обновлять данные? Они обновили, - отправили на сервер. А там уже транзакции номер присвоился. Так на практике и происходит.

Dimitry Sibiryakov
Ещё вопрос:
она продолжает работать с состоянием, актуальным на момент завершения седьмой
транзакции и продолжает формировать данные для следующей. Если она в этот момент завершит
свою работу и изменившиеся данные пойдут на сервер, он не сможет записать ее данные и
сообщит на станцию об ошибке (вспомним, что они редактировали один и тот же документ).

Как сервер определит, что они редактировали один и тот же документ?

Сценарий:
1. Операционистки 1 и 2 начинают редактировать Документ 1;
2. Операционистка 3 начинает редактировать Документ 2;
3. Операционистка 1 сохраняет Документ 1;
4. Операционистка 3 сохраняет Документ 2;
5. Операционистка 2 сохраняет Документ1.
Что делает сервер чтобы сообщить Операционистке 2 об ошибке?

Сервер всегда знает станцию, от которорой пришел запрос на обновление данных.
Допустим в вашем сценарии на начальный момент времени у нас 7 транзакций. Данные от операционистки 2 сервер сохранит в качестве транзакции под номером 8, а от операционистки 3 - 9. Когда придет запрос от операционистки 2, там будет указано, что она хочет сохранить документ 1 и ее последняя транзакция - 7. Сервер увидит, что после этой транзакции уже происходило редактирование этого документа (сохранено в транзакции 8) и он вернет клиенту сообщение об ошибке - что-то вроде "конфликт обновление записи, обновите документ и отредактируйте его снова". Вообще- это задача прикладного программиста отработать эту ошибку. Реакция с точки зрения пользователя может быть и другой, например - перезаписать автоматом, или сравнить запись по полям, обновив автоматом те поля где нет конфликта и дать пользователю решать, как именно разрулить конфликт с конкретным полем, ну и т.п.
29 авг 11, 14:51    [11195298]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Vladimir Baskakov,
Нет, там не стартап. Контора работает с 90х годов и обслуживается силами ээ... 2.5 программистов (в разные годы по-разному, но среднее число примерно такое). При этом они всех своих клиентов успевают поддерживать и вовремся выпускать все изменения в законодательстве, которые за эти годы имели место быть. Говорят что все это благодаря только гибкости фреймворка.


200 внедрений / 2.5 разработчика + BOSS = Вах !!!

Наркобароны плачут кровавыми слезами
29 авг 11, 14:51    [11195302]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

Yo.!
ну тут то понятно, по SCN, как и любой другой версионник.

Да нет, совсем непонятно: как сервер определит, что в промежутке между взятием Документа 1
на редактирование и его "коммитом" изменялся именно он. Будет читать все транзакции от
"стартовой" до конца?

То бишь в примере из статьи при записи транзакции 10 надо определить, что транзакция 8
изменила именно Документ 1, а не Документ 3, например.

Posted via ActualForum NNTP Server 1.4

29 авг 11, 14:54    [11195328]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
Вот пытаюсь понять перспективность. У меня тоже есть некоторое представление о теории и практике строения реляционных СУБД. И я понимаю, что это чудо ни на что не похоже.
Бесперспективно. Но настоящего романтика это пугать не должно. Это духовный выбор... (я имею в виду изобретение велосипедов) не надо опошлять его деньгами... и размышлениями о всяких транзакциях - блокировках тоже.

Особенности БД не играют ключевой роли в проектировании ЕРП системы. Объекты сериализуются, восстанавливаются? Хвала всеблагой эволюции... откуда, куда? Так ли это важно...
29 авг 11, 14:55    [11195339]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

интересующаяся_мнением
Обновление записи, - что в такой схеме помешает нескольким клиентам одновременно обновлять
данные? Они обновили, - отправили на сервер. А там уже транзакции номер присвоился. Так на
практике и происходит.

Возьмём тысячу клиентов, желающих одновременно отправить свои изменения на сервер. Пусть
одна отправка занимает одну секунду. Тысячный клиент будет ждать 999 секунд пока сервер
обработает пакеты остальных. Разве нет?

интересующаяся_мнением
Сервер увидит, что после этой транзакции уже происходило редактирование этого документа
(сохранено в транзакции 8)

Как "увидит"? Перечитав из файла каждую транзакцию после седьмой? А если их успело пройти
сто тысяч?..

Posted via ActualForum NNTP Server 1.4

29 авг 11, 15:04    [11195401]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
--------------------------------
Не понял - что вы такого удивительного обнаружили в их транзакциях.
Вполне нормальный механизм. Обычно это называется "оптимистическая блокировка".
А транзакции перепутаться не могут просто потому, что номер транзакции присваивается при фиксации.

Непонятно другое - как быстро получить текущее состояние по, по сути, транзакционному логу и как обеспечиваются скорости поиска в такой базе.

За наименование - спасибо, буду знать :)
По поиску - конечно они используют индексы и индексируют все что не лень. И все равно, если сравнивать один к одному, то скорость чтения здесь конечно получается меньше, причем сильно. Но на практике это как раз и нивелируется тем, что на чтение каждый пользователь работает со своими локальными данными, в единопользовательском, так сказать, режиме, и плюс еще то, что база у него де-факто - встроенная, живущая в его же процессе, то есть вы не теряете время на передаче именно данных.

Конечно, вся эта петрушка будет хорошо жить на небольших базах. Если мы начнем перерастать какие-то пределы (какие - хочу провести эксперименты со временем), то наверно этот недостаток должен начать давать о себе знать. По факту, я так понимаю они сталкивались с числом записей примерно до поллумиллиона в одной таблице, пока задержек не проявлялось.
29 авг 11, 15:06    [11195419]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
Dimitry Sibiryakov
То бишь в примере из статьи при записи транзакции 10 надо определить, что транзакция 8
изменила именно Документ 1, а не Документ 3, например.

Ну а как вы в обычной базе определяете, что это уже существующая запись? По ключу. А поиск - индексы.
29 авг 11, 15:10    [11195444]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить