к вопросу о хранении файлов в БД

[NetBus]

Таблица DocuValue, настройка в типе документа "Хранение файлов" — "База данных". Размер таблицы — гигабайт этак 15. На таблице есть поле Name c EDT Description StringSize 100. Меняем stringsize на 150. Запускается синхронизация данных часа этак на три. Так стоит ли хранить файлы в БД?

[Андре]

В зависимости....

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

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

[NetBus]

1) В процентах это 50.
2) Я менял не в ней, а изменил расширенный тип данных, это же огромный плюс к удобству системы

[Андре]

Ну, значит это поле надо перевесить на отдельный тип. Я в таких случаях делаю вообще табличку из двух полей - короткий int идентификатор и поле с файлом. Остальные таблицы ссылаются на него.

[mazzy]

Цитата:

Сообщение от NetBus

На таблице есть поле Name c EDT Description StringSize 100. Меняем stringsize на 150. Запускается синхронизация данных часа этак на три.

Цитата:

Сообщение от NetBus

2) Я менял не в ней, а изменил расширенный тип данных, это же огромный плюс к удобству системы

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

[NetBus]

Цитата:

Сообщение от mazzy

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

Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь

[mazzy]

Цитата:

Сообщение от NetBus

Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь

А опыт специалистов показывает, что можно менять EDT и на 40Гб с живой базой.

[NetBus]

И даже если изменяемый EDT входит в таблицу весом несколько гигов?

[ZVV]

А о чём вы вообще спорите?

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

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

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

[gl00mie]

Цитата:

Сообщение от NetBus

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от NetBus

Нет, опыт домохозяек показывает, что синхронизация только одного EDT на таблице весом 15 Гбайт убивает базу напрочь

А опыт специалистов показывает, что можно менять EDT и на 40Гб с живой базой.

И даже если изменяемый EDT входит в таблицу весом несколько гигов?

Дело, мне кажется, не в том, сколько занимает таблица (бывало и побольше, правда, на других системах ), а в том, что в ней присутствуют BLOB-поля. Тот же Oracle такие таблицы обрабатывает по одной записи, что, разумеется, не может не сказаться на производительности. Единственный выход тут - реорганизовывать таблицу, как уже указал Андре.

[NetBus]

Ок, спасибо всем за участие. Ситуация прояснилась, про это зло надо знать и уметь обходить.

[Logger]

Я думаю проблема еще в том, что при изменении длины EDT - Аксапта выполняет запрос Insert into Select From т.е. фактически создается новая таблица, в которую перекачиваются данные - все 15 гигов.

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

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