Уже для многих не секрет что внутренняя структура 1С представляет из себя набор двоичных данных. Для того что бы загрузка 1С не занимала по полчаса при каждом запуске эти данные читаются разумеется не все сразу, а определенными порциями. Поэтому они разделены на безумное количество частей, чем больше объектов в конфигурации тем этих частей больше например в УПП (самой большой конфигурации) их ~ 22000. Но сейчас я расскажу об основных их них.
Всегда есть запись root, как же без нее) она сама главная, и как обычно это бывает - самая бестолковая. Выглядит примерно так
Вот примерно так они выглядят в Ei
Ранее я писал о том что из себя представляет структура реквизита объекта, но сейчас не об этом важно запомнить что у каждого реквизита объекта так же есть свой идентификатор, 7b505d9b-1a90-41fa-8cb3-1d2420533295 у реквизита ДатаНачала.
Где же еще используется этот идентификатор и как он связан со структурой таблиц базы данных? И вот теперь мы переходим действительно к самой главной записи DBNames из служебной таблицы Params.
Многие из вас спросят "Не слишком ли сложно?", но зная "нашего брата" большинство подумает "Вот они ....ны я бы все сделал гораздо проще >:["
И действительно до 2007 (8.1) было по другому, вместо всех выше описанных записей за исключением DBNames был одна запись с характерным именем metadata, в этой записи были перечислены все объекты конфигурации и их метаданные.
И почему все изменилось?
Файл metadata каждый клиент при запуске 1С должен был скачивать с СУБД и разбирать, в данном случае чем больше была конфигурация (объектов и реквизитов) тем больше времени требовалось на ее открытие и "поломка" любого объекта приводила к "параличу" всей конфигурации.
Вы наверно заметили что первое открытие любой базы данных требует больше времени чем обычно. Это происходит потому что 1С при первом открытии конфигурации формирует на локальном компьютере кеш метаданных (все объекты с их реквизитами) что в принципе равносильно старой структуре (metadata). При последующих запусках 1С читает только метаданные измененных объектов относительно кеша, при старой структуре никакого выигрыша это не дало поскольку разбирать все метаданные пришлось бы снова, файл то был один.
Кстати изменения метаданных фиксируются в записи versions, но это уже совсем другая история
Приятных вам сновидений.
Всегда есть запись root, как же без нее) она сама главная, и как обычно это бывает - самая бестолковая. Выглядит примерно так
{2,ada14b12-452d-4f85-9d71-99554e8fc6c0Идентификатор указанный в самом верху указывает на запись в которой перечислены все идентификаторы объектов, просто разбитые на группы и перечислены.
,twthcp1MHMXJpJNq3Y1lbwXjJkNVD1CBaj5Yqn5y3zEJ1tAXJJ5Ka5GgKhC33jAS
3ij7ZDeIHkda66+vtKusT8/N/f7knxo2nX89Y1hROPg9Ju5XoONUnbHNAXIYvp0x
aPiD1rZZfjJ8w7NPHJnhSJ/Scyl/pg+u8vlxVQuv8tNA7XwVEdISe0vBx00+JQk3
zyzPX+lLif0Phn98XxzmOnAQXPzXQ3f8lp8lZgVm15c=}
...
{0,0,79db8f22-3f2f-4a5c-ad3b-b92e0a1e420e},46ae0c8e-be8a-4a3c-9c6e-ab67ff3017ac},15,..
{0195e80c-b157-11d4-9435-004095e12fc7,141,b1b5d925-aa34-4477-bb6b-43ab5a2bb8a4,64f66..
{061d872a-5787-460e-95ac-ed74ea3a3e84,348,fd344322-5ce0-4570-aca8-772b0ac28ada,694bb0f...
...
В Ei эту запись можно открыть через
вот так например перечислены документы, если мы возьмем запись любого идентификатора например первого документа ABC-классификация покупателей то там мы уже обнаружим метаданные самого объекта.Вот примерно так они выглядят в Ei
Ранее я писал о том что из себя представляет структура реквизита объекта, но сейчас не об этом важно запомнить что у каждого реквизита объекта так же есть свой идентификатор, 7b505d9b-1a90-41fa-8cb3-1d2420533295 у реквизита ДатаНачала.
Где же еще используется этот идентификатор и как он связан со структурой таблиц базы данных? И вот теперь мы переходим действительно к самой главной записи DBNames из служебной таблицы Params.
....
{fd344322-5ce0-4570-aca8-772b0ac28ada,"Document",374},
{18723ea9-3d35-4241-88e9-0ad4f7ea7045,"DocumentChngR",8201},
{e530fa0a-d463-460d-a18a-3880a25e157f,"Fld",18574},
{959743fc-4ae8-4107-82eb-8d7b10168b77,"Fld",7310},
{baaff48a-da25-4f19-bc6a-2e02f4bc376d,"Fld",9078},
{7b505d9b-1a90-41fa-8cb3-1d2420533295,"Fld",2279},
{9fff3b6d-d36d-4c21-9c0e-a70874538541,"Fld",4724},
{6f83e71b-7439-4e2b-9962-e7111f4d4716,"Fld",14963},
{0e5614b5-05a2-40d2-afe8-19c0decc39d3,"Fld",13015},
....
В Ei эту запись можно открыть через
Зная правила именования документов мы можем сделать вывод что документ ABC-классификация покупателей расположен в таблице _Document374, а реквизит ДатаНачала в колонке _Fld2279 этой таблицы.Многие из вас спросят "Не слишком ли сложно?", но зная "нашего брата" большинство подумает "Вот они ....ны я бы все сделал гораздо проще >:["
И действительно до 2007 (8.1) было по другому, вместо всех выше описанных записей за исключением DBNames был одна запись с характерным именем metadata, в этой записи были перечислены все объекты конфигурации и их метаданные.
И почему все изменилось?
Файл metadata каждый клиент при запуске 1С должен был скачивать с СУБД и разбирать, в данном случае чем больше была конфигурация (объектов и реквизитов) тем больше времени требовалось на ее открытие и "поломка" любого объекта приводила к "параличу" всей конфигурации.
Вы наверно заметили что первое открытие любой базы данных требует больше времени чем обычно. Это происходит потому что 1С при первом открытии конфигурации формирует на локальном компьютере кеш метаданных (все объекты с их реквизитами) что в принципе равносильно старой структуре (metadata). При последующих запусках 1С читает только метаданные измененных объектов относительно кеша, при старой структуре никакого выигрыша это не дало поскольку разбирать все метаданные пришлось бы снова, файл то был один.
Кстати изменения метаданных фиксируются в записи versions, но это уже совсем другая история
Приятных вам сновидений.
Комментариев нет:
Отправить комментарий