Sexton
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arvur Цитата: Неправда ваша, батенька Сделать можно все - вопрос в затраченных усилиях. Задача упрощается тем, что тут аплоад в одну сторону и центр один. | Ну тогда это задача по реализации "тонких" клиентов. А почему действительно не организовать промежуточное звено стандартными средствами? MIDAS (TClientDataSet) или RemObjects им в руки. А репликация на неподготовленных для этого базах... Согласен по поводу усилий. Скажем так, усилия на реализацию репликации могут оказаться бОльшими, чем на перепроектирование. Я как-то автоматически думаю при проектировании таблиц, как их будет удобнее релицировать, если понадобится, и по каким правилам. Скажем документы надо реплицировать, но по каким правилам определять, какая версия записи "свежее" - рассматривается индивидуально. А всякие регистры (вычисляемые на основе документов данные) будут пересчитываться автоматически при репликации документов - отдельно их реплицировать не надо. А чтобы выйти за пределы Int32 на учетной системе (если это не автоматический биллинг и иже с ними), надо постараться. Вряд ли 20-50 пользователям это под силу. Хотя, исключения, конечно, могут быть (или неправильное проектирование, когда при вводе пользователем одной записи в базе плодятся тысячи). Цитата: P.S. Насчет производительности - есть подозрение, что поиск по одному Int64-полю будет быстрее, чем по двум Int32 вне зависимости от логики проца. Но тестов Int64 я не видел. | А, ну это понятно. ID записи-то всегда будет Int32, причем уникальность гарантируется только в пределах конкретной базы (при перемещении из одной базы в другу, ID записи в новой базе будет присвоено другое). Второе поле (в моем случае идентификатор пользователя) используется при репликации, ну и в ограничениях прав: чтобы, например, нельзя было редактировать записи, поступившие из другой базы. Правда, для репликации существует еще и третье поле - ID записи в базе-владельце записи (база-владелец определяется по ID пользователя). |