|
Получить структуру SQL-таблиц базы данных | ☑ | ||
---|---|---|---|---|
0
Врадий
18.04.13
✎
11:26
|
Надеюсь на отзывчивость тех, кто уже понял принципы построения SQL-таблиц базы данных
1С:Предприятие 8.2 (8.2.17.157) Управление производственным предприятием, редакция 1.3 (1.3.38.4) Необходимо получить структуру SQL-таблиц базы данных, для этого используем язык 1С: Пример приведен для справочника «Номенклатура» МассивИменМетаданных = Новый Массив(); МассивИменМетаданных.Добавить(Метаданные.Справочники.Номенклатура); СтруктБД=ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных); Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)), то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны. Вопрос: подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf . |
|||
45
Рэйв
18.04.13
✎
12:37
|
||||
46
Infsams654
18.04.13
✎
12:38
|
(43) прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы
|
|||
49
Infsams654
18.04.13
✎
12:46
|
(47) абсолютно не при чем. "За державу обидно".
Меня устраивает "оптимизатор запросов 1С", хоть и не фан. Как, говорилось на этом форуме не раз, готовить запросы надо уметь. |
|||
50
mistеr
18.04.13
✎
12:46
|
Почему-то все адепты прямых запросов не учитывают вероятности получить несогласованные данные.
|
|||
51
ДенисЧ
18.04.13
✎
12:49
|
(50) Это с какого перепою?
|
|||
52
Врадий
18.04.13
✎
12:52
|
(45) Спасибо!!! Смотрю...
ВСЕМ СПАСИБО |
|||
53
Sammo
модератор
18.04.13
✎
12:53
|
(47) Флейм в тематике
|
|||
54
Infsams654
18.04.13
✎
12:55
|
(51) ну как с какого? В обход объекта 1С что-то писать...
|
|||
55
Врадий
18.04.13
✎
13:03
|
данные из 1С попадают в систему весовых терминалов....обрабатываются там....затем обратно в 1С....кто работает с весовым оборудованием??? средства 1С дают хорошие возможности??????
|
|||
56
mistеr
18.04.13
✎
13:04
|
(51) Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе.
(54) Я про чтение. |
|||
57
Infsams654
18.04.13
✎
14:04
|
(56) про чтение да. 100+
|
|||
58
Infsams654
18.04.13
✎
14:05
|
(55) а какие не дают ?
|
|||
59
Serginio1
18.04.13
✎
14:22
|
(56) Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?
v8: Разделяемый или Исключительный режим блокировки |
|||
60
Infsams654
18.04.13
✎
14:27
|
(55) в продолжение темы для "адептов":
Для чего надо делать так (0): ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать Для чего не надо делать так: 1. БД зависимо 2. лицензионное соглашение и согласованность данных 3. даются средства высокого уровня, зачем лезть в кору 4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики |
|||
61
mistеr
18.04.13
✎
15:38
|
(59) Блокировки хранит менеджер кластера.
|
|||
62
Serginio1
18.04.13
✎
15:41
|
(61) Как другой кластер (рабочий процесс) об этом узнает? Проще использовать блокировки БД
|
|||
63
МихаилМ
18.04.13
✎
17:58
|
(60)
запудрить тупых рисовальщиков формочек и отчётов 0 что значит бд зависимо? 1с примерно одинаково гененрирут названия полей для разных субд (всего 3 варианта) 2 с учетом оговорок смысла не имеет. тк практически любой объект бд- метаданных можно привести к состоянию требующему разрешённому и рекомендованному фирмой 1с вмешательству. 3. вот тут верно. тк 1с8 на риалтайм систему не тянет. лучше через коннектор. мне через саповский коннектор в 10 раз удобней было работать с САП чем на прямую в скл сервер писать. 4. если делать через view с именами метаданных - то все равно. |
|||
64
mistеr
18.04.13
✎
18:35
|
(62) Рабочие процессы обращаются к менеджеру. А другой кластер это другая база.
|
|||
65
МихаилМ
18.04.13
✎
18:49
|
(64)
с какого релиза? |
|||
66
Serginio1
18.04.13
✎
18:53
|
(64) Рабочие процессы это реально разные процессы со всоей виртуальной памятью.
Другой кластер это другой компьютер а база у всех одна. Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД? Меня интересует технический процесс. |
|||
67
etc
18.04.13
✎
20:10
|
(17) чтобы этого не случалось в SQL есть роль db_datareader
|
|||
68
mistеr
18.04.13
✎
20:57
|
(65) (66) Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет.
Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера. И не путайте "рабочий процесс" и "кластер". |
|||
69
mistеr
18.04.13
✎
20:58
|
(66) Хранить блокировки только в БД разумеется эффективнее. Но это не всегда возможно, см. выше.
|
|||
70
МихаилМ
18.04.13
✎
21:40
|
(69)
"желтые книжки почитайте" - - какую главу. если Вы сами не использовали что-то то к ЖК лучше не аппилировать, тк это 1с. В ней заявленое может не работать, рабочее может быть не декларированным. поэтому и интересно, можете ли Вы точнее чем общий отсыл к ЖК или интернет подтвердить работу кластера с разными бд. |
|||
71
mistеr
18.04.13
✎
21:50
|
(70 >подтвердить работу кластера с разными бд.
Не понял Главу постараюсь найти. |
|||
72
sda553
18.04.13
✎
23:45
|
(38) Ты опоздал, вроде как веб сервисами пользоваться умеют уже все, а поднимать веб сервер дорогого стоит
|
|||
73
mistеr
19.04.13
✎
02:55
|
(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера На ИТС тоже есть. |
|||
74
МихаилМ
19.04.13
✎
08:25
|
(73)
спасибо. |
|||
75
Serginio1
19.04.13
✎
11:00
|
(73) Понимаешь блокировки так или иначе происходят на стороне БД смотри v8: Разделяемый или Исключительный режим блокировки сообщение 37.
Организовывать свою систему блокировок не имеет смысла. Это имело бы смысл если бы сервер приложений был в единственном процессе, где доступ к объектам был бы в одном адресном пространстве. Когда существует не только множество процессов но и кластеры на различных компьютерах, то любое обращение должно приводить к маршалингу данных как между процессами на одном компьютере так и между другими компьютерами. Просто мне интересно приведи пример блокировок на уровне менеджера кластера, что бы знать о подводных камнях. http://v8.1c.ru/overview/Term_000000126.htm#1 Мало того в 8 ке применяется оптимистическая блокировка. Управляемые блокировки используют хинты SERIALIZABLE,REPEATABLEREAD Здесь тоже писатели про оптимистическую и пессимистическую блокировку http://langslab.com/ebooks/prof-dev2/tome1/pr-dev-t1-ch04 Оптимистическая блокировка осуществляется на уровне поля ._Version v8: Кэши разные нужны, кэши нужные важны. Пессимистическая на уровне блокировок в транзакции. Нет смысла городить огород там, где он не нужен. Но вот если будут реальные примеры объектных блокировок осообенно в контексте нескольких серверов приложений. |
|||
76
mistеr
19.04.13
✎
12:00
|
Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в (50). Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.
|
|||
77
Рэйв
19.04.13
✎
12:03
|
||||
78
Serginio1
19.04.13
✎
12:09
|
(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile |
|||
79
mistеr
19.04.13
✎
12:34
|
(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.
|
|||
80
mistеr
19.04.13
✎
12:42
|
(76) Спасибо, но верстка там полных швах.
|
|||
81
Serginio1
19.04.13
✎
12:42
|
Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.
|
|||
82
mistеr
19.04.13
✎
12:46
|
(77) Более полезная статья: http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm
Но там верстка еще хуже. Читатьможно только в Опере в режиме Fit to width. |
|||
83
mistеr
19.04.13
✎
12:51
|
(81) Давай ты прочитаешь (82), с терминологией и общей концепцией все устаканится, потом продолжим.
Правда, там в тексте упоминается 8.1, кое-что могло и устареть. |
|||
84
ssh2006
19.04.13
✎
13:11
|
(81) > Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD.
Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются. |
|||
85
Рэйв
19.04.13
✎
13:19
|
(82)У меня на лисе нормально.
|
|||
86
МихаилМ
19.04.13
✎
13:33
|
(84)
раньше (до 14 релиза) накладывались блокировки субд. сейчас может исправили. |
|||
87
МихаилМ
19.04.13
✎
13:34
|
+(86) при управляемых блокировках
|
|||
88
Serginio1
19.04.13
✎
13:42
|
(84) Интересно, а почему Управляемые блокировки только в Транзакции. И уровень изоляции Read Commited?
Интересно а это что за блокировки http://www.sql.ru/forum/actualthread.aspx?tid=912872 (83) Ты мне так и не объяснил механизм объектных блокировок между рабочими процессами. Для этого нужен некий общий процесс к которому будут обращаться все рабочие процессы за блокировками. Это тебе не единое адресное пространство. Необходим маршалинг данных. Мало того кластеры могут находится на разных серверах. http://v8.1c.ru/overview/Term_000000126.htm#1 |
|||
89
Infsams654
19.04.13
✎
13:55
|
ух разошлись про блокировки. Ну и что, выяснили что нибудь? Если, выяснили, то через несколько релизов платформы 1С забудьте. Вам же ясно говорят, нечё лезть куда ни надо
|
|||
90
MM
19.04.13
✎
13:56
|
(88) Внутри одного из менеджеров кластера (процесс) запускается служба (в терминах 1С) транзакционных блокировок, конечно, это маршалинг, но если рабочих процессов больше одного, то без этого управляемые блокировки не организовать. Если рабочий процесс один то в предыдущих версиях этот механизм блокировок размещался в рабочем процессе, с тех пор рекомендация, на х64 запускать один рабочий процесс, если нет веских причин поступить по-другому.
|
|||
91
MM
19.04.13
✎
14:05
|
(88) Так и сказано управляемые блокировки используют Read Commited (или Snapshot Isolation в 8.3), а блокировки в разрезе объектов 1С держит менеджер блокировок.
(89) Так это и есть официально объяснение лицензионного запрета, вы там наулучшаете, а мы в свою очередь всё переделаем внутри в новой версии и в неё уже автоматом ничего не сконвертируется при обновлении, и могут обвинить в этом не улучшателя, а производителя. |
|||
92
Serginio1
19.04.13
✎
14:06
|
(90) Объясни зачем городить огород если все это можно решить на уровне БД, для рабочих процессов больше 1?
Могут быть кластеры на нескольких серверах. Где выигрыш если рабочих процессов больше чем 1? |
|||
93
Serginio1
19.04.13
✎
14:12
|
(91) Зачем в запрсах применять хинты
FROM _AccRg5523 T3 WITH(SERIALIZABLE) LEFT OUTER JOIN _Acc6_ExtDim5518 T4 WITH(REPEATABLEREAD) (91) Глупо изобретать велосипед, там где он уже эффективно работает. Snapshot Isolation хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно. |
|||
94
MM
19.04.13
✎
14:16
|
(92) Например, надо заблокировать одно значение субконто в регистре бухгалтерии по всем счетам, предложи как это сделать блокировками на уровне СУБД.
Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции. Всё дело в том, что, именно, сервер 1С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт. |
|||
95
ssh2006
19.04.13
✎
14:21
|
(86) версия 8.1
Код 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 |
|||
96
ssh2006
19.04.13
✎
14:22
|
(88) та по ходу автоматический режим
|
|||
97
MM
19.04.13
✎
14:24
|
(93) .1 это точно управляемый режим новых версий 8.2?
.2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково! |
|||
98
Serginio1
19.04.13
✎
14:40
|
(96) Для автоматического режима хинт REPEATABLEREAD не имеет смысла.
(97) Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула. |
|||
99
Serginio1
19.04.13
✎
14:54
|
Хотя вот на оракуле
http://my-oracle.it-blogs.com.ua/post-37.aspx Блокировка транзакций 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). Но эти режимы встречаются крайне редко. |
|||
100
MM
19.04.13
✎
14:59
|
(98) Я тоже не знаток оракла. PostgreSQL тоже версионник, есть ли там DBMS_LOCK ?
Но ключевой момент всё же то, что БД не знает про внутреннее устройство объектов 1С и значит не может учесть их природу. Возможно, для MS SQL можно было бы часть операций, таких, например, как расчёт итогов и управляемые блокировки, поместить в хранимые процедуры или .net сборки загруженные в процесс СУБД. Но они пошли по пути переписать под себя, ведь завтра множество поддерживаемых СУБД может расшириться. |
|||
101
ssh2006
19.04.13
✎
15:02
|
(98) запрос при проведении документа, автоматические блокировки
exec sp_executesql N'UPDATE _Document6303 SET _Marked = P1 FROM _Document6303 WITH(REPEATABLEREAD) WHERE _Document6303._IDRRef = @P2 AND _Document6303._Version = @P3',N'P1 varbinary(1),@P2 varbinary(16),@P3 varbinary(8)',0x00,0x840D00151730A35011E22F1E926C06FC,0x0000000001493E2A |
|||
102
Serginio1
19.04.13
✎
15:21
|
(100) А зачем знать внутренне устройство? Блокировки накладываются не только на запись но и на индекс.
|
|||
103
MM
19.04.13
✎
15:24
|
(99) не противоречит тому, чему меня учили в 1С. блокировки записи не мешают блокировкам чтения, эти эксклюзивные блокировки не похожи на одноимённые в MS SQL.
|
|||
104
Serginio1
19.04.13
✎
15:27
|
(101) Интересно какой смысл применять REPEATABLEREAD при UPDATE если на нё автоматически накладывается эксклюзивная блокировка?
|
|||
105
Serginio1
19.04.13
✎
15:30
|
(103) Интересно зачем Разделяемые и эксклюзивная?
Есть хинты NoLock но они не блокирующие. |
|||
106
MM
19.04.13
✎
15:33
|
(102) Вы так и не объяснили как заблокировать одно субконто во всех таблицах бухгалтерии средствами sql? На этапе проверки остатков до начала изменений.
|
|||
107
Serginio1
19.04.13
✎
15:36
|
(100) http://wiki.dieg.info/postgresql для
? ACCESS SHARE MODE. Устанавливается автоматически командой SELECT для таблиц, из которых производится выборка данных. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровня ACCESS EXCLUSIVE MODE. ? ROW SHARE MODE. Устанавливается автоматически командами SELECT, содержащими секцию FOR UPDATE или FOR SHARE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE. ? ROW EXCLUSIVE MODE. Устанавливается автоматически командами UPDATE, INSERT и DELETE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и CREATE INDEX. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней SHARE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE. ? SHARE UPDATE EXCLUSIVE MODE . Устанавливается автоматически командами VACUUM (без FULL), ANALYZE и CREATE INDEX CONCURRENTLY. ? SHARE MODE. Устанавливается автоматически командами CREATE INDEX (без CONCURRENTLY). В заблокированных таблицах запрещается выполнение команд INSERT, UPDATE, DELETE, ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW EXCLUSIVE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE. ? SHARE ROW EXCLUSIVE MOOE. Специальный режим блокировки, практически идентичный режиму EXCLUSIVE MODE, но допускающий установку параллельных блокировок уровня ROW SHARE MODE. ? EXCLUSIVE MODE. Запрещает выполнение команд INSERT, UPDATE, DELETE, CREATE INDEX, ALTER TABLE, DROP TABLE и VACUUM, а также команд SELECT с секцией FOR UPDATE. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW SHARE MODE, ROW EXCLUSIVE MODE, SHARE MODE, SHARE ROW EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE. ? ACCESS EXCLUSIVE MODE. Устанавливается автоматически командами ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц запрещаются любые команды или параллельные блокировки любого уровня. |
|||
108
Serginio1
19.04.13
✎
15:37
|
(106) То есть ты не знаешь как хранятся итоги и движения по субконто?
|
|||
109
krbIso
19.04.13
✎
15:44
|
о чем спор то?
в (0) вроде не блокировки спрашивал |
|||
110
Serginio1
19.04.13
✎
16:11
|
(109) См 50,56
|
|||
111
MM
19.04.13
✎
17:07
|
(108) Если субконто не первое, то не будет подходящего индекса, а значит лишние блокировки при REPEATABLE READ и выше. (Хотя и для первого, как я погляжу, индекс требует период и организацию) Как работает for update при Read Commited я не знаю, просветите.
В (107) плохо описана работа for update. |
|||
112
Serginio1
19.04.13
✎
17:29
|
(111) Там остатки в разрезах хранятся.
http://main.1c-ei.ru/Home/help/objectdb/dbschema#TOC--18 Что значит излишнее? Я для таких случаев делаю регистр сведений и на нем делаю блокировки когда нужно заблокировать несколько таблиц, но по одинаковым измерениям. По поводу для изменения посмотри v8: блокировки при записи в регистр сведений А в 1С нет блокировок updlock. |
|||
113
ssh2006
19.04.13
✎
17:40
|
(112) > А в 1С нет блокировок updlock.
В автоматическом режиме конструкция ДЛЯ ИЗМЕНЕНИЯ d pfghjct дает UPDLOCK |
|||
114
Serginio1
19.04.13
✎
17:48
|
(113)
Спасибо. Буду знать. |
|||
115
Serginio1
19.04.13
✎
17:54
|
114 + Правда у них он не такой уж и UPDLOCK
v8: Оптимизация SQL WITH(SERIALIZABLE, UPDLOCK) интересное сочетание |
|||
116
MM
19.04.13
✎
17:57
|
(112) В управляемом режиме Read Commited снимает блокировку сразу и, вероятно, for update игнорирует.
Лишние, я имел ввиду, что REPEATABLE READ блокирует все прочитанные записи, а в отсутствии индекса по блокируемуму измерению (или субконто) будет читаться лишнее. Отдельный РС это разве не костыль? Если нарушить порядок наложения блокировок получим взаимоблокировку. Или интересный вопрос, как бы вы блокировали данные которых возможно и нет? Как я помню в автоматическом режиме такая проверка остатков блокировала всю пустую или слабо заполненую таблицу. |
|||
117
Infsams654
19.04.13
✎
18:02
|
(100) + 100500. Так, почему в 1С нет объектов типа хранимых процедур, функций и вьюх ? Казалось, бы, все просто, ан нет, СУБД то разные. Свой язык-транслятор сделать в Transact SQL, PL/SQL и т.п. и во вьюхи разных диалектов ... к (60) п.1
|
|||
118
mistеr
19.04.13
✎
18:14
|
Читаю http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm и понимаю, что где-то уже читал. Покопался в книжках - так и есть. Это из книги Радченко-Хрусталевой Архитектура и работа с данными 1С:Предприятия 8.2. Глава 4. Почти Один-в-один. Вот те на думаю, причем же здесь "Автор: Белоусов Павел (Альтер Лого, Москва)"? Для 1С с ее отношением к авторским правам очень странно...
К чему это я? Советую всем прочитать/перечитать эту главу. Желательно в книге, но если нет, то статью по ссылке. Потом можно обсуждать интересующие вопросы про блокировки на должном уровне, но В ОТДЕЛЬНОЙ ТЕМЕ. Эта уже становится мусоркой. А вопросы есть. Например, где живут управляемые блокировки при работе с файловой базой. Единого сервера-то нет. |
|||
119
mistеr
19.04.13
✎
18:17
|
Кстати, являюсь "знатоком Оракла". Могу пояснить по нему, что интересует. Опять же в отдельной теме.
|
|||
120
MM
19.04.13
✎
18:17
|
(117) Я имел виду использование хранимок для встроенных нужд, которые не связаны с языком 1С, в 7.7 они ведь были.
(118) В файловом режиме табличные блокировки, как сказано в приведённой статье, что очень упрощает их структуру; живут, вероятно, во временном файле. |
|||
121
mistеr
19.04.13
✎
18:19
|
(120) Я не про табличные. Я про те которым нет места в СУБД. То же субконто в РБ.
|
|||
122
Infsams654
19.04.13
✎
18:24
|
(120) - какие хранимки были ?
к (63) п. 1 - если бы было так просто, то 1С крутилась бы на всех SQL-серверах на 4 - к (117) в вьюху подцепить имя поля по-русски - реально ? |
|||
123
Ковычки
19.04.13
✎
18:40
|
а чо в восьмерке нету ид вида объекта ?
|
|||
124
MM
19.04.13
✎
18:49
|
(123) Есть, например, _Value_TYPE есть в регистрах бухгалтерии, только у него тип binary(1) в MS SQL, а по сути целое число.
|
|||
125
Ковычки
19.04.13
✎
18:52
|
(124) а по адинесовски он доступен ?
|
|||
126
fisher
19.04.13
✎
18:56
|
Чо, реально что ли при создании новой базы из cf имена таблиц могут отличаться от базы-источника cf?
Я почему-то был уверен, что имена таблиц однозначно генерятся по внутренним идентификаторам метаданных... |
|||
127
MM
19.04.13
✎
18:58
|
(125) Только в виде проверки на тип (ТипЗнч) или оператор ССЫЛКА в языке запросов. При сильном желании можно из ЗначениеВСтрокуВнутр(Ссылка) получить.
(126) хм, вряд ли объекты в CF идентифицируются по ГУИДам, а идентификаторы видов объектов маленькие числа, при свёртке были бы коллизии. |
|||
128
Serginio1
22.04.13
✎
10:50
|
(116) Отдельный РС это как раз не костыль, а оптимизация.
Тебе не нужно накладывать лишние блокировки, особенно когда нужно накладывать блокировки на множество таблиц. А вот за последовательностью тебе нужно самому следить. Но для этого создаются общие процедуры накладки блокировок. На то они и управляемые. При автоматических, ты легко можешь получить взаимные блокировки сначала прочитав данные, а потом записывать. И может получится так, что другая транзакция тоже хочет записать данные и прочитала данные до записи первой. Делать блокировки на уровне Сервера приложений достаточно не дальновидно, так как в любой БД уже существуют блокировки и заново изобретать велосипед просто не стоит. Стоит оптимизировать блокировки. Например регистр остатков состоит как минимум из двух таблиц. Движений и остатков по периодам. Стоит выделить один регистр который хранил бы измерения которые были в движениях. (124) binary(1) это в большинстве случаев boolean. |
|||
129
MM
22.04.13
✎
12:16
|
(128) Легко ли унифицировать все способы блокировок для различных версий СУБД?
Насколько я понимаю, почти всегда достаточно заблокировать остатки на конец времён по тем измерениям, которые планируется изменить, и сделать это перед началом их чтения. > Стоит выделить один регистр который хранил бы измерения которые были в движениях. Можно по-подробнее? тип составного реквизита boolean? скорее signed/unsigned char. |
|||
130
Serginio1
22.04.13
✎
12:29
|
(129) Да. Я уже тебе давал ссылки. Мало того сама 1С ставит сочетание хинтов которые излишни.
А вот изобретение велосипеда может приводить к дополнительным ошибкам. Но если есть огромное желание изобретать велосипеды то никто конечно помешать не может. Тем более, что сочетание своих блокировок и блокировок СУБД ведет к излишним потреблением ресурсов. Регистр остатков хранится в виде период измерения. При наложении блокировок будут накладываться блокировки на все измерения по периодам, коих может быть множество. Ну boolean как byte проще использовать. В Delphi например true:= not false то есть true = 255 false = 0. Впрочем как и для олеаутоматион но там -1 |
|||
131
Serginio1
22.04.13
✎
12:30
|
У 1С хранится как 0 и 1
|
|||
132
MM
22.04.13
✎
12:44
|
(115) SERIALIZABLE- это они всегда с регистрами в автоматическом режиме так работали, чтобы победить проблему фантомов. (как вы с ней бороться предложили бы?) UPDLOCK - это ДЛЯ ИЗМЕНЕНИЯ.
(130) По ссылкам нет всех деталей механизмов, не заметил как у этих БД решается проблема фантомов. READ COMMITED вроде не очень ресурсоёмкий уровень изоляции транзакций для БД. > При наложении блокировок будут накладываться блокировки на все измерения по периодам, коих может быть множество. Это об автоматическом или управляемом режиме? в Управляемом вроде граничных блокировок быть не должно. |
|||
133
Serginio1
22.04.13
✎
14:15
|
По поводу блокировок и изоляций транзакций там одно и тоже. Те же хинты и те же изоляции.
А по сути они должны быть и во всех. Так например для расчета остатков нужно запретить любые движения по измерениям во всех периодах. Другой вариант может приводить к взаимным блокировкам блокировкам, когда при при проведении за прошлый период задним числом, будут изменяться последующие остатки по периодам. (123) В хинте WITH(SERIALIZABLE, UPDLOCK) нет смысла, так как SERIALIZABLE уже накладывает эксклюзивные блокировки. |
|||
134
Infsams654
22.04.13
✎
14:24
|
Sergionol достал уже с этими блокировками. Блокировки для вопроса с (0) - частный случай, зависимости от реализации БД, возможно решаемый.
|
|||
135
Serginio1
22.04.13
✎
14:27
|
Во всех есть уровень изоляции SERIALIZABLE
Для того, что бы заблокировать на чтение нужно просто прочитать данные. Например @Х=Select Count(*) From . (134) Почему я а не ММ См 50,56. Мы с ним неспешно ведем беседу. |
|||
136
Infsams654
22.04.13
✎
14:35
|
(135) эта беседа вообще к теме о блокировках, а как они связаны с (0). Открывайте другую ветку, или скажите прямо, чем это поможет (0).
|
|||
137
Serginio1
22.04.13
✎
14:42
|
(136) Ну а ты чего раскипетился? По поводу 0 так все ясно, что базы с одинаковыми названиями реквизитов, могут иметь различное название полей в БД. Подтверждаю. Поэтому есть два режима как загрузка конфигурации так и объединение с файлом конфигурации.
|
|||
138
MM
22.04.13
✎
15:28
|
(133) Так управляемые сервером 1С блокировки эту проблему с остатками решают.
Есть ещё версия, что разработчики по-началу просто не разобрались с разными СУБД и начали построение велосипедов. Странно, но в http://technet.microsoft.com/ru-ru/library/ms173763(v=SQL.90).aspx ничего не сказано про X-блокировки при SERIALIZABLE Инструкции не могут считывать данные, которые были изменены другими транзакциями, но еще не были зафиксированы. Другие транзакции не могут изменять данные, считываемые текущей транзакцией, до ее завершения. Другие транзакции не могут вставлять новые строки со значениями ключа, которые входят в диапазон ключей, считываемых инструкциями текущей транзакции, до ее завершения. Блокировка диапазона устанавливается в диапазоне значений ключа, соответствующих условиям поиска любой инструкции, выполненной во время транзакции. Обновление и вставка строк, удовлетворяющих инструкциям текущей транзакции, блокируется для других транзакций. Это гарантирует, что если какая-либо инструкция транзакции выполняется повторно, она будет считывать тот же самый набор строк. Блокировки диапазона сохраняются до завершения транзакции. Это самый строгий уровень изоляции, поскольку он блокирует целые диапазоны ключей и сохраняет блокировку до завершения транзакции. Из-за низкого параллелизма этот параметр рекомендуется использовать только при необходимости. Этот параметр действует так же, как и настройка HOLDLOCK всех таблиц во всех инструкциях SELECT в транзакции. |
|||
139
Serginio1
22.04.13
✎
15:37
|
(138) Так расскажи про механизм управляемые сервером 1С блокировки? Учитывая, что может быть несколько рабочих процессов на разных серверах?
Про блокировки SQL http://msdn.microsoft.com/ru-ru/library/ms187373.aspx SERIALIZABLE Равнозначен аргументу HOLDLOCK. Накладывает дополнительные ограничения на совмещаемую блокировку: удерживает ее до завершения транзакции вместо снятия блокировки сразу после того, как таблица или страница данных больше не требуется, независимо от того, завершена ли транзакция. Просмотр выполняется с той же семантикой, что и транзакция, запущенная на уровне изоляции SERIALIZABLE. Дополнительные сведения об уровнях изоляции см. в разделе SET TRANSACTION ISOLATION LEVEL (Transact-SQL). |
|||
140
Serginio1
22.04.13
✎
15:50
|
138 Посыпаю голову пеплом. Что то у меня замутило. SERIALIZABLE не накладывает эксклюзивные блокировки.
Поэтому WITH(SERIALIZABLE, UPDLOCK) вполне правильная инструкция. И WITH (XLOCK, SERIALIZABLE) должны накладывать и X блокировки на вставляемые данные http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/20d7a8e1-9098-4db0-aa77-7eb5f4d33dc2/ |
|||
141
MM
22.04.13
✎
15:51
|
В (139) написано про S-блокировку до конца транзакции с захватом соседних записей, но где там про U или Х?
Про технические детали управляемых блокировок можно только предполагать, но у 1С их меньше и они проще чем у MS SQL. С другой стороны этот механизм плохо управляемый, к примеру, невозможно отменить эскалацию при большом количестве записей в регистр. |
|||
142
Serginio1
22.04.13
✎
16:03
|
(141) Особенно когда обновляются миллионы записей. Приходится напрямую писать не от хорошей жизни. И то, что в 1С нет возможности массового применения например Merge просто заставляет применять прямую запись. Да и нет кучу функция для чтения данных. Так, что приходится применять прямые запросы.
|
|||
143
MM
22.04.13
✎
16:07
|
Где-то встречал описание эскалации на 20 000 (или на 5000, не помню точно) записей при проведении документа и ничего с ними не сделаешь.
Сам сталкивался с закрытием месяца с одним пользователем в базе. Сервер 1С зависал на управляемых блокировках, совет производителя блокировать весь регистр бухгалтерии не помог, но установка блокировки на все счета, участвующие в документе, позволили наложить блокировки, которые поглотили все последующие блокировки при записи и позволили записать документ. В менеджере кластера живет TransactionLockService (сервис транзакционых блокировок) rphost'ы к нему обращаются. Кстати, упр. блокировки могут быть применены и при объектном чтении данных, я такими вещами не занимаюсь, но у менеджеров разных метаданных есть соответствующие методы (Выбрать, Остатки, Обороты). (142) Каких функций для чтения нет? |
|||
144
Serginio1
22.04.13
✎
16:40
|
Ну если несколько серверов приложений должен существовать общий сервер через который все блокировки должны взаимодействовать. Читал я про это. Просто когда объем транзакций вырастет, то у него премуществ перед блокировками на уровне БД никаких не будет, только одни сложности.
Да куча. Например работа с датами, строками. Те же Выбрать первые v8: v8: Вcтречаем! Версия 8.2.18, вышла в релизе 8.2.18.61 смотри 228 сообщение. И еще куча всего. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |