в продолжение темы Собственная автоматизация

svcoder Егоров Александр
А в 1С есть структура БД? как ее посмотреть? такой популярный инструмент, как visio вытаскивает из базы 1С лишь набор абсолютно несвязанных таблиц. Никакой структуры. Может я где-то в конфигураторе упустил меню "структура БД"? Тоже вроде нету. Как может не нравиться то, чего не существует?

В данном случае метаданные храняться в md-файле. То что вторичные ключи не сообщаются SQL Server и вы не видите связей с помощью универсальных инструментов не является проблемой. При желании можно написать обработку которая будет создавать эти связи по информации из метаданных.

вторичных ключей нет в БД 1С. По крайней мере в 77 нет. Я не говорю, что проблема - посмотреть. Я говорю, что сервер БД только хранит таблицы 1С и ничего более. И даже за целостность данных в БД он отвечать не может. Все делается на клиенте. Поэтому структуры БД нет. И написать обработку можно только показывающую как клиентское приложение трактует взаимоотношение полей разных таблиц . Тоже самое можно сказать о любом наборе любых таблиц, даже экселевских. То, что у меня валяется в папке МоиДокументы 35 экселевских документов, имеющих внутренние связи - это БД? Она имеет структуру?

svcoder Егоров Александр
Потому что основные тормоза не в скорости доступа к данным, а в неоптимальной системе хранении данных в 1С и очень больших накладных расходах на "проведение" документов силами клиента.

Раскройте тему о накладных расходах. Особенно если все стандартные блокировки 1С очищены и используется блокировка sp_getapplock.

Отчет "Взаиморасчеты" у меня не использует регистры. Значит наличие регистра "взаиморасчеты", формирование движений по нему при проведении, пересчет его итогов каждое проведение и каждое открытие периода - лишние накладные расходы. Остатки товар по партиям я собираю быстрее, чем 1Ска по регистру остатков товаров - Наличие регистра "ОстаткиТоваров" - лишние накладные расходы. Блокировки в 1С - это следствие тормозной работы клиента, а не причина. Если выполнение ОбработкаПроведения() свести к милисекундам - табличные блокировки перестанут проявляться так сильно, что позволит вырасти количеству проводимых документов за единицу времени вообще не притрагиваясь к апгрейду железа и переносом всех активных пользователей в терминал. И не используя нештатные возможности платформы.

ScareCrow
открой для себя 1С++

Открыл уже давно. причем здесь 1С++?

ScareCrow
там парсер метаимен есть.

я знаю... этим и пользуюсь при создании триггеров и процедур. В ПриНачалеРаботыСистемы сравнивается текущая версия md и последняя версия md, и при их разнице триггера и процедуры перекомпилируются... С испольщованием MetaDataWork и ODBCRecordset. При этом я получаю возможность обработки "проведения" документов непосредственно на сервере, не используя клиентский код 1С и не заставляя 1С загружать вагон данных с сервера, чтобы потом заново записать их обратно.

ScareCrow
>Поэтому структуры БД нет
БД есть а структуры у нее нету
ага.. а вообще про что топик?

Еще раз - то, что у меня валяется в папке МоиДокументы 35 экселевских документов, имеющих внутренние связи - это БД? Она имеет структуру?

Топик о том, что то, что в 1С (77) называется "структурой БД" - набор разрозненных таблиц. То, что в 1С использование встроенных элементов "ускорения обработки данных" и наличие клиентского кода в ОбработкаПроведения() - источник тормозов, а не ускорений.

ScareCrow
>что то, что в 1С (77) называется "структурой БД" - набор разрозненных
>таблиц
давайте определимся с понятиями. что для вас "структура БД"? Связка -
foreign key -> primary key?

Угу. вообще constraints в целом, в том числе и foreign key\primary key. иначе как сервер БД может отвечать за целостность хранимых им данных?

ScareCrow
>иначе как сервер БД может отвечать за целостность хранимых им данных
ясна. каша в голове.

ясна. очередной любитель dbf :)

ScareCrow
>очередной любитель dbf
переходим на личности?

Извиняюсь, погорячился.

Разговор как раз и идет зачем поддерживать обработку данных и проверку целостности на клиенте, если под это уже есть все инструменты непосредственно в самом сервере БД. Особенно в сетевой ИС предприятия. Особенно на интерпретируемом клиенте. Сервер БД в этом случае забирает на себя все рутинные манипуляции с данными уже не только связанные с самим хранением данных во внутренних хранилищях сервера, но и обработку этих данных перед записью, по правилам, заданными в том числе и алгоритмами бизнес-логики. Трех-звенка придумана так же для хранения обработчиков бизнес-логики подальше от клиента и поближе к серверу БД. Сейчас сам сервер БД уже может являться полноценным сервером приложений. Зачем тягать данные между клиентом и сервером, если достаточно серверу один раз скормить логику обработки и потом только отдавать команды на уровне ПровестиДокумент ? Зачем клиенту задумываться об обеспечении логической целостности, если достаточно один раз скормить constraints на сервер?

Ферзь
То что свази между таблицами не прописаны .. так они по сути и не нужны .. потому как логика построена не в SQL а в приложении. SQL это только кеширование и хранение таблиц.
Слишком сложно будет реализовывать логику в SQL особенно с составными типами.

Зачем тогда хранить таблицы в SQL? Отдать побольше памяти под файловый кэш и оставить тот же dbf. Физическую целостность обеспечивает серверная ОС, логическую - клиент. необходимость сервера SQL в чем?
Давайте пример. Какую логику (особенно с составными типами) сложнее реализовать на 1C, чем на SQL?

пардон... конежно же "Какую логику (особенно с составными типами) сложнее реализовать на SQL, чем на 1C?"

Ферзь
Протрассируйте запрос к составным типам и увидите.
Да логика на сервере .. замечательно. ....
Как вы думаете интерпретатор запросов с 1с на SQL где находится?

В трейсы, в которых видно что 1С делает с SQL слабонервным лучше не смотреть :) Я имел ввиду логику которая у вас описана в ОбработкаПроведения() и который вы считаете трудно реализуемый на t-sql.

Сисой
А ведь это у Вас действительно каша в голове. Спор о необходимости использования ключей/констрейнтов в БД ERP-систем длится не одно десятилетие. На этом форуме пара десятков веток по данной тематике.
Вам известно, что многие КРУПНЕЙШИЕ ERP (типа Oracle EBS) не используют связки foreign key\primary key? Их, наверное, идиоты писали из фирмы Oracle, большие любители dbf.

Так вот, БД на основе dbf - самая настоящая база данных, если где-то (например, в одном из файлов) хранится словарь базы данных и перечень ключей и relations, описывающих ER-модель. И попробуйте доказать, что это не так

Ну значит каша в голове не только у меня, но и у всех кто десятилетиями спорит о необходимости использвоания ключей/констрентов в БД, когда многоие КРУПНЕЙШИЕ ERP их не используют? :)
Я знаю про эти споры и так до сих пор не понимаю зачем отказываться от этого инструмента. Только на основании того, что крупнейшие erp их не используют? Но ведь основная аргументация за отказ от проверки целостности на сервере БД - это... проверка целостности на сервере приложений, а необходимость сервера приложений - это... еще одна священная война "зачем нужны сервера приложений на современных серверах БД?". Как же тут не быть каше в голове? :)

Ферзь Егоров Александр Ферзь
Протрассируйте запрос к составным типам и увидите.
Да логика на сервере .. замечательно. ....
Как вы думаете интерпретатор запросов с 1с на SQL где находится?

В трейсы, в которых видно что 1С делает с SQL слабонервным лучше не смотреть :) Я имел ввиду логику которая у вас описана в ОбработкаПроведения() и который вы считаете трудно реализуемый на t-sql.
Ответ в моем 2 вопросе.
Я извиняюсь, но то, что я увижу в трейсе - это уже не та бизнес-логика, которую вы писали в ОбработкеПроведения(), это то, во что ее превратил интерпретатор 1С. Интерпретатор запросов 1С не в состоянии определить логику вашего запроса. С точки зрения данных, что запрос 1С, что запрос SQL не несет никакой бизнес-логики, а только команды изменения данных. Как эти изменения отражают бизнес-логику вашего приложения знаете только вы. И описываете вы эту логику алгоритмом проведения. Вы предпочитаете описывать эти алгоритмы на языке 1С, я - на языке t-sql. Это никак не влияет ни на саму бизнес-логику проведения, ни на отражение проведения документа в бизнес-процессе. Это влияет только на скорость разработки приложения (от выбора инструментов разработки) и на скорость работы приложения (от выбранных инстурментов доступа к данным). Почему-то считается что качество инструментов достпа к данным, реализованных в платформе 1С позволяет сосредотачиваться только на бизнес-логике. На практике почему-то чаще всего программисты 1С заняты борьбой с тормозами и блокировками, в том числе и за счет переписывания готовой логики на всякие 1С++ и ToySQL, и ломанием этого правильного механизма доступа к данным ради отключения табличных блокировок и верификации... Не понятно это тогда...

Сисой
В случае 1С отказ от контроля ссылочной целостности по первичному ключу вызван повсеместным использованием ссылок по recid. Ключи используются только в необъктных таблицах (регистрах).
Кроме того, используется ряд фокусов при организации распределенной БД. Например, при загрузке XML-файла с изменениями из одной БД в другую контроль целостности на уровне кода приложения ОТКЛЮЧАЕТСЯ (т.к. загружаемый объект может ссылаться на еще не загруженные в транзакции объекты). Это не есть гуд, но сделано именно так.
Кроме того, ограничения, накладываемые кодом приложения 1С на объекты БД (например, документы), иногда довольно сложны, носят нереляционный характер и в терминах стандартного Т-SQL будут занимать не одну страницу кода триггера (в 1С используются встроенные методы объектов). А если учесть, что 1С уже поддерживает 4 СУБД (включая свою файл-серверную), то проблема генерации триггеров для объектно-ориентированных или объектно-подобных мультиплатформенных ИС вызывает священный ужас разработчика (особенно если учесть часто возникающую необходимость интеграции триггеров с подсистемами задач/сообщений).
Плюс возможная несовместимость таких механизмов со следующими версиями СУБД.

Вот получется за счет универсальности доступа к данным построена модель БД, приводящая к крайне низкой производительности, но позволяющая программисту абстрагироваться от физической модели данных. Это очень хорошо, но... подвела реализация?.. Ну пускай в универсальной 1cv7s.exe не хватило сил или времени хотя бы сравнять производительность dbf и sql движка, но зачем в 8.x опять плодить один большой универсальный сервер приложений, поддерживающий 4 СУБД, включая свою собственную? Ведь опять теже грабли с производительностью в 8.0 что и были в 7.7, мучительно преодолеваемые в 8.1. Не проще ли было написать несколько вариантов серверов приложений, оптимизированных под нужную СУБД? Ведь трехзвенка и затевалась ради независимости от конкретики СУБД на стороне клиента... Есть возможность "выполнить метод на стороне сервера приложений", почему нет способа "выполнить метод на стороне сервера БД"? Вечный выбор - либо универсальность, либо скорость...

Ферзь Егоров АлександрЕсть возможность "выполнить метод на стороне сервера приложений", почему нет способа "выполнить метод на стороне сервера БД" ? Вечный выбор - либо универсальность, либо скорость...

Э что то вас понесло ..

это бывает. :) особенно когда требуется очередное многочасовое "восстановление последовательности" или "формирование внутренних продаж" и начинаешь откладывать ее до ночи или ближайших выходных... с ностальгией вспоминая самописку, в которой "последовательности" даже большего количества документов восстанавливались в течении нескольких минут. В том числе и благодаря возможности "выполнять методы на стороне сервера БД"... И не двух двухядерных ксеонах, а на обычном p-III...
Я понимаю - идеал недостижим. Но к 1С острая нелюбовь как раз по причине "ну разве можно так издеваться над sql-сервером???" А ведь сам начинал когда-то подсаживать людей на 1С именно из-за наличия готовых решений учета. Теперь у тех людей вырос документооборот и... предложить нечего. Либо монстров типа Ax\Nav\Sap, либо "кластеры северов", либо самописки...

svcoderЯ пока для себя нашел недавно только ОДНУ задачу, в которой бы мне пригодилось использовать foreign key constraint. Это замена дублей контрагентов.
Сразу хочется спросить, а разве нельзя заранее обеспечить уникальность справочника контрагенты? Если вы говорите, что логическая целостность базы - задача клиента, значит ваш клиент плохо написан, раз допускает дубляжи уникальных значений? Соответственно никакой гарантии логической целостности клиент не дает и даже помощи в этом не оказывает? в отличии от unique constraint по нескольким полям?