Получить структуру SQL-таблиц базы данных #661619

Надеюсь на отзывчивость тех, кто уже понял принципы построения SQL-таблиц базы данных Управление производственным предприятием, редакция 1.3 (1.3.38.4) Необходимо получить структуру SQL-таблиц базы данных, для этого используем язык 1С: Пример приведен для справочника «Номенклатура» Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)),  то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны. Вопрос:   подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf .

Надеюсь на отзывчивость тех, кто уже понял принципы построения SQL-таблиц базы данных Управление производственным предприятием, редакция 1.3 (1.3.38.4) Необходимо получить структуру SQL-таблиц базы данных, для этого используем язык 1С: Пример приведен для справочника «Номенклатура» Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)),  то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны. Вопрос:   подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf .

cf это метаданные 1С к sql отношения не имеют... из того же cf можно вообще сделать файловую базу... а вообще - проводлжайте наблюдать, вас столько открытий ждет

да, имена генерятся

Добро пожаловать в реальный мир

В базе1 добавили новый справочник, появилась таблица _Reference131. В базе1 удалил справочник, таблица _Reference131 удалилась. В базе1 добавили новый справочник, появилась таблица _Reference132 На базу2 накатили обновление из базы1. в базе2 появился справочник с таблицей _Reference131

сопоставление метаданные-данные в params.dbnames

но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова

>но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова одинаковы будут id по которым происходит "быстрая" сверка... также это будет гарантировать что данные не отвалятся при нахлабучивании изменений одной конфы на другую через "загрузить"

Ага. Следует заметить, что отсортированный по имени объектов cf-ник и такой же без сортировки скорее всего даст разные имена таблиц и полей, если, конечно, количество объектов метаданных в каждом типе больше 1 :)

это понятно, я про стуртуру таблиц ы скуле, она тоже совпасть должна

всегда так было, еще с семёрки

Кому должна?

с фигали?

для чего ? Не ищем прохоженных путей?

Ребята!!!! Всем СПАСИБО!! НЕОБХОДИМО из SQL-таблиц получать информацию для другого программного продукта (НЕ 1С).....получается, что надо создавать таблицу соответствий что ли, чтооб не изменять код при чтении данных 1С из таблиц в другом программном продукте(базу 1С планируем обновлять....ведь можно разными способами получить базу данных обновленную чистую для учета с нового года, например).... Кто-нибудь решал такую проблему? Может кто подскажет оптимальное решение....

вьюшки генери...

снабди своё 1С вебсервисом, который будет отдавать то , что надо, и ни чего лишнего. Иначе однажды утром 1С не заведется потому. что какой-то осел нечаянно сказал DROP DATABASE не в то окно

Подтверждаю Дата, подпись

Образение через com в 1с и получение структуры оттуда. Но обычно более эффективным считается работа от обратного, когда 1с отдает в нужном виде.

я решал при обнослении config обновляется таблица сответствий имен полей и имен таблиц в случае необходимости пересоздается view с именами метаданных.

+ Ащета лицензионное соглашение 1С запрещает лезть своими грязными пальцАми в 1Совские БД

Другой продукт каждый раз при коннекте каким то образом инициирует ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных) в конфиге и дальше работает через этот мапинг до конца коннекта. Как реализовать вызов этой процедуры - уже технические формальности

Я создавал базу данных соответствий НазвваниеОбъекта- таблица SQL.так же с реквизитами. дальше запросом получал соответствие и формировал динамически запрос к базе данных. если менялось название какой либо таблицы или реквизита то я просто в базе соответствий менял значение. и запрос опять давал корректный результат. Это все делалось для сверки с 1С другой учетной системы

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

если данные только получать для отчетов и сверок- то это ничем не чревато. а вот если писать в базу то тут существует опасность.

какие опасности существуют при записи в таблицы (представления) ?

а чем чревато создание собственных функций, процедур, вьюшек etc в одинесовской базе?

ничем.

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

всё-равно побаиваюсь. Создать другую базу и в ней создаю всё это хозяйство

Ничего не будет. Я индексами игрался, функции и вьюхи создавал - всё работало как часы

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

Можно ведь создать еще одно юзера к кишкам с доступом на ридонли

данные из 1С читать надо только, обрабатываться будут в другой системе

единственное, наверно, если создавать архив средствами 1С, то потеряется. Но, это не страшно

дык на то пишется процедура-верификатор-создаватор...

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

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

о, ещё один как я :)

Совершенно верно, имена таблиц на уровне MS SQL генерируются заново, поэтому - смотрите сообщения, отмеченные "лампочками".

так я думаю это самое верное решение. т.к. на этапе проектирования не один пуд соли съел)))

все-таки, еще раз вопрос - что в 1С не хватает ? + - изобретать велосипид, БД зависимый. Типа, круто, на asm ваять, а vb - отстой

прямые (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) запросы гораздо быстрее выполняются напрямую-если важна скорость

Значит все средства интеграции, которые предлагает 1С штатно, мы вертели на вертеле? Или просто лень почитать?

На, держи. Описание структуры данных.

прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы

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

Почему-то все адепты прямых запросов не учитывают вероятности получить несогласованные данные.

Это с какого перепою?

Спасибо!!! Смотрю... ВСЕМ СПАСИБО

Флейм в тематике

ну как с какого? В обход объекта 1С что-то писать...

данные из 1С попадают в систему весовых терминалов....обрабатываются там....затем обратно в 1С....кто работает с весовым оборудованием??? средства 1С дают хорошие возможности??????

Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе. Я про чтение.

про чтение да. 100+

а какие не дают ?

Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?

в продолжение темы для "адептов": Для чего надо делать так : ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать Для чего не надо делать так: 1. БД зависимо 2. лицензионное соглашение и согласованность данных 3. даются средства высокого уровня, зачем лезть в кору 4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики

Блокировки хранит менеджер кластера.

Как другой кластер (рабочий процесс) об этом узнает? Проще использовать блокировки БД

запудрить тупых рисовальщиков формочек и отчётов 0 что значит бд зависимо? 1с примерно одинаково гененрирут названия полей для разных субд (всего 3 варианта)   2 с учетом оговорок смысла не имеет. тк практически любой объект бд- метаданных можно привести к состоянию требующему разрешённому и рекомендованному фирмой 1с вмешательству. 3. вот тут верно. тк 1с8 на риалтайм систему не тянет. лучше через коннектор. мне через саповский коннектор в 10 раз удобней было работать с САП чем на прямую в скл сервер писать. 4. если делать через view с именами метаданных - то все равно.

Рабочие процессы обращаются к менеджеру. А другой кластер это другая база.

с какого релиза?

Рабочие процессы это реально разные процессы со всоей виртуальной памятью. Другой кластер это другой компьютер а база у всех одна. Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД? Меня интересует технический процесс.

чтобы этого не случалось в SQL есть роль db_datareader

Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет. Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера. И не путайте "рабочий процесс" и "кластер".

Хранить блокировки только в БД разумеется эффективнее. Но это не всегда возможно, см. выше.

"желтые книжки почитайте" - - какую главу. если Вы сами не использовали что-то то к ЖК лучше не аппилировать, тк это 1с. В ней заявленое может не работать, рабочее может быть не декларированным. поэтому и интересно, можете ли Вы точнее чем общий отсыл к   ЖК или интернет подтвердить работу кластера с разными бд.

(70 >подтвердить работу кластера с разными бд. Главу постараюсь найти.

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

Нашел. Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера На ИТС тоже есть.

спасибо.

Понимаешь блокировки так или иначе происходят на стороне БД смотри сообщение 37. Организовывать свою систему блокировок не имеет смысла. Это имело бы смысл если бы сервер приложений был в единственном процессе, где доступ к объектам был бы в одном адресном пространстве. Когда существует не только множество процессов но и кластеры на различных компьютерах, то любое обращение должно приводить к маршалингу данных как между процессами на одном компьютере так и между другими компьютерами. Просто мне интересно приведи пример блокировок на уровне менеджера кластера, что бы знать о подводных камнях. Мало того в 8 ке применяется оптимистическая блокировка. Управляемые блокировки используют хинты SERIALIZABLE,REPEATABLEREAD Здесь тоже писатели про оптимистическую и пессимистическую блокировку Оптимистическая блокировка осуществляется на уровне поля ._Version   Пессимистическая на уровне блокировок в транзакции. Нет смысла городить огород там, где он не нужен. Но вот если будут реальные примеры объектных блокировок осообенно в контексте нескольких серверов приложений.

Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в . Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.

Так и объектные блокировки имеют смысл без транзакции. Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile

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

Спасибо, но верстка там полных швах.

Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.

Более полезная статья: Но там верстка еще хуже. Читатьможно только в Опере в режиме Fit to width.

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

> Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются.

У меня на лисе нормально.

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

+ при управляемых блокировках

Интересно, а почему Управляемые блокировки только в Транзакции. И уровень изоляции Read Commited? Интересно а это что за блокировки Ты мне так и не объяснил механизм объектных блокировок между рабочими процессами. Для этого нужен некий общий процесс к которому будут обращаться все рабочие процессы за блокировками. Это тебе не единое адресное пространство. Необходим маршалинг данных. Мало того кластеры могут находится на разных серверах.

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

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

Так и сказано управляемые блокировки используют Read Commited (или Snapshot Isolation в 8.3), а блокировки в разрезе объектов 1С держит менеджер блокировок. Так это и есть официально объяснение лицензионного запрета, вы там наулучшаете, а мы в свою очередь всё переделаем внутри в новой версии и в неё уже автоматом ничего не сконвертируется при обновлении, и могут обвинить в этом не улучшателя, а производителя.

Объясни зачем городить огород если все это можно решить на уровне БД, для рабочих процессов больше 1? Могут быть кластеры на нескольких серверах. Где выигрыш если рабочих процессов больше чем 1?

Зачем в запрсах применять хинты FROM _AccRg5523 T3 WITH(SERIALIZABLE) LEFT OUTER JOIN _Acc6_ExtDim5518 T4 WITH(REPEATABLEREAD) Глупо изобретать велосипед, там где он уже эффективно работает.  Snapshot Isolation хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно.

Например, надо заблокировать одно значение субконто в регистре бухгалтерии по всем счетам, предложи как это сделать блокировками на уровне СУБД. Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции. Всё дело в том, что, именно, сервер 1С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт.

версия 8.1 SET TRANSACTION ISOLATION LEVEL READ COMMITTED go SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 AND lastwaittype LIKE 'LCK_%' go BEGIN TRANSACTION go

та по ходу автоматический режим

.1 это точно управляемый режим новых версий 8.2? .2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково!

Для автоматического режима хинт REPEATABLEREAD не имеет смысла. Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула.

Хотя вот на оракуле Блокировка транзакций TX устанавливается при выполнении следующих операторов insert, delete, update, select for update. Блокировки транзакций работают только в режиме (lmode) - 6 exclusive (X) монопольная блокировка. Блокировки транзакций всегда осуществляются на уровне строк: блокируется строка и предотвращается изменение строки другими транзакциями до тех пор, пока не буде выполнен откат текущей транзакции или транзакция не будет зафиксирована. Чтобы была установлена блокировка TX, сначала устанавливается блокировка TM для таблицы в режиме 3 (RX). Затем устанавливается блокировка TX в режиме 6 (X). Блокировка TX не будет установлена, если другая транзакция установила блокировку TX на эту же строку. Блокировки могут быть еще в режиме 4 (разделяемая блокировка таблицы share mode, генерируется, например, оператором lock table <…> in share mode) и 5 (разделяемая блокировка таблицы и монопольная блокировка строк share row exclusive; генерируется, например, оператором lock table <…..> in share row exclusive mode). Но эти режимы встречаются крайне редко.

Я тоже не знаток оракла. PostgreSQL тоже версионник, есть ли там DBMS_LOCK ? Но ключевой момент всё же то, что БД не знает про внутреннее устройство объектов 1С и значит не может учесть их природу. Возможно, для MS SQL можно было бы часть операций, таких, например, как расчёт итогов и управляемые блокировки, поместить в хранимые процедуры или .net сборки загруженные в процесс СУБД. Но они пошли по пути переписать под себя, ведь завтра множество поддерживаемых СУБД может расшириться.