Публикация

Приветствую, уважаемые коллеги!

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

Сегодня я расскажу Вам о преимуществах и выгодах использования приложения для оперативной проверки структуры базы данных (далее - БД) на корректность (https://marketplace.terrasoft.ru/app/database-structure-check).

Проблематика.

После накатывания нового функционала на тестовую среду могут появиться ошибки структуры БД. Их особенности:

  • не всегда очевидны.
  • разработчиков может сбивать с толку тот факт, что на рабочей среде всё работает, а на тестовой – нет.
  • поиск и устранение может занять длительное время.

Всё это снижает эффективность разработки/обслуживания, приводит к дополнительным расходам ресурсов. 

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

  • падает надёжность системы.
  • повышается вероятность аварии.

Особенно это актуально, когда «окно» для обновления промышленной среды очень небольшое. Чем больше проект в плане доработок, тем больше ошибок структуры БД может возникать.

При использовании приложения все эти проблемы можно успешно решить!

Целевая аудитория.

Обращаю внимание партнёров Terrasoft: приложение предназначено для среднего и крупного бизнеса. То есть, основные преимущества от его использования получает именно клиент. Приложение универсально и подойдёт практически всем клиентам, у которых есть потребность в доработке базовых продуктов.

Степень необходимости приложения может варьироваться. Если в ходе выяснения потребностей выясняется, что:

  1. будет большой проект (или уже есть) со сложными связями между сущностями системы.
  2. есть потребность в максимальной надёжности.
  3. у клиента только небольшие «окна» для обновления промышленной среды.
  4. есть потребность в повышении эффективности разработки и обслуживания (клиент хочет как можно скорее получить готовую систему в пользование).
  5. есть потребность в повышении устойчивости к авариям системы.

- это всё покажет рост степени необходимости приложения. Я настоятельно рекомендую устанавливать приложение всем клиентам в случае, если имеет место хотя бы один пункт выше.

Выгоды.

Какие выгоды получит клиент от использования приложения? Как правило, это выгоды в долгосрочной перспективе. Клиент:

  1. получит дополнительную меру повышения надёжности системы.
  2. сэкономит ресурсы на обнаружение ошибок структуры БД.
  3. обеспечит повышение эффективности разработки и обслуживания системы.
  4. обеспечит повышение устойчивости системы к авариям из-за ошибок структуры БД.

Есть также выгоды для разработчиков, облегчающие некоторые аспекты разработки/сопровождения. Разработчики: 

  1. смогут пользоваться самым рациональным решением для проверок структуры БД, которое не имеет аналогов.
  2. смогут пользоваться всем функционалом приложения в один клик.
  3. смогут проверять структуру БД на корректность в течение нескольких секунд.
  4. смогут оперативно выявлять отсутствующие таблицы и/или их колонки, обнаруживать несоответствия типов полей.
  5. после проверки структуры БД смогут понять, для каких объектов необходимо произвести повторное обновление структуры БД.
  6. после успешного анализа, будут точно знать, что БД целевой среды содержит все требуемые системой таблицы/поля, и что типы всех полей всех таблиц правильные.

Преимущества.

  1. Поиск ошибок структуры БД. Приложение выявляет отсутствующие таблицы и/или их колонки, а также обнаруживает несоответствия типов полей.
  2. Повышение надёжности. Использование приложения повышает надёжность системы за счёт минимизации времени, в течение которого в структуре БД есть ошибки.
  3. Экономия ресурсов. Использование дополнения сокращает расходы на обнаружение ошибок структуры БД. В ряде случаев очень серьёзно сокращает расходы.
  4. Подтверждение целостности. После успешного анализа, специалист будет точно знать, что база данных целевой среды содержит все требуемые системой таблицы/поля, и что типы всех полей всех таблиц соответствуют требуемым типам.
  5. Повышение эффективности разработки и обслуживания. Это происходит за счёт экономии ресурсов при использовании приложения, а также за счёт ускорения обнаружения ошибок структуры БД.
  6. Простота использования. Запуск функционала в один клик.
  7. Быстрая скорость работы. Проверка структуры БД в течении нескольких секунд.
  8. Простая и удобная форма отчёта приложения. После проверки, в случае наличия ошибок, специалисту будет предоставлено подробное информационное сообщение. Разработчик сразу поймёт, для каких объектов необходимо произвести повторное обновление структуры БД.
  9. Локализация на английский язык. Поддержка не только русского языка, но и английского.
  10. Самое рациональное решение для проверок структуры БД. На самом деле, можно проверить вручную, но это дольше (просмотреть все разделы, вкладки, детали, а также проверить работоспособность всего разработанного функционала) и не всегда возможно проверить вообще всё. Зачастую такого количества времени просто нет. 
  11. Уникальность. Инструмент для проверки структуры БД не имеет аналогов на маркетплейс.
  12. Смешная цена. За год использования, то есть возможно продление на следующий год. Продлевать нет смысла только если разработка/обслуживание полностью завершены. Экспертные продажи.
  13. Повышение устойчивости системы к авариям, вызванным ошибками структуры БД. Использование приложения позволяет обнаружить ошибки БД сразу же после обновления целевой среды, после чего сразу предпринять действия для исправления найденных ошибок.

Совместимость.

Приложение совместимо со всеми продуктами на платформе bpm’online (с версии 7.11, на остальных нужно тестировать, но скорее всего работать будет).
В данный момент не поддерживается работа на системах, для которых используется СУБД Oracle.

Большое спасибо всем, кто дочитал до конца!

Буду рад любым предложениям по совершенствованию продукта!

С уважением, Сергей Кузнецов.

Поделиться

1 комментарий

yes

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

В какой то момент пропали настройки журнала изменений по контакту.
Как можно отследить изменение настроек аудита? Кто, когда?

У меня такой же вопрос

4 комментария

Егор, добрый день!

Обычно такие задачи решаются с помощью самого журнала аудита (не журнала изменений). Но сейчас в системе не логируется изменение настроек журнала изменений (я создала соответствующую идею в беклоге профильной команды). Список логируемых операций можно посмотреть тут: https://academy.terrasoft.ru/documents/studio/7-12/razdel-zhurnal-audita

В качестве обходного решения можно сделать следуюшее:

1. Для анализа текущей ситуации проанализировать логи приложения (там должны быть видны соответсвующие запросы) и сравнить с данными по сессиям пользователей.

2. На будущее реализовать собственный тригер на уровне БД, который будет писать в лог, если кто-то будет менять настройки журнала изменений.

Старун Юлия,
спасибо за развернутый ответ!

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

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

        {
          "UId": "736c30a7-c0ec-4fa9-b034-2552b319b633",
          "Name": "Name",
          "CreatedInSchemaUId": "11ab4bcb-9b23-4b6d-9c86-520fae925d75",
          "ModifiedInSchemaUId": "4cbdc6f3-625d-4639-92bf-bb19d4c9d58e",
          "CreatedInPackageId": "66e9e705-64b4-4dda-925e-d1e05a389eb6",
          "DataValueTypeUId": "ddb3a1ee-07e8-4d62-b7a9-d0e618b00fbd",
          "RequirementType": 1,
          "IsTrackChangesInDB": true,
          "IsLocalizable": true
        },

Но вот на уровне базы данных это уже хранится в колонке MetaData таблицы SysSchema в не таком удобном виде. Там следует искать код Е16, чтобы понять, колонка с каким UID логируется:

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

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

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

Добрый день, коллеги!
Есть разработческая площадка, развернутая на БД клиента с неактуальными данными, на ней ведутся все доработки в свой пакет и фиксируются в хранилище. Также есть "пустая" продуктивная площадка, на которую все изменения применяются. Кроме того, необходимо настроить права доступа, интеграцию с АД, прописать орг структуру. После окончания всех работ нужно перенести все изменения на актуальную базу клиента. Все доработки перенести с помощью хранилища не проблема, но права доступа, интеграция с АД, пользователи, орг структура, настройки почтового ящика хранятся в БД. Поэтому при переносе эти настройки можно потерять. В связи с этим вопрос: есть ли способ переноса данных с одной базы на другую?

У меня такой же вопрос

2 комментария

Добрый день, Елена.

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

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

Перенос настроек интеграции с LDAP также приведет к тому, что синхронизация не будет запущена.

В данной ситуации правильно будет выполнить все настройки вручную на актуальной БД.

"Мария Ватулина" написал:

Добрый день, Елена.

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

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

Перенос настроек интеграции с LDAP также приведет к тому, что синхронизация не будет запущена.

В данной ситуации правильно будет выполнить все настройки вручную на актуальной БД.


Мария, спасибо за ответ!

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

Здравствуйте!

Подскажите, как можно осуществить проверку наличия таблиц и их колонок БД по именам, используя EntitySchemaManager в веб-сервисе? Чтобы проверить перед внесением изменений в БД.

У меня такой же вопрос

2 комментария

В Terrasoft 3.Х нет механизма EntitySchemaManager. Там всё устроено иначе.

"Зверев Александр" написал:

В Terrasoft 3.Х нет механизма EntitySchemaManager. Там всё устроено иначе.


Понял. Спасибо.

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

Добрый день.
Подскажите за счет чего увеличивается обьем базы данных? База Террасофта находится на отдельном сервере и весит на сегодня порядка 100ГБ.
Версия террасофта - 3.3.1.148
БД - Файерберд
Заранее спасибо, за помощь.

У меня такой же вопрос

2 комментария

Часто это случается из-за пустого места в таблицах. Необходимо проводить переиндексацию таблиц и выполнять операцию srink на базе SQL. Я так добилась двукратного уменьшения базы.
Как все это правильнее сделать , Вам подробнее может помочь техподдежка.

Кроме этого у меня в базе зависали неудаленные файлы (после того, как объект к которому они были привязаны, удалялись сами файлы из базы не удалялись). Это я вычищала скриптами.

"Бучковский" написал:Подскажите за счет чего увеличивается обьем базы данных

Смотрите размеры таблицы tbl_MailMessages и tbl_Files
Если пользоваться ibexpert, то это меню Services-Database Statistics.
Основной рост базы данных за счет прикрепления писем и хранения файлов в базе данных.

Плюс, как написала Виктория, из-за пустого места в таблицах - подробнее здесь

"Тихенко Виктория" написал:выполнять операцию srink на базе SQL

Для firebird операция shrink не существует. Делается бэкап базы и ее восстановление. В результате свободное место будет реорганизовано.

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

В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.

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

В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица WindowLog, а вторая TriggerLog.

Первая таблица WindowLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Ответственный» (WindowsUser), «Имя поля породившего событие»(FieldName), «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для наполнения таблицы было использованы события невизуального компонента окна dlData: dlDataOnDatasetDataChange, dlDataOnDatasetBeforePost и dlDataOnDatasetAfterPost. В скрипте в событиях была создана функция, которая формировала SQL запрос к таблице WindowLog базы данных с фиксацией информации по указанным полям на момент срабатывания события.

Запрос:

INSERT INTO WindowLog (*набор полей*)
SELECT (*набор полей*) -- Dataset('поле1'), Dataset('поле2'), Dataset('поле2')

Вторая таблица TriggerLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Состояние» (до изменения записи и после), «SystemUser», «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для заполнения данной таблицы был создан триггер на инструкцию UPDATE проблемной таблицы с двумя запросами вставки значений в таблицу. В одном запросе вставлялись значения до изменений, а во втором после.

Запрос №1:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM deleted

Запрос №2:

INSERT INTO TriggerLog (*набор полей*)       
SELECT (*набор полей*)
FROM inserted

Результатом использования данного решения на основе анализа таблицы WindowLog было установлено, что срабатывают все события окна редактирования, влияющие на вычисление значения поля «Итого». В процессе использования окна редактирования и после сохранения записи значения поля «Итого» были корректны.

Проанализировав записи в таблице TriggerLog было установлено, что в результате выполнения инструкции UPDATE было внесено некорректное значение. Сопоставив даты создания записей в таблице TriggerLog и WindowLog было установлено, что инструкция UPDATE была вызвана не в результате манипуляций с окном редактирования, а иным источником. На основании поля «SystemUser» таблицы TriggerLog было установлено что изменения были внесены с помощью импортера данных.

Таблицу TriggerLog возможно расширить, добавив в нее поля, которые помогут ускорить процесс обнаружение источника изменений записи базы данных. Список дополнительных полей может выгладять следующим образом: ApplicationName, LoginName, HostName.

PS: Принимаю предложения на доработку вашей конфигурации!!! Для более детальной информации можно связаться по следующему e-mail адресу: providnui@ukr.net !!!

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

Всем удачи в этом не легком процессе!!!

У меня такой же вопрос

0 комментариев
Войдите или зарегистрируйтесь, чтобы комментировать
Публикация

Многие из нас пользуются бесплатными версиями MS SQL Server, которые, как вы понимаете, имеют ограничение на размер базы данных.
Рано или поздно, у Вас появится сообщение примерно такого характера :

ошибка сохранения

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

Для того, чтоб определить сколько места занимает каждая из таблиц базы данных вы можете использовать скрипт :

/*
** For update free space uncomment follow --, N'TRUE'
*/


SET nocount ON

IF NOT object_id('tempdb..[#space]') IS NULL DROP TABLE [#space]

declare @TABLE [sysname]

CREATE TABLE [#space] (
        [name] [nvarchar](128),
        [rows] [char](11),
        [rows_int] [int],
        [reserved] [varchar](18),
        [DATA] [varchar](18),
        [data_int] [int],
        [index_size] [varchar](18),
        [unused] [varchar](18),
        [unused_int] [int]
)

declare [c] cursor FOR
SELECT name
FROM sysobjects
WHERE type = N'U'
ORDER BY name

open [c]

while (1 = 1)
begin
        fetch next FROM [c] INTO @TABLE
       
        IF @@fetch_status = -1 break
        IF @@fetch_status = -2 continue

        INSERT INTO [#space] ([name], [rows], [reserved], [DATA], [index_size], [unused])
        exec sp_spaceused @TABLE , N'TRUE'
end

close [c]
deallocate [c]

UPDATE [#space]
SET [data_int] = cast(REPLACE([DATA], N' KB', N'') AS [int]),
[unused_int] = cast(REPLACE([unused], N' KB', N'') AS [int]),
[rows_int] = cast([rows] AS [int])

SELECT * FROM [#space]
ORDER BY --rows_int desc
[data_int] DESC

SELECT cast(sum([unused_int]) AS varchar) + ' KB' AS [unused] FROM [#space]

Обращаю ваше внимание, что скрипт дает информацию о занимаемом месте каждой таблицей в базе данных, но не избавляет вас от оповещения, которое показано выше.
Действия, которые вы будете принимать далее, зависят только от вас, одним из вариантов есть заказ лицензий на использование MS SQL Server.

Поделиться

1 комментарий

Я бы еще советовал обращать внимание на колонку index_size - т.к. нередко индексы занимает львиную часть места в БД.

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

Коллеги, добрый день!

Вопрос: есть ли какая-то объективная причина того, что в БД террасофта ни в одной таблице абсолютно не используются кластерные индексы?

У нас система еле шевелится, при том что очень мощный сервер БД, всего около 150 пользователей, таблицы не сказать что очень огромные (десятки-сотни тыс. записей)... кроме таблиц логов (миллионы-десятки миллионов записей) :)
В общем производительность очень низкая.

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

Спасибо!

У меня такой же вопрос

9 комментариев

Здравствуйте,
Так сложилось исторически, что для для MSSQL 2000 в общем случае некластерный индекс является оптимальным, так как в Terraosft 3.X для первичных ключей и внешних ключей используются GUID. В этом случае, если включить кластерные индексы, они будут постоянно перестраиваться, т.к. при вставке записей мы всегда получаем случайное значение GUID и для сохранения упорядоченного вида, новую запись нужно вставить в середину индекса.

Для MSSQL 2008, при использовании последовательных GUID, кластерный индекс будет более производительным. В новых версиях мы проанализируем возможность использования таких индексов для MSSQL 2008.

Алексей,

А как на счет использования "разреженных" индексов, в которых FillFactor < 100 (например 60-80)?

Или использование NEWSEQUENTIALID() вместо NEWID()?

Или введения кластерного индекса не связанного с первичным ключем (например, введение поля типа BigInt с автоинкрементом, либо выделение группы полей по которым возможно построить уникальный индекс, например для контрагента - дата создания, наименование, + может быть ИНН, ОГРН)?

Не проводились ли исследования в этой области? Перед тем как начать самому исследование, хотелось бы услышать какие-то рекомендации, наработки, если таковые имеются.

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

Тут же возможно возникнут вопросы по сбору статистики для полей как входящих в индексы так и не входящих в них.

Здравствуйте,
1) Генерация самих GUID в Terrasoft 3.X происходит на уровне приложения (используется внутренний генератор Connector.GenGUID()), это дает возможность использовать значения идентификаторов, до их фактической вставки в таблицу, для того что бы использовать последовательную генерацию идентификаторов, необходимо править бинарные файлы, и менять логику построения на генерацию последовательных идентификаторов.

2) Если Вы имеете в виду, замену uniqueidentifier на BigInt, в Terrasoft в качестве первичных ключей, то боюсь Вас разочаровать, многие вещи в конфигурации заточены под использования типа GUID.
В качестве оптимизации вы можете построить группы полей, по которым чаще всего проводиться фильтрация/поиск, и создать кластерный индекс, это действительно может повысить производительность
Последовательные GUID в нашем случае также противоречат репликации – т.к. ключи могут повторяться.

Для начала следует оптимизировать запросы, с которыми в Вашей компании наиболее часто работают.
Для этого выловите сам запрос который идет в БД, SQL Profiler’ом и дальше работу стоит вести по плану выполнения (http://www.mssqltips.com/sqlservertip/1856/sql-server-query-execution-p…)
1

Рассмотрение возможностей оптимизации коробочного продукта, с учетом возможностей SQL Server 2008, запланировано на следующую неделю.

Спасибо, Алексей.

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

"Яворский Алексей" написал: Яворский Алексей 2 апреля 2012 – 15:48

Здравствуйте,
Так сложилось исторически, что для для MSSQL 2000 в общем случае некластерный индекс является оптимальным, так как в Terraosft 3.X для первичных ключей и внешних ключей используются GUID. В этом случае, если включить кластерные индексы, они будут постоянно перестраиваться, т.к. при вставке записей мы всегда получаем случайное значение GUID и для сохранения упорядоченного вида, новую запись нужно вставить в середину индекса.

Тоесть Вы хотите сказать, что Table Scan будет быстрее работать на наблице в 50к записей, чем Clustered Index Scan???

И что RID Lookup работает быстрее, чем Key lookup при использовании индексов???

И таблица с Identity колонкой и кластерным индексом по ней и Nonclustered Primary Key будет работать медленней, чем таблица без кластерного идекса???

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

Универсальное решение тяжело найти, с учетом того что система работает и под FB и Oracle. Не всегда большое кол-во индексов способствует повышению производительности, иногда производительность резко падает из-за переизбытка индексов. Если вы используете MS SQL 2008, то в нем есть хороший инструмент под названием "Мониторинг ресурсов". Он Вам покажет что происходит с диком, процессором и какие тяжелые запросы. На комьюнити выкладывались так же запросы по рекомендациям использования индексов (какие лишниеи каких не хватает). Так же не забывайте каждый день (точнее ночь) перестраивать индексы, чистить кэш (SQL-ный) и собирать статистику.

Евгений, я знаю, что избыток индексов - тоже плохо, я также знаю, что GUID в качестве кластерного индекса тоже плохо, т.к. он быстро фрагментируется.
Я также понимаю, что GUIDы удобнее для разработчиков.
Про мониторинг ресурсов, профайлер, чистку кэша, обновление статистик и др тоже хорошо знаю.
В оптимизации запросов тоже не новичок...

Если вы мне покажете хоть один(!) запрос из нескольких таблиц где записей больше 100 и он будет работать быстрее без кластерных индексов (конечно не по гуиду) я успокоюсь :smile:

Михаил, я не в коем случае не хотел Вас уличить в некомпетентности. Просто я сейчас поддерживаю две крупные базы, каждая из которых примерно 60 Гб. Одна на Oracle, вторая на MS SQL 2008R2. Ни на одной нет кластерных индексов, это не заслуга, просто так исторически сложилось. Сервера работаю в штатном режиме и не особо напрягаются (я не имею ввиду те ситуации когда процесятся OLAP кубы :lol:, но это не часто и не долго). Так вот, основные тормоза идут на конечных рабочих местах при открытии разделов и экранных форм, т.к. ОЧЕНЬ много логики и ОЧЕНЬ много полей, что очень сильно замедляет билдинг и рендеринг клиентского приложения в целом.

"Домброва Михаил" написал:Если вы мне покажете хоть один(!) запрос из нескольких таблиц где записей больше 100 и он будет работать быстрее без кластерных индексов (конечно не по гуиду) я успокоюсь

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

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

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

У меня такой же вопрос

10 комментариев

Здравствуйте, Вениамин.

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

Инна Безверхняя,
II линия службы поддержки Terrasoft

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

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

- Detail
Здесь хранятся все сервисы, связанные с деталями раздела
- Dictionaries
Здесь хранятся все сервисы, связанные со справочниками раздела
- General
Здесь находятся сервисы, которые отвечают за отображения основного реестра записей раздела
- Graphs - графики
- Library - библиотека специфичных для этого раздела сервисов
- Reports - различные сервисы, связанные с отчетами FastReport
- User Fields - сервисы, связанные с пользовательскими полями

После того, как вы нашли сервис нужной вам таблицы, открываете этот сервис и слева вы увидите список полей таблицы:

Я могу в чем-то ошибаться, но общее представление у меня такое.

Андрей, огромноее спасибо. Действительно, все более-менее понятно.

Здравствуйте, Андрей!
Спасибо за Ваш ответ, да, в целом все верно.

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

То есть, для каждого раздела есть основная таблица, на примере раздела "Контрагенты" - tbl_Account, далее, вся связанная информация, которая заносится через детали этого раздела хранится в таблицах, которые начинаются с названия раздела + название детали, то есть tbl_AccountAddressess - адреса контрагентов, tbl_AccountCommunications - средства связи контрагентов и т.д., аналогично справочная информация по данному разделу tbl_AccountType - типы контрагентов и т.д.
По тому же принципу хранится информация о группах записей и правах доступа к записям: tbl_AccountGroup и tbl_AccountRight.

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

Это в общих чертах, подробнее будем рады ответить на более конкретные вопросы.

Инна Безверхняя,
II линия службы поддержки Terrasoft

Инна, отличное дополнение! Картинка постепенно прорисовывается. Спасибо :)

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

А вот по какому принципу хранится информация в табличке tbl_Service ? Особенно блоб "XMLData".
В каком виде хранятся тексты "сервисов" ? Ну точно не в виде чистого XML.

Здравствуйте Сергей,
При записи в таблицу tbl_Service, сам сарвис сериализируется, подробнее вы можете почитать в теме http://www.community.terrasoft.ru/forum/topic/6829

"Яворский Алексей" написал:
При записи в таблицу tbl_Service, сам сарвис сериализируется, подробнее вы можете почитать в теме http://www.community.terrasoft.ru/forum/topic/6829

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

Вопрос простой - как просмотреть/отредактировать модуль (сервис) во внешнем приложении имея доступ к БД? IBExpert воспринимает обсуждаемый BLOB как двоичный (это естественно при неизвестной структуре).

Здравствуйте Сергей,

Для редактирование сервиса из БД необходимо:
1.Получить значение BLOB-поля
2.Разархировать его – получится XML сервиса
3.Редактировать текст XML
4.Заархивировать
5.Записать заархивированный XML в то же поле

Но редактирование XML на прямую может повлечь ошибки. Если сервис неправильно отредактирован и записан в БД, он станет недоступным для редактирования в TSAdmin и для использования в TSClient, т.к. он не сможет правильно дисериализироваться.

Для решения Вашей задачи лучше работать с сервисами через COM-объекты Terrasoft из любого внешнего приложения:
1.Например, запросить сервис sq_Contact (Services.GetNewItemByUSI)
2.Модифицировать его как угодно, добавлять колонки, фильтры, union’ы и т.д. – это минимизирует ошибки, т.к. COM-объекты Terraosft делают проверку возможности тех или иных изменений. А работа напрямую с текстом XML ничего не проверяет
3.И после модификаций сохранить Services.SaveItem(Service, sdoaSave) в БД

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

Приветствую! Есть необходимость получить описание структуры базы данных и таблиц Terrasoft CRM 3.3.2.

Поделиться

5 комментариев

Здравствуйте.
На текущий момент готового руководства с описанием структуры базы данных и таблиц Terrasoft CRM 3.3.2 нет. Но если у Вас есть конкретные вопросы - задавайте и мы в рамках технической поддержки Вам ответим.
Terrasoft Support Team.

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

"OlegLeko" написал:Жаль что нет, как же вы тогда разработку вели, если не знаешь где и какая таблица в базе?

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

"OlegLeko" написал:Жаль что нет, как же вы тогда разработку вели, если не знаешь где и какая таблица в базе?

Даже без опыта, структура самой базы данных очень проста и прозрачна.

Ну это вопрос другой, было бы проще получить описание.. У меня пользователи как бы должны сами научиться пользоваться CRM - там ведь все просто ;) - приходиться писать краткие мануалы по той или иной задаче.

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