интересующаяся_мнением,

я прочитал полностью только статью по ссылке на первой странице и саму первую страницу. Остальное не читал, так как по своему опыту примерно догадываюсь, что там написано. Вот Вам моем мнение по поводу особенностей БД "Викта".

1.
Архитектура при которой данные центральной базы тиражируются на клиентские компьютеры действительно позволяет добиваться высокой производительности в ИС класса ERP. Мы сами долгое время занимаемся такими системами, и пришли к такому же варианту решения, реализовали его, и по своей практике оценили на 5+. Вот материалы. . У нас другой принцип обновления, и есть поддержка SQL, но это детали. Главная идея – локальный копии данных - одинакова.

Но! Высокой производительности многопользовательских ИС можно достигать и другими средствами - правильное проектирование и программирование, кластерные SQL-сервера, мощные аппаратные ресурсы. Большинство так и привыкли делать. И на их стороне стоят их успешные проекты, и вникать в "революции" до тех пор пока о них не объявит крупный вендор с мировым именем они не будут.

2.
Хранимые агрегаты, рассчитываемые аккуратно по приращениям, - это тоже из нашей успешной практики. Но этот примём встречается в других практиках настолько часто, что его нужно называть не уникальным, а обыкновенным правильным решением для БД ERP .

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

Random_GoodmanНельзя хранить всю базу у клиентов. Это вопиющее нарушение всех принципов безопасности доступа к данным. На этом точка.

Зачем так категорично? Никто и не говорит, что нужно хранить всю базу на каждом клиенте.

Вот рассуждения об информационной безопасности для такого подхода.

Кратко:
1. Локальные данные содержать только ту часть центральной БД, которая разрешена пользователю данного рабочего места.
2. Локальные данные располагаются на зашифрованном разделе локального диска.

Таким образом:
1.Кража локальных файлов самим пользователем корпоративного приложения бессмысленна. Вся определенная ему информация и так ему доступна, ведь он работает с ней через приложение. А все ‘для него секреты’ не поступают в его локальные хранилища.
2. Кража локальных файлов другим пользователем, имеющим доступ к компьютеру с приложением, но не знающим пароля не возможна из за локального шифрования.

Оспорьте приведенные тезисы, или скажите свои. Точку поставить всегда успеем.

Random_GoodmanавторКража локальных файлов другим пользователем, имеющим доступ к компьютеру с приложением, но не знающим пароля не возможна из за локального шифрования.
шифрование - не проблема, если знаешь ключ, а ключ у всех и так есть, иначе нельзя было бы "проставить флажок".
1.Если нарушитель не является пользователем системы, то ключа у него нет.
2.Если нарушитель это пользователь системы, то красть информацию он будет из самой системы, используя при этом ее экранные и печатные формы, включая экспорт последних в то, что поддерживается эта ИС. Это гораздо проще, чем ковыряться в локальных файлах.

Random_Goodman, да, у автора говориться, что локальная копия - это полная копия БД. Это нужно рассматривать только как недостаток отдельной реализации. Недостаток этот относительно легко устраним (смотри мои ссылки на нашу систему) и он не ставит точку ;) в развитии идеи локальных файлов в целом.

Ключом к решению проблем безопасности является формирование усеченной локальной копии БД.

И еще.

tanglirartemanaЭто гораздо проще, чем ковыряться в локальных файлах.Гораздо проще тупо унести всю БД (и клиента) к себе домой/куда-нибудь ещё, а там уже делать с ней что заблагорассудится (в том числе и печатать отчёты/скриншотить экранные формы/...). Не?

Можно сделать так, что приложение без связи с центральной БД не захочет работать ни у кого дома. Например, одна часть ключа шифрования вводится пользователем, а другая часть берется с сервера. Его конечно можно сковырнуть, но это уже гораздо сложнее чем укарсть информацию из самой системы. Ведь там: интуитивно понятный интерфейс, широкие возможности, гибкость ... ;)

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

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

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

Был бы автор, он бы наверное подтвердил.

tanglirКак вам такая точка зрения?Т.е. смысл как раз в том, чтобы любая станция могла работать сервером, а для этого (очевидно) необходимо, чтобы на каждой станции было всё.[/quot]
Через край. Для надежной защиты от ударов судьбы, нужно иметь резевры ресурсов, в том числе горячие, в гораздом меньше количестве чем количество пользователей. Желательно так же часть резервов иметь не в том месте где сидять пользователи, а то в случае (не дай бог!) разрушения здания заводоуправления ни одну из 30 копий востановить не удасться. Вообщем копий много, толку мало.

maytonМне эта СУБД напоминает пиринговую сеть. Очень хороша для аналитики
и отчётов по историческим данным. Но все что касается OLTP скорее
всего "идёт лесом".
Это работает. И разработчики БД "Викта" и мы занимаемся именно OLTP системами, и давно.
Можно найти задачи, у которых ввод данных сопоставим с чтением данных, для таких задач архитектура локальных данных не подходит. Но в среднестатистической ERP-системе таких задач мизер. Как правло чтений на несколько порядков больше записи.

SergSuperсейчас подумал - если база копируется на клиентские машины, то в принципе она небольшая - десяток-другой гигабайт максимум
соответственно и читать там можно немного
раз движок доморощенный, то вряд ли там есть сложные запросы
отсюда получается, что смысла то в такой СУБД и нет - простые запросы небольших данных занимают небольшую часть нагрузки обычных СУБД
Локальные движки могут быть разными. В том числе, за счет специализации, превосходить серверные по производительности в определенном сегменте задач. Локальные движки могут быть сделаны на основе серверных и значит ни в чем не уступать им с точки зрения синтаксиса и производительности.

Но это детали. Главное. На мой взгляд, Вами спутаны понятия. Понятия сложный SQL запрос, с точки зрения синтаксического состава, и понятия тяжелый запрос, или большой набор мелких запросов, объединенных неким прикладным алгоритмом, - это разные понятия. Отсутствие первого плохо, но оно не означает отсутствие второго. То, что у разработчиков Викты нет под рукой синтаксиса современного стандарта SQL, или даже хоть какого то SQL, не значит, что у них низкие аппетиты к обработки данных. Аппетиты, в главной объеме, определяется прикладной задачей, а не средством.

SergSuperartemana...
Локальные движки могут быть разными. В том числе, за счет специализации, превосходить серверные по производительности в определенном сегменте задач. Локальные движки могут быть сделаны на основе серверных и значит ни в чем не уступать им с точки зрения синтаксиса и производительности.
вроде как заявляется что это некая СУБД, т.е. движок неспециализированный
понять что такое "локальный на основе серверного" не смог
В архитектуре локальных копий это означает, что данные локальной копии находятся под управлением той же СУБД, что и данные центральной БД. Грубо говоря, на клиенте установлен такой же программный сервер, как и на центральном компьютере сервере.

SergSuperartemanaНо это детали. Главное. На мой взгляд, Вами спутаны понятия. Понятия сложный SQL запрос, с точки зрения синтаксического состава, и понятия тяжелый запрос, или большой набор мелких запросов, объединенных неким прикладным алгоритмом, - это разные понятия. Отсутствие первого плохо, но оно не означает отсутствие второго. но означает лишний геморрой для разработчиков


Согласен. Но поймите меня правильно, я, увидев систему с такой же архитектурой как у нас, поддерживаю именно архитектуру. То, что в данной конкретной реализации Викты отсутствует SQL, и на каждом клиенте полная копия данных - это ее недостатки. Я их не оспариваю, а лишь указываю на то, что они легко могут быть устранены и не могут приводиться как аргументы против архитектуры локальных копий в целом.

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

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

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

Нет, это не шаг назад. Это удачный микс клиент-сервера cо старой, доброй и сверх быстрой локальной обработкой данных.
Все пишут данные на единный сервер, а читают у себя.

Опять же, я говорю об архитектуре в целом, учитываю то, что реализация может быть другой (наш сайт я давал).
Терминальные системы являются альтернативным решением для распределенных систем! В единой ЛВС работать на них, это делать плохо пользователям во благо админов. У терминальных систем, для задачи распределенности, есть критический потолок, они не могут обеспечить работу при отсутствии соединения.

SergSuperartemanaТерминальные системы являются альтернативным решением для распределенных систем! нет, не альтернативным
всё именно идет к тому что будет либо вэб-интерфейс, либо терминал
Как и куда все пойдет, сказать не берусь. Но то, что архитектура с локальной копией данных вполне эффективна, и обладает рядом преимуществ, как с точки зрения производительности, так и надежности для меня является доказанным фактом.
SergSuperartemana
В единой ЛВС работать на них, это делать плохо пользователям во благо админов. что плохого то? пользователи подчас и не подозревают что они "сидят в матрице"
Зачастую тормозит. Уравниловка. Мощности локальных машин есть, но не используются.

SergSuperartemana
У терминальных систем, для задачи распределенности, есть критический потолок, они не могут обеспечить работу при отсутствии соединения.а компьютеры не могут работать без электричества, но это же не повод переходить на счеты
Но, это вполне себе повод установить резервный генератор.

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