Как записать в таблицу БД текст объёмом свыше 2-х мегабайт?

← →
dehkanin (2014-02-19 20:15) [0]

1. Какой тип переменной выбрать для поля записи?
2. Если string то - что указать в поле "size ", чтобы записать текст объёмом свыше 2-х Мб?
Если другой тип - какой?

← →
Anatoly Podgoretsky © (2014-02-19 20:35) [1]

Вообще то это от СУБД зависит

← →
Rouse_ © (2014-02-19 20:42) [2]

2 мега данных в блобе одной записи?!
Да Вы, батенька, эстет :)

← →
dehkanin (2014-02-19 20:46) [3]

СУБД? с использованием языка SQL в данном случае используется приложение Absolute Database.

← →
dehkanin (2014-02-19 20:50) [4]

Rouse: А Вы, "батенька",- острячок?
М.б. не поняли? (Я наверное бестолково объяснил?)
Есть файл rtf объёмом около 2- Мб (текст документа), который надо сохранить в таблице; и таких файлов -много.
Что бы Вы применили?

← →
Inovet © (2014-02-19 21:09) [5]

> [3] dehkanin (19.02.14 20:46)
> с использованием языка SQL в данном случае используется
> приложение Absolute Database.

Три раза перечитал - слова знакомые. А что не FB или MS SQL? Тоже бесплатные. Критерий выбора видимо был какой-то, в т.ч. удобство работы с BLOB, наверное, рассматривалось на первом месте, судя по задаче.

← →
brother © (2014-02-19 21:09) [6]

а ссылки (путь) к файлу не лучше ли хранить?

← →
Inovet © (2014-02-19 21:10) [7]

> [6] brother © (19.02.14 21:09)

Файлы надо расшаривать тогда.

← →
brother © (2014-02-19 21:11) [8]

локал или нет версия не уточнялось...

← →
brother © (2014-02-19 21:12) [9]

> Файлы

папки ли -_-

← →
brother © (2014-02-19 21:13) [10]

да и для нормального сис амина это не проблемма, не известно, кто эти фалй будет отображать или что-то сними делать )))))))

← →
Smile (2014-02-19 21:21) [11]

Пост закончился на ...
Rouse_ © (19.02.14 20:42) [2]
Да Вы, батенька, эстет :)

← →
Inovet © (2014-02-19 21:22) [12]

> [10] brother © (19.02.14 21:13)

Это дополнительные слои для задачи, а так всё средствами базы. Смотря что надо, мы не знаем.

← →
Rouse_ © (2014-02-19 21:42) [13]

> dehkanin (19.02.14 20:50) [4]
> Rouse: А Вы, "батенька",- острячок?

Видимо так и горжусь этим :)
ЗЫ: советую пересмотреть архитектуру хранения, хотя бы на ссылки...

← →
DVM © (2014-02-19 21:47) [14]

> dehkanin (19.02.14 20:15)
> 1. Какой тип переменной выбрать для поля записи?

BLOB поле.

> brother © (19.02.14 21:13) [10]

с файлами будет огромное количество проблем, начиная от синхронизации изменений и заканчивая одновременным доступом к файлу. Профита никакого абсолютно. Т.е АБСОЛЮТНО никакого, одни недостатки.

СУБД абсолютно без разницы какого размер данные кладут в ее поле BLOB. Хоть 100 мегабайт, хоть терабайт. Это все будет также файл на диске, но по другому там размещенный. И в случае файла в БД и в случае файла на файловом сервере доступ и к тому и другому будет осуществлять с примерно одной и той же скоростью, ограниченной скоростью TCP соединения.

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

← →
Rouse_ © (2014-02-19 21:57) [15]

> Где то на сайте Firebird есть интервью с разработчиками
> Firebird, где они отвечая на вопрос, можно ли хранить файлы
> в субд, говорят - нужно хранить.

Угу, было такое заблуждение. На сколько я помню все остановилось на скорости выборки данных при хранении в базе ста фильмов в HD формате.

← →
DVM © (2014-02-19 22:02) [16]

> Rouse_ © (19.02.14 21:57) [15]

> Угу, было такое заблуждение.

Нет тут никакого заблуждения.

> На сколько я помню все остановилось на скорости выборки
> данных при хранении в базе ста фильмов в HD формате.

Причем тут скорость? Кто заставляет выбирать в запросе и вытягивать на клиента BLOB поля содержащие большие объемы данных? Выбирать надо метаинформацию, а по ней тянуть на клиента файл.
Можно подумать копирование на клиента сто фильмов в HD формате быстрая операция.

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

← →
Rouse_ © (2014-02-19 22:05) [17]

> Ты вот лучше назови реальные плюсы хранения файлов не в
> базе, а в виде файлов на диске.

Скорость бэкапа

← →
DVM © (2014-02-19 22:08) [18]

> Rouse_ © (19.02.14 22:05) [17]

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

← →
Плохиш © (2014-02-19 22:08) [19]

> Критерий выбора видимо был какой-то, в т.ч. удобство работы
> с BLOB, наверное, рассматривалось на первом месте, судя
> по задаче.

Судя по вопросам этих букав в критериях не встречалось ;-)

← →
Rouse_ © (2014-02-19 22:09) [20]

А, ну и до кучи - произвольный доступ к файлу по офсету (дозакачка).

← →
Rouse_ © (2014-02-19 22:09) [21]

> DVM © (19.02.14 22:08) [18]
> Ошибаешься. Бекап средствами СУБД сохраняет только изменения
> от предыдущей версии

Ты сейчас про фаерберд?

← →
Rouse_ © (2014-02-19 22:13) [22]

> DVM © (19.02.14 22:08) [18]
>
> > Rouse_ © (19.02.14 22:05) [17]
>
> Ошибаешься. Бекап средствами СУБД сохраняет только изменения
> от предыдущей версии

Да хотя в принципе пофигу, ты представляешь себе затраты на сохранении изменений в ссылке на данные, и изменении 10 байт с 40 гигабайтном блобе?
Просто тупо время на поиск изменений?

← →
DVM © (2014-02-19 22:14) [23]

> Rouse_ © (19.02.14 22:09) [20]
> А, ну и до кучи - произвольный доступ к файлу по офсету
> (дозакачка).

Опять ошибаешься. Если пользоваться не дельфийскими компонентами доступа, а напрямую вызывая API сервера (хотя может какие компоненты и предоставляют такую возможность, но влюбом случае можно ее реализовать), то возможно произвольное позиционирование в блобе. И докачка по частям и закачка по частям. А если интегрировать свое расширение (dll ) в сервер, так вообще возможности безграничны. В Firebird это есть.

> Rouse_ © (19.02.14 22:09) [21]

> Ты сейчас про фаерберд?

Касательно бекапа в FB не знаю, не делал. В Оракле бекап точно есть Incremental backup.

← →
Rouse_ © (2014-02-19 22:15) [24]

> DVM © (19.02.14 22:14) [23]
> Опять ошибаешься.

С Ораклом не работал - могу и ошибаться.

← →
DVM © (2014-02-19 22:17) [25]

> Rouse_ © (19.02.14 22:13) [22]

> Просто тупо время на поиск изменений?

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

← →
Rouse_ © (2014-02-19 22:19) [26]

Дим, ты не понял.
Дано: таблица с 1 записью с блобом в 40 гигов, и альтернатива - ссылка на данные.
Бэкапим - для того чтоб найти изменения в первом случае, нам нужно перечитать все 40 гигов - нес па?

← →
DVM © (2014-02-19 22:19) [27]

> Rouse_ © (19.02.14 22:15) [24]

В Firebird есть http://www.firebirdsql.org/manual/nbackup-backups.html#nbackup-backups-incr в Oracle есть http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

← →
DVM © (2014-02-19 22:23) [28]

> Rouse_ © (19.02.14 22:19) [26]

> Бэкапим - для того чтоб найти изменения в первом случае,
> нам нужно перечитать все 40 гигов - нес па?

Не, не так. Если страница была перезаписана, не важно такими же данными или другими, то это изменившаяся страница и подлежит бэкапу. Никто там ничего не сравнивает. Т.е если залили в базу новый файл вместо старого, то весь файл будет забекаплен, даже если он такой же как старый.

Но ведь при бэкапе файлов в файловой системе абсолютно такая же картина. Только там вместо страниц кластеры.

> DVM © (19.02.14 22:19) [27]

Давай просто протестируй.
Возьми Аватара в HD (60 гигов) и залей в таблицу.
Сделай бэкап, замерь время.
Произвольно измени в блобе данные (байт 100), сделай бэкап - замерь время.
Напиши код который последовательно читает данные с диска и из базы - замерь время.

> Rouse_ © (19.02.14 22:24) [29]

> Давай просто протестируй.

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

Касательно скорости бэкапа. Не все так однозначно. Как думаешь, что будет быстрее - бэкап миллиона файлов лежащих отдельно на диске или бэкап одного файла БД, где лежит тот же миллион?

> Rouse_ © (19.02.14 22:24) [29]
>

Будет время может и потестирую. Мне честно говоря не хочется. Это целый день же займет с большими объемами.

Одно могу сказать, чтение из СУБД большого файла и запись в СУБД большого файла не сильно отличается от скачивания оного или загрузки через HTTP например. Это я проверял.

> Как думаешь, что будет быстрее - бэкап миллиона файлов лежащих
> отдельно на диске или бэкап одного файла БД, где лежит тот
> же миллион?

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

Конечно, оба подхода к хранению несомненно имеют право на жизнь. И надо очень тщательно изучить все нюансы задачи прежде чем принимать решение о хранении файлов в БД или на диске.

Хранение в базе - более общий случай, в файлах - частный. Более общий как следствие более гибкий, но вероятно немного более медленный вариант.

Плюсы хранения в БД такие:
1) Более удобное разграничение доступа к файлам.
2) Одновременный доступ к файлам множества пользователей, в том числе на запись.
3) Автоматическая поддержка целостности базы без необходимости синхронизации изменений в файловой системе и базе.
4) Более простой удаленный доступ, нет необходимости организовывать доп удаленный доступ к файлам, опять же с разрешениями на запись отсутствуют сложности. Достаточно открыть один порт.
5) Более простой бэкап без остановки базы.
6) Нет проблем с одинаковыми именами файлов, может хранится множество версий одного и того же файла.
7) Нет проблем с ограничениями некоторых файловых систем на количество файлов в папке.

этот список, думаю, можно еще продолжить.

Эмм, Вы еще подеритесь, горячие финские...

У ТС поди все в 1NF, а Вы тут о высоком...

> этот список, думаю, можно еще продолжить.
этот список можно выкинуть посмотрев на используемый движок -
> Absolute Database
насколько знаю это что-то SQLite, встраиваемый "моно" движок (читал когда-то и про сервер но не видел вопросов о том чтобы его использовать... может его и нету совсем)

т.е. используется локально, "в одно рыло", (с вероятностью 95%)... цель хранения в базе скорее всего вовсе не в "высоких материях", а попросту - лишить юзера работать с файлами в чем то помимо проги.
из написанного списка только 6 как то имеет смысл для условий топиккастера (может иметь если он делает что-то этого требующее... ставлю на вероятность этого менее 3% :)).

> что-то SQLite,
что-то типа SQLite,

я всеж согласен с Розычем, имхо лучше ссылки на файлы...

да и для бэкапа базы это лучше, если единожды врайт ссылку и далее реад онли...

> brother © (20.02.14 08:48) [38]

> да и для бэкапа базы это лучше, если единожды врайт ссылку
> и далее реад онли...

Нет никакой разницы. База бекапится тоже не вся целиком. Ничто не изменилось - ничего и не забекапится.

> brother © (20.02.14 08:45) [37]
> я всеж согласен с Розычем, имхо лучше ссылки на файлы...
>

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

Этот вариант жизнеспособен, если действительно база только для чтения или для использования в "одно рыло".

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

У нас развернута такая система, с ней работает пара сотен тысяч человек, а не десятков. Это собственно сервер обновлений, в котором ежедневно меняется 7-10 файлов размером от 10 до 60 мегов каждый, а всего файлов в районе 900 с копейками + ежемесячно по 10-15 новых добавляется).
Перешли на хранение файлов вне базы именно из-за тормозов.

Как записать в таблицу БД текст объёмом свыше 2-х мегабайт? Найти похожие ветки