2 интересующаяся_мнением
интересующаяся_мнением.ЛПЭтот вопрос очень, очень интересен.
Особенно в свете декларируемого "в случае потери сервера, сервером можно объявить любую из рабочих станций"

По номеру транзакции. Если станция получила обновление с пропуском, она запрашивает у сервера недостающее и тогда он уже ей персонально пересылает.
Ещё раз. По буквам. Медленно.
Станция пропустила какое-то обновление.
Был поток транзакций от других машин, транзакции номер 1, 2, 3, 4, 5.
Бухгалтер порнуху смотрел, чем загрузил всю свою машину, и проспал бродкаст. До станции дошли транзакции 1, 2, 3, 4.
В этот момент "сервер" умер.
Как станция узнает о том, что она чего то недополучила? У кого она это узнает? У "сервера"? Но ведь "сервер" - умер .

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

Если эту больную станцию сделают сервером - какие номера она будет выдавать для новых транзакций? Следующий номер будет 5? Что произойдёт на всех остальных рабочих станциях, когда к ним второй раз придёт транзакция за номером 5, причём совсем другая, не та, что в первый раз?

интересующаяся_мнением.ЛПВ базе хранится вся история, от ишачьей пасхи до сегодняшнего дня. Вся эта база в полном объёме находится у всех клиентов.
На самом деле, не совсем так. У них там есть механизм - называется компрессирование. Он как раз и предназначен для того, чтобы "схлопнуть" историю.
Т.е. статейные заявления о том, что в любой момент времени можно получить состояние базы на любой момент времени - не соответствуют действительности.
Правильно я понимаю?

интересующаяся_мнениемНе клиент бродкастит, а сервер. Клиент передает данные на сервер уже не бродкастом а конкретно ему. И не на каждый чих. Данные передаются только об изменениях.
Это неважно, рассылает бродкастовый пакет сам клиент, или псевдо-сервер по требованию клиента. Важдно, что по требованию клиента. Как только клиент что-то проапдейтил, так тут же все остальные клиенты вынуждены ловить и обрабатывать бродкаст об этом апдейте.

интересующаяся_мнениемА что вы имеете в виду под "нужно, не нужно, пофигу?"
Именно это и имею в виду.
Рабочая станция создала одну запись. Никому не нужную, кроме неё. Остальные про эту запись и знать не знали бы, и не нужно им оно.
А потом эта одна запись этой самой рабочей станцией начинает непрерывно апдейтиться. С частотой стопиццоттыщщ апдейтов в секунду.
Чем в это время будут заниматься остальные рабочие станции? Ловить из сети бродкасты и обрабатывать их? Стопиццоттыщщ бродкастов в секунду, по поводу апдейта записи, которая нафиг им не нужна?
В статье содержатся какие-то умные слова насчёт горизонтальной маштабируемости, но это, знаете ли, маштабируемость наоборот. Каждый новый (пишущий) клиент понижает общую производительность системы (как читателей, так и писателей).

интересующаяся_мнениемМмм.. да. Скорее всего. Так и не позиционируется это для больших нагрузок на запись.
Тогда зачем использовать способ хранения в виде append-only лога изменений?

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

интересующаяся_мнением.ЛПДаже на де-факто умершем файл-серверном нечте.
А вот с этим я кстати не согласна. Тот же Access используется очень широко.
Какая разница, насколько широко он используется, если этот продукт не развивается? Последние значимые нововведения были в 2000-ом году (поддержка клиент-серверного режима в виде adp-клиента к базе MS SQL Server). После этого аксес умер. С тех пор нововведения от версии к версии - нечто из серии "у трупа какое-то время продолжают расти волосы и ногти".
Впрочем, неважно.

интересующаяся_мнениемИ как раз для случаев когда в офисе нужно быстро сваять что-то учетное очень малыми силами и при почти полном отсутствии знаний/образования/ресурсов...
.... Вот поэтому и "не сделать на нормальной СУБД".
Используйте LightSwitch.
Кривая вхождения как у аксеса. Но по крайней мере СУБД нормальная, а не mdb. И не "Викта".