Доброго всем, в моем представлении это чудеса, но вдруг.

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

исходя из задачи - не обязательно форма, мб что то другое, нужен просто текст

(0) это тебе к Г1С

он такое чудо чудесное давеча рисовал...

ну само собой что бы не перебирать реквизиты и не складывать их в кучку с последующей передачей обратно в вызывающую базу

(2) интересно, сейчас найдем

(2) не поминай к ночи )))

(0) Начал транзакцию, создал нужные ссылки, создал форму с заполненными полями, отменил транзакцию
А вообще порнуха конечно, в пень такое

(0) и в чем состоит чудо повторения типового функционала УХ ?

(6) не совсем так - ссылки уже есть, в одной базе сканируют номер документа из другой базы, данные этого документа показать в базе где сканируют
(7) могу поискать конечно, но в чем там соль, как передача происходит и передача чего, именно формы?

+(2)

Г1С дарит вам

Коллеги, мне поручили сделать вложенную форму, есть опыт?

всё не читал. оно?

(8) Да блин, идея та же
Начинаешь транзакцию
Выгружаешь всю нужную инфу
Загружаешь всю нужную инфу
Создаешь форму объекта
Отменяешь транзакцию

За тебя код написать что ли?

(0) а так умеет еще "бесшовная интригация" 1С:Документооборот посредством веб-сервиса. Доступно и всерьёз

(9) спасибо что нашел. ну нет, у меня проблема не столько с отображением форм сколько с передачей данных между базами
(10) да, идею понял (наверно), но это же все равно надо "перебрать" реквизиты и определить, что выгружать, а что нет, потом в "приемнике" загрузить это. почему я подумал о формах - потому что документов несколько, они не идентичные по набору метаданных, поэтому придется писать "если такой документ, а если другой" (да собственно сейчас так и написано, давно так и работает, переделываю на новую платформу с попутной оптимизацией). А вот если получить по номеру ссылку, там в базе - исходнике(ссылка с данными не сериализуется), а потом получить ее форму и передать сюда обратно что бы просто показать... ТабДок можно передать xmlем, но в него сначала надо будет вывести данные, песня та же

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

(7) такое там сделано или может я не доступно объяснил? что бы я не искал того, чего нет в ухе

(0) бесшовная интеграция с документооборотом однако

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

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

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

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

Вызов пользовательских интерфейсов через OLE

https://infostart.ru/1c/articles/277982/

(20) ок, почитаю

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

(22) если есть нав.ссылка, то ПерейтиПоНавигационнойСсылке()
откроется ИБ и в ней объект

(0) есть же порнуха с 1сными интерфейсами, с встраиванием 1сных форм на страницу сайта. Используй её. Делаешь форму с HTML полем во всю ширь, в поле отображаешь документ из другой БД. Profit

https://infostart.ru/1c/articles/1504895/

https://its.1c.ru/db/v8320doc#bookmark:dev:TI000002191

Но вообще, я бы пересмотрел решение. Надо нормально базы интегрировать, а не заниматься костылевществом в стиле Г1Сов

(22) вторая база будет открыта так или иначе, явно или не явно, если данных нет в этой базе (нет синхронизации).

(14) там такое сделано. именно такое, как ты хочешь. давно бы уже посмотрел, вместо писанины.

(29) о сделано через COM ( фу *ля)))

(27) спасибо за ссылки, насчет пересмотреть решение - да, дилемма, останавливает только одно из основных правил баз данных "избыточность данных за счет дублирования", базы близко друг к другу, на одном сервере крутятся
(30) а где в ух такое, в каком документе/обработке? может на сервис переделать можно

(31) >>избыточность данных за счет дублирования

А в чем проблема-то? Мегабайты на дисках экономите? Можешь забыть все эти умности про "нормальные формы базы данных", борьбу с дублированием и вот это всё. Оно пережиток давно минувшего прошлого. Трепетно боролись с дублированием данных в БД в те времена, когда мегабайт места на диске стоил как покупка нового легкового автомобиля. Сейчас в промышленной разработке сплошь и рядом денормализация данных. Ибо гигабайты добавить как за мороженкой сходить, а "дублирование" данных предоставляет массу удобств

Кеширование - целенаправленное дублирование данных.

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

(34) и для чего же по-твоему придумали нормализацию данных?

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


https://docs.microsoft.com/ru-ru/office/troubleshoot/access/database-normalization-description

(36) все верно, с 1 по 6 нормальных форм, но есть одно но, нормализованная база становится сверх сложно1 в дорпботке и эксплуатации, так как сложность растет по экспоненте

(36)Пример наличия избыточных данных в 1С - ежемесячные итоги для РН. Очистите итоги если вам претит использовать ненормализованную БД и собирайте негатив от пользователей.

(35) Для того чтобы избежать несогласованных обновлений

(37) Нормализованная по 3нф база - это база, где в каждой таблице есть уникальный ID и все справочные данные хранятся отдельно в справочниках. Я бы сказал, сложно при разработке придумать ненормализованную бд, если разработчик не идиот, конечно. Формы Б.К., 5-6 - да это там уже матан, но 3нф просто естественна.

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

(40) для "правки в нескольких местах одним куском" придумали транзакции

(40) >  в первую очередь избыточность проблемна тем, что одно и то же приходится править в нескольких местах

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

(39) как-то ты своеобразнно понимаешь нормализацию данных

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

Как яркий пример нарушения нормализации в 1с - таблица адресов. Прям целая пощёчина нормализации. Поля:
Объект (Ссылка)
ВидКИ
ТипКИ
ПредставлениеКИ
Поле1
Поле2
Поле3
Поле4
...

1. ТипКИ всегда берется и по-логике связан с ВидомКИ. Поля ТипКИ быть вообще не должно, оно должно получатся пробрасыванием через левое соединение контакта с ВидомКИ
2. Технически возможна ситуация вроде такой:
ВидКИ = "Юридический адрес", ТипКИ = "Телефон"
3. Данные между адресами могут совпадать. Например, юридический и фактический адрес могут быть одинаковыми
4. Опять же технически легко нарукозадить с поавторяющимися контактами. Юридический адрес сделать "Мухосранск, ул.Сурикова, 44", фактический адрес "Мухосранск, ул. Сурикова, 444"
5. Поля в таблице избыточны во многих случаях

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

(43) Может это ты ее как-то своеобразно не понимаешь?

(44) Айпишник же зависит от времени и от сервера. В данном случае 3 н.ф. есть, но нарушается 5 н.ф.

(45) Не знаю где ты там яркий пример нарушения нормализации углядел. Нарушается только BCNF, но выполняется 3 н.ф. Ты бы ей богу правду разобрался, что такое нормализация и зачем она нужна. Глядишь, пригодится.

(46) вот ты и разберись, что это такое. Если в КИ не видишь нарушения нормальных форм, то я прям не знаю...

(47) Ну давай немного развею твое невежество.
1) Почему присутствует поле "Тип", хоть у "Вида" есть реквизит "Тип"? Да потому что реквизит справочника ВидыКИ с именем "Тип" - это не более чем тип по умолчанию. На практике у меня в базе заведен ВидКИ - "Адрес для информирования о задолженности" и у половины клиентов там тип email, а у другой половины - почтовый адрес. И поле Тип нужно, чтобы понять кому из клиентов послать мыло, а для кого подсунуть секретарю на отправку печатную форму.

2) То что юридический и фактический адрес совпадают - это вообще никакого отношения к нормализации не имеет. Что, если у клиента изменился юридический адрес, то обязательно должен поменяться фактический (или наоборот)? Это просто частное совпадение - бывает.

3) А если у клиента юридический адрес ул.Сурикова 40-1-567_1432143бис_левый, а фактический написан Сурикова 40, потому что ни одна собака не найдет по юридическому?

4) Ну возможно, тебе кажется, что поле Представление избыточно, но это не так. Раз не для всех адресов имея правильный xml из ФИАСа можно составить правильное представление (а, например, для иностранных очевидно нельзя), то значит и функциональной зависимости там нет. А такие поля как Страна и Город так же в общем-то не однозначны. Достаточно какую-нибудь Абхазию рассмотреть или Севастополь.

(44) Это вообще две разные схемы, решающие две разные задачи. В одном случае ip адрес - это атрибут сервера, а во втором - сохраняемый параметр операции поиска.

(47) > то я прям не знаю
Это упрямство уже было в ветке про Линтер.

(48) чувак, ну ты всё-таки почитай, что такое нормализация данных и как её делают. Вот неплохо объясняют:
https://info-comp.ru/database-normalization

Веб-сервис в базе источнике, обращение к нему из базы приемника, получение информации в текстовом виде, отображение на форме.

(51) Ахаха, статья на уровне школьного учебника

и пример как бы доставляет

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

(55) решил по-умному съехать? Ну сходи на форум DBA, спроси каким нормальным формам соответствует КИ в 1с, ответы тебя удивят

(53) ну, попробуй опровергни. Сможешь?

(57) Т.е. своих аргументов нет, и ты предлагаешь мне сходить на какой-то форум, я т.п. ораклоидов, и там поспрашивать про тонкости хранения информации в 1С? Не, тебе надо, ты и иди, хочешь лесом, а хочешь полем. Опровергать невежду себе дороже, так что с тобой прощаюсь.

(45) А вот я помню такая же фигня произошла с ответственными лицами организаций в БП. Было нормализованное хранение, а потом сделали денормализацию, зачем-то, вместо ключей отбора сделали отдельные колонки для директора, главбуха и т.п..

(58) чувак, ну ты же решил поумничать про нормализацию БД, вот я тебе и предложил окунуться в реальность. Ладно, вижу что ты ломаешься. Если я сам пойду на форум DBA и там порасспрашиваю про нормализацию контактной информации в 1с, потом опубликую на мисте, ты же не станешь отнекиваться?

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

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

А по поводу вида и типа контактной информации - тут разделение по принципу использования.
Тип - это как редактировать и что оно из себя представляет.
Вид - что это такое и для чего используется.

(63) да, но информация по "как редактировать КИ" прекрасно могла быть получена левым соединением с видом КИ. Тут даже с попаданием в индексы всё тип-топ

(60) > Если я сам пойду на форум DBA

То про 1С (и тем более про реализацию в ней контактной информации со всеми сценариями) дбашники услышат только от тебя. А твоя точка зрения уже известна.

Идея забавная, предсказуемая, фузиной воняет.

(61) > про права пользователей
И про обмены.

(66) и животноводство!

(41) обязательно найдётся кто-то или что-то, не выполнившее все до единой требуемые операции и закоммитившееся.

(67) >  и животноводство
Так это и есть про права пользователей и их ведение =)

(62) Только вот никаких плюсов в данном случае нет. Экономия двух строчек кода при обращении. Причем старый механизм был более гибкий - позволял добавить произвольных ответственных лиц, а не только прибитых гвоздями директора и главбуха.

(65) ну ты сходи, раз мне не доверяешь. ДБАшникам вообще не нужно ничего говорить про 1с. Вот таблички, вот связи, вот данные. И сам вопрос - насколько это всё соответствует нормальным формам?

(7) ну не совсем двух строчек, а поболее. Левое соединение для получения босса, второе левое соединение для получения главбуха, третье левое соединение для получения кассира... И так в 100500 запросах

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

(73) ты рассуждаешь о какой-то гипотетической необходимости. Выбор-то какой. Либо сделать удобно для тех ста случаев, которые уже здесь и сейчас. Либо сделать универсально, малоудобно для имеющихся ста случаев, но чтобы можно было быстренько подстроиться под единичный случай, который возможно настанет когда-то там, а может и не настанет никогда

В архитектуре есть такой важнейший принцип - YAGNI. Расшифровывается как "тебе это не понадобится". Это как раз наш случай

(71) а толку-то от этой норм формы, если бпзу можнт дорабатывать ктн? А вот уход от норм- это как раз возможность производить доработку любому человеку. Отсюда и количество спецов

(74) Так ладно бы, если бы так было. Но изначально было по другому, а потом зачем-то понадобилось заморачиваться, менять структуру данных, в куче мест переписывать код - и ради чего? Чтобы потом у людей доработки отвалились? Вообще, 1с любит заниматься подобным, то функции из модуля в модуль перетасует, то структуру данных поменяет не ровном месте без особых потребностей.
Просто есть денормализация оправданная - это я например о недавних инновациях в хранении субконто, это реально ускоряет выбор движений. А есть чисто "из вредности", чтобы гемора создать всем.

(75) у нас про это и разговор, что нормализация не панацея, и что на неё кладут болт во многих случаях

(77) нормализация нужна когда бд будет работать в режиме жестких ограничений при условиии что меняться архитектура не будет. Это все военные темы

(76) дык, развивают свои продукты, вычищают старое дерьмо. Например, в старых типовых можно встретить толстые регистры сведений, у которых 6-8 измерений и столько же ресурсов/реквизитов. Такой регистр натуральное дерьмо. Удобство записи в регистр низкое, удобство чтения из регистра низкое, производительность низкая. Сейчас такой колхоз уже не городят. Большинство регистров компактные, с 1-2-3 измерениями. Но и тут я не уверен, что победил здравый смысл и осознали неудобство работы с регистрами-монстрами. Возможно такие регистры выхорчевали под натиском техэкспертов, боровшихся за производительность при многопользовательской работе

(78) не совсем. Тут важно понимать исторический контекст. Сами по себе реляционные БД возникли во времена, когда компьютеры были слабенькими, и было экономичеаки оправдано бороться за каждый килобайт оперативной памяти и каждый килобайт места на диске. Я даже больше скажу, реляционщина появилась как средство борьбы с несовершенством жестких дисков. Найти на диске файл по имени легко и быстро, а прочитать содержимое файла - долго. Пока считывающая передвинется в нужное место проходит относительно много времени. Сейчас эти проблемы пережиток прошлого. SSD решили проблему считывающей головки. И поэтому реляционные БД и SQL уже давно не доминируют. Всё большее распространение получают NoSQL базы данных. Ибо они позволяют хранить данные в понятном и удобном для использования виде, без соединения 100500 таблиц между собой

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

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

(80) > реляционщина появилась как средство борьбы с несовершенством жестких дисков.
Фантазер. Она появилась как средство организации данных.

(81) >>модификация в случае нормализованных данных намного легче с точки зрения операций записи на диск

В чем легче?

(80)[ Я даже больше скажу, реляционщина появилась как средство борьбы с несовершенством жестких дисков]
ты бредишь, на момент появления первых СУБД дисков не было, были перфокарты и 9-мм ленты

(95)9-мм ленты - 9 дорожечные конечно

(82) пока что держатся, но век жестких дисков подходит к концу

(83) это не мои фантазии. К сожалению, сейчас не могу процитировать книгу, она у меня дома

(85) причем тут первые СУБД, когда речь про реляционку? Реляционные БД появились в 70-е, жесткие диски в 50-е

(87) > сейчас не могу процитировать
Ну начнем с википедии, что-ли. Там прямо написано:
https://ru.wikipedia.org/wiki/Нормальная_форма

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

(89) начни лучше с (36)

(90) О, началось деление источников на приемлимые и неприемлимые. Как ты думаешь, что можно сказать про книгу, которую ты сейчас не можешь процитировать?

(91) а тебя в институте не учили различать источники информации?

(92) Точно также как и тебя

(88) ешё раз, реляционные СУБД развились до момента промышленного использования жёстких дисков

(93) не похоже. Для меня, например, свободно релактируемая википедия ни разу не авторитет

(94) с чего бы это вдруг?

Кодд только в 1970-м выкатил миру реляционную модель данных. Сами РСУБД появились годами позднее. Жесткие диски на тот момент уже широко применялись

(95) Вот тебе первоисточник: https://forum.thethirdmanifesto.com/wp-content/uploads/asgarosforum/987737/00-efc-further-normalization.pdf

Найди там, пожалуйста, что-нибудь про экономию на жестких дисках.

(98) ты издеваешься? Ты сам три минуты назад нагуглил этот текст, и конечно же не прочел его, но почему-то предлагаешь изучить его мне

(99) А тебя в институте не учили работать с источникам информации?

(100) чувак, у тебя на лбу написано, что ты решил поспорить со мной ради спора. А тема реляционки и нормализации данных тебя не интересовала никогда. Ты на эту тему не то что книг, даже статей не читал. Чего ты пытаешься добиться?

(101) Ты уже нашел в приведенной статье-первоисточнике упоминание об экономии на жестких дисках?

(102) зачем? Я и так прекрасно знаю, что одна из целей нормализации - устранение избыточности данных (читай - экономия места). Ты бы это тоже понял, если бы попытался прочесть и понять хотя бы свои же источники

"Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше"

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

(105) "некоторые клиенты считают это нежелательным"
Клиенты с испорченными экселем мозгами..

Excel vpr
Там все также.
Просто,иногда лучше одна таблица,чем 10 хотя и наблюдается дублирование.
Например,номенклатуру,которая имеет свойства и параметры,можно хранить в линейной таблице,можно разбить на несколько таблиц,а можно таблицу для доп.реквизитов.

(107) типовые "тяжёлые" решения 1С настолько не нормализованны, в особенности ERP, что дискус об избыточности данных для решения факультативного кейса ТС-а выглядит бессмысленным и бесполезным

(107) ВПР. На аглицком VLOOKUP. Внешний ключ классический :)

И по поводу key-value database.
В современных базах данных,первичный ключ для многих таблиц - это Уникальный идентификатор.
В этом случае,таблицы sql-базы мало чем отличаются от контейнеров nosql-базы.
Особенно,если для остальных полей выбраны строки переменной длины,и общий размер записи объекта становится переменный.

(110) NoSQL это не совсем про то. Например, данные могут храниться в формате JSON, причем структура документов JSON может различаться внутри одной "таблицы". Для ряда задач такой подход очень удобен. Не нужно городить колхоз из "плоских" таблиц, данные хранятся сразу в удобном и понятном виде

(0) это тебе не в УФ, а в ОФ. УФ не умеют отображать данные не записанного объекта, даром что "управляемые", гыгыгы

(111) но вот строить отчеты по таким данным, наверно, тот еще секас

(108) мы же не виноваты что тс живет в килобайтах 30 лет назад, а мы в терабатах сегодня

(112) > УФ не умеют отображать данные не записанного объекта, даром что "управляемые"

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

(112) и транзакции не помогут - они только на севрере. по идеем можно было бы записать в транзакции объект, получить его форму, запомнить как она заполнена, потом откатить транзакцию. Но увы - нет, форму можно получить только на клиенте, а там транзакция должна быть уже завершена. только если записать, потом откатить назад, но не в транзакции.

ох епырст дискуссия развернулась. ну место на диске сейчас не проблема, это не основной вопрос, хотя тоже присутствует, основной - быстродействие, скл у нас временами становится слабым местом. немного статистики о ссылках, о которых речь: 30000~40000 в месяц * 3 документа * 12 месяцев * 10 лет. + ТЧы в каждом. создаются в смежной базе, переносятся, без реквизитов и тычей. если продублировать и реквизиты, то физически это будут две рядом лежащие базы, с одинаковым набором данных, ну как то даже по неформальным признакам ставится "не по себе", ну и скорость выполнения запросов/записи станет еще грустнее. в "целевой" базе данных тоже хватает, несколько основных таблиц, около 120 млн записей в каждой. в не лучший день/час/момент мягко говоря подтормаживает. или скорость работы скл перестала зависеть от объема хранящихся данных в базе?

(112) форму я привел как пример, объект, который теоретически мог бы сериализоваться и потом обратно, что бы не рисовать ничего, удобно
как варианты подойдут, что подсказывали выше - html, oData, спасибо. не делал еще, наверно будут камни.