AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.04.2008, 14:55   #1  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
к вопросу о хранении файлов в БД
Таблица DocuValue, настройка в типе документа "Хранение файлов" — "База данных". Размер таблицы — гигабайт этак 15. На таблице есть поле Name c EDT Description StringSize 100. Меняем stringsize на 150. Запускается синхронизация данных часа этак на три. Так стоит ли хранить файлы в БД?
Старый 03.04.2008, 15:11   #2  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
В зависимости....

1. Каков размер всей базы? То есть, 15 Гб - это сколько в процентах?
2. Как часто вы меняете в ней размеры столбцов?
3. Данную таблицу можно вынести в отдельный tablespace (oracle) / группу файлов (ms sql)

При всех минусах хранения файлов в СУБД есть один большой плюс, который на практике часто перевешивает - администратором не надо заботиться о согласованности бекапов СУБД и файл-сервера.
Старый 03.04.2008, 16:09   #3  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
1) В процентах это 50.
2) Я менял не в ней, а изменил расширенный тип данных, это же огромный плюс к удобству системы
Старый 03.04.2008, 16:17   #4  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Ну, значит это поле надо перевесить на отдельный тип. Я в таких случаях делаю вообще табличку из двух полей - короткий int идентификатор и поле с файлом. Остальные таблицы ссылаются на него.
Старый 03.04.2008, 16:27   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от NetBus Посмотреть сообщение
На таблице есть поле Name c EDT Description StringSize 100. Меняем stringsize на 150. Запускается синхронизация данных часа этак на три.
Цитата:
Сообщение от NetBus Посмотреть сообщение
2) Я менял не в ней, а изменил расширенный тип данных, это же огромный плюс к удобству системы
Дык, такая синхронизация изменяет все таблицы и индексы, где есть поля с таким типом. Поэтому и долго.
__________________
полезное на axForum, github, vk, coub.
Старый 03.04.2008, 16:30   #6  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Дык, такая синхронизация изменяет все таблицы и индексы, где есть поля с таким типом. Поэтому и долго.
Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь
Старый 03.04.2008, 17:03   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от NetBus Посмотреть сообщение
Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь
А опыт специалистов показывает, что можно менять EDT и на 40Гб с живой базой.
__________________
полезное на axForum, github, vk, coub.
Старый 03.04.2008, 17:11   #8  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
И даже если изменяемый EDT входит в таблицу весом несколько гигов?
Старый 03.04.2008, 17:13   #9  
ZVV is offline
ZVV
MCITP
MCP
Oracle
MCBMSS
 
1,006 / 246 (11) ++++++
Регистрация: 13.02.2004
Адрес: Минск
->
А о чём вы вообще спорите?

Нет никакого противоречия. Да, можно менять размер ЕДТ. Это повлечёт увеличения столбца во всех таблицах, где есть такие поля. Всё правильно. И да, на описанной таблице она (синхронизация) действительно будет очень долго выполняться.

Отличный выход предложил выше Андре. Единственный минус: об этом надо было задуматься раньше. Счас переделывать будет всё равно долго по тем же причинам (перестройка таблицы в БД).

Конкретно в этой ситуации остаётся только ждать окончания синхронизации... Запастись интересными играми, сходить погулять там..
__________________
Zhirenkov Vitaly
Старый 03.04.2008, 17:31   #10  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от NetBus Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
Цитата:
Сообщение от NetBus Посмотреть сообщение
Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь
А опыт специалистов показывает, что можно менять EDT и на 40Гб с живой базой.
И даже если изменяемый EDT входит в таблицу весом несколько гигов?
Дело, мне кажется, не в том, сколько занимает таблица (бывало и побольше, правда, на других системах ), а в том, что в ней присутствуют BLOB-поля. Тот же Oracle такие таблицы обрабатывает по одной записи, что, разумеется, не может не сказаться на производительности. Единственный выход тут - реорганизовывать таблицу, как уже указал Андре.
Старый 03.04.2008, 17:34   #11  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Ок, спасибо всем за участие. Ситуация прояснилась, про это зло надо знать и уметь обходить.
Старый 03.04.2008, 18:15   #12  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,941 / 3229 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Я думаю проблема еще в том, что при изменении длины EDT - Аксапта выполняет запрос Insert into Select From т.е. фактически создается новая таблица, в которую перекачиваются данные - все 15 гигов.

Плюс как заметил Gl00my процедура перекачки замедляется еще из-за того что есть блобы.

Я думаю можно попробовать изменить длину поля средствами БД через Alter Table. - Тогда удается избежать тормозной перекачки данных. Правда если там стоит выравнивание по правому краю, то лучше поля повторно джобом перепрописать, чтобы другое число ведущих пробелов прописалось во всем столбце.
Ну и не забыть скорректировать сведения о длине поля в таблице SQLDictionary - на всякий пожарный.
За это сообщение автора поблагодарили: NetBus (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Подключение АОС к новой БД AxaptaUser DAX: Администрирование 4 07.04.2008 16:09
Ошибки в отчете о статусе БД, Не совсем понятный отчет. Помогите разобраться. Poleax DAX: Администрирование 7 21.08.2007 12:23
Владельцы таблиц в БД аксапты AxaptaUser DAX: Администрирование 11 23.05.2007 18:33
2 AOS + 2 БД = 1 сервер renat DAX: Администрирование 2 22.07.2003 09:20
Создание точной копии БД для анализа ошибок Maxim Gorbunov DAX: База знаний и проекты 1 18.12.2001 15:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:21.